The most consequential AI engineering problem of 2026 is not model capability. The models are good enough. The problem is memory — the practical question of how an agent remembers what it has previously said to a person, what that person has previously asked, and what was previously resolved. Anyone who has actually shipped an AI agent into a customer-facing role has discovered that the gap between "the model can answer this question" and "the agent acts like a coherent entity over time" is the entire product.
In the wellness vertical specifically, the memory problem shows up as fragmentation. A patient calls the practice on Tuesday and the voice agent answers their question about aftercare for a recent treatment. The same patient sends an email on Friday about scheduling a follow-up. The web chat picks up the email-driven inquiry the next Monday when the patient revisits the site. In a fragmented stack, those three interactions live in three different systems with no shared state. The voice agent never knows about the email; the web chat never knows about the call. The patient experiences a clinic with no memory, which is the most expensive thing a wellness clinic can be.
This piece is an engineering perspective on why unified inboxes — by which we mean shared cross-channel state for an AI agent system — have become the central design problem in this category. It is also a description of what the architecture actually looks like under the hood, written from the perspective of having built it.
The pattern most teams stumble through
Most teams who set out to build an AI agent system for a wellness practice start in the same place: a single channel, usually voice or web chat, with a model handling the conversation and a CRM lookup at the start of each interaction. This works adequately for a single-channel deployment, and most vendors in the space stop here. The architectural failure mode shows up when the team tries to add a second channel. They face a choice: do we extend the existing system to handle multiple channels, or do we run a parallel system for the new channel?
The path of least resistance is the parallel system. The team adds an SMS agent with its own context, its own retrieval, its own conversation handling. Six months later they add iMessage, then email handling, then web chat. Each system is built well enough on its own. The system as a whole is fragmented; the agent has no memory across channels, and the practice operates as multiple disconnected vendors from the patient's perspective. We have audited dozens of these architectures. The team always knows it is the wrong shape; the team almost never has the engineering capacity to unwind it.
The alternative — designing for unified state from the start — is more work in the first six weeks and dramatically less work over any subsequent timeline. It is also where the architecturally interesting problems live. Most of the engineering challenge in modern wellness AI is not the conversational model; it is the state and retrieval layer that sits underneath every conversation regardless of channel.
What unified state actually requires
A working unified-inbox architecture has four layers that need to be designed coherently. First, a canonical patient record — one row per actual human, regardless of how many phone numbers, email addresses, or device identifiers that human has used to interact with the practice. The deduplication logic here is harder than it sounds. A patient who calls from a new number, then emails from an existing address, needs to be reconciled to one record in real time. We use a combination of structured matching (phone, email, name), behavioral signals (location patterns, device fingerprints where available), and conservative fallbacks that flag ambiguous cases for human review rather than guessing.
Second, a canonical conversation log — one ordered stream of all interactions per patient, regardless of channel. Voice transcripts, message threads, email exchanges, and chat sessions all land in the same log with channel metadata. The log is queryable and feeds the retrieval layer.
Third, a retrieval layer that pulls the relevant conversation history into the context of each new interaction. The naive approach is to dump the full conversation log into the model context on every turn. This works at very small scale and breaks the instant a patient has more than a few interactions. The working approach is a combination of recency bias (recent interactions get priority), semantic retrieval (vector embeddings over the conversation log, retrieved against the current turn), and structured retrieval (specific data fields like preferences and outcomes are pulled deterministically). We run all three in parallel and merge into a single context window.
Fourth, a write-back layer that updates the canonical record after each interaction. The voice agent that just resolved a billing question writes the resolution back to the patient record with structured tagging ("billing_resolved", "follow_up_not_needed"). The next agent that talks to this patient sees the resolution without having to re-derive it from the transcript. This write-back is the single most-skipped piece in fragmented architectures and is the difference between an agent system that gets smarter over time and one that does not.
The retrieval-quality problem
Retrieval is where most unified-inbox implementations live or die. The pattern that does not work: dumping all prior conversation into the context window and letting the model figure out what is relevant. The model is reasonably good at this for short histories and reasonably bad for long ones. By the time a patient has six months of interactions, the model is more likely to fixate on a stale detail than to surface the actually-relevant prior context.
The pattern that works is a small, fast model running retrieval against the conversation log and producing a structured summary that gets injected into the main agent's context. Claude Haiku 4.5 is the sweet spot for this in our deployments — fast enough to run inline on every turn, smart enough to identify the relevant prior interactions, cheap enough that the per-turn cost is acceptable. The main conversational model then operates on the summary, not on the raw log. The two-model architecture (retrieval Haiku + conversational Sonnet) outperforms a single-model approach on every quality metric we have measured.
The Claude Sonnet 4.6 release in April 2026 extended the 1M-token context window to the Sonnet tier, which has opened a different architectural option: putting the entire conversation log directly into Sonnet context with appropriate caching, and letting the model handle retrieval inline. We have run this approach against the two-model retrieval approach for the last six weeks. The full-context Sonnet wins on retrieval quality (it makes fewer mistakes about what is relevant), loses on cost (caching helps but is still meaningfully more expensive per turn), and loses on latency (the model has to process the cached context even on cache hits). The right choice depends on the specific use case. For high-stakes long-relationship patients (hormone clinics, multi-year aesthetic relationships), the full-context approach is worth the cost. For higher-volume lower-stakes contexts (IV reactivation outreach), the two-model approach holds.
The handoff problem
Unified state also unlocks the handoff between AI and human, which is the second-most-undersolved problem in this category. In a fragmented architecture, the handoff from the voice agent to a human clinical coordinator loses most of the context — the human has to read the transcript, re-derive the situation, and pick up the conversation from a cold start. In a unified architecture, the human inherits the agent's state: same conversation log, same structured summary, same outstanding action items. The handoff feels continuous to the patient because the human knows what the agent knew. This is also where the AI/human boundary feels honest rather than awkward — the agent does what it does well, the human does what they do well, and the patient experiences one coherent clinic.
The technical specification of a good handoff is that the human receives, in a single pane, the active conversation log, a structured summary of the situation, the outstanding action items, and any constraints (consent state, channel preferences, scheduling restrictions). The human does not have to look anywhere else to be effective. The most common failure mode of handoff is the "tabs problem" — the human has to open three tabs to find the EHR record, four to find the messaging history, and one to find the voice transcript. By the time they are oriented, the patient has hung up.
Where the industry is going
Three trends we expect to play out over the next 12-18 months. First, consolidation: most of the wellness-AI vendor landscape today is single-channel or thinly multi-channel. The companies that survive the next phase are the ones that have unified-state architecture, because their product gets better the longer it runs while fragmented stacks stay flat. Second, model-tier specialization: the unified-inbox architecture lets you make granular model-selection decisions on a per-turn basis, which makes economic sense as the model tier landscape diversifies (Haiku, Sonnet, Opus, and their equivalents at OpenAI and Google). The vendors who can route turns to the right tier at the right cost will deliver better economics than the ones who run everything on a single model. Third, retrieval as the moat: the canonical record gets more valuable the longer it runs, and the retrieval system gets better the more it sees. Vendors with three years of clean unified data have a meaningful advantage over vendors with three years of fragmented data, regardless of which model is in the conversational layer.
What we shipped this quarter
In service of this thesis, the platform changes we shipped in Q1 2026: the structured intent tagging on voice transcripts that lets retrieval surface relevant prior interactions by intent rather than just by keyword; the cross-channel reply mode that lets a coordinator respond to a voice transcript with an iMessage in the same patient pane; and the duplicate-record reconciliation that uses behavioral signals to merge records that structured matching would have missed. None of these are individually flashy. Together they are the difference between an agent that compounds in capability over time and one that resets every conversation.
The closing observation. The question every operator should be asking AI vendors in 2026 is not "what model do you use." Every reasonable vendor uses the right model for the moment. The question is "what does your retrieval architecture look like, and how does your handoff between AI and human staff actually work in practice?" Vendors who can answer those two questions specifically have built something durable. Vendors who deflect are running fragmented architectures that will degrade as the patient relationship deepens, which is exactly where you cannot afford degradation.
Written by
Tality Engineering
Engineering notes from the Tality platform team
