Designed for sub-300ms voice recall: inside the edge hot path

Northsun is designed for sub-300ms voice recall. That sentence describes an engineering target, not a universal latency guarantee or a published benchmark.

The distinction matters. A real request crosses your application, the network, Northsun authentication, tenant-scoped storage, optional enrichment, and your agent platform. Architecture can bound work and expose measurements; it cannot make every dependency identical.

The hot path is a read contract

POST /v1/recall_and_enrich has to authenticate the tenant, resolve the caller, read available memory, attempt eligible enrichment, and return a packet the agent can use. The endpoint is designed so optional work does not become required work.

That gives an integration three possible classes of result:

• A successful packet with memory and enrichment fields available.
• A successful packet with some nullable fields or a degraded indicator.
• A non-success response that the caller-facing application must handle.

Your agent needs a valid behavior for all three. A neutral opening question is safer than delaying the conversation or inventing context.

Edge execution shortens one part of the route

The public API runs on Cloudflare Workers, and database access uses the repository's tenant-scoped data path. Edge execution can reduce application distance for some requests, but it does not prove the end-to-end latency experienced by every caller or agent platform.

The useful design principle is separation: keep connection management and tenant isolation inside the service, and keep the client contract independent of where a particular request executes.

Cache first, database fallback

The recall path uses a read-through cache for caller and interaction data. A cache hit can avoid a database read for that material; a miss can fall back to the database and repopulate the cache.

Cache behavior is an implementation detail, not an availability promise. Integrations should consume the response contract, inspect degraded state where present, and retain a context-free fallback. They should not assume a caller is warm, a cache is present, or a database fallback will always succeed.

Enrichment is useful precisely because it is optional

Trestle and Twilio Lookup can contribute external caller information. That work is bounded and may be served from cached data, arrive fresh, or be absent from the response.

Model each enrichment field as nullable. Do not gate call setup on a person name, business identity, carrier, or line type. Do not convert an enrichment hint into a verified fact without an application-level policy that justifies doing so.

This is the practical difference between enrichment and dependency: enrichment improves the packet when available; the agent still works when it is not.

Timing is telemetry, not a benchmark

Successful recall responses can include timing_ms. Use that field with your own wall-clock measurement and trace identifier to diagnose the request you actually made.

Do not turn one warm request, one region, or one successful packet into a general performance claim. A useful production evaluation records:

• warm and cold caller paths;
• packets with present and absent enrichment;
• degraded and non-success results, not only successful samples;
• your agent platform's full time to usable context;
• test region, tenant shape, sample window, and configuration.

If you publish measurements, label the methodology and the environment. Until a representative benchmark exists, the honest public statement remains the design target above.

Write-back is outside recall

POST /v1/calls/end accepts a completed interaction separately from the pre-interaction recall path. A 204 No Content response confirms the interaction is already committed durably. A later recall normally returns it, though a recall already in flight, or a failed refresh of the recall cache, can serve the earlier state until that cached view is refreshed.

Production tests should therefore verify the complete lifecycle: recall, call-end acknowledgement, then later recall of the expected history. This protects the product experience from confusing transport success with observed persistence.

Design the integration around failure

Before serving real traffic, decide:

1. How long your application waits before using neutral context.
2. Which nullable fields may influence the prompt.
3. How webhook retries are deduplicated.
4. How trace IDs and timing are recorded without logging sensitive content.
5. How you prove write-back through a later read.

The API reference defines the current public shapes. Errors and retries covers failure handling, and the production-readiness checklist turns these principles into an acceptance test.

The architecture aims at the conversational gap. Your measurements determine whether your complete agent system meets its own latency requirement.