An AI system layer for a healthcare navigation platform

Overview

A US healthcare navigation platform serving 3M+ members and 570+ employer clients was building a multi-agent AI framework: an orchestrator, specialised worker agents for providers, claims, documents, benefits and communication, retrieval, memory, tools, event infrastructure and guardrails. It could answer requests and it could raise signals on its own. My brief as Product Design Lead was different from "design the chatbot": decide how a member experiences that intelligence across Home, Search, Object Pages, Documents, Chat and human support without ever having to understand the machinery behind it.

The product and company names are withheld under NDA. The diagrams below are the conceptual architecture I designed, redrawn for this page.

The portfolio story is not "I designed a chatbot". It is "I translated a multi-agent AI platform into one coherent healthcare member experience".

The risk

If every feature team added AI on its own, the product would fragment into an AI summary here, an "Ask AI" button there, a recommendation module somewhere else and a generic chatbot floating over everything. That is AI fragmentation, not intelligence. Four design goals followed: keep AI grounded in real healthcare objects and trusted member data; connect the six surfaces into one system; use AI in proportion to the member's need rather than maximising its visibility; and build something that could grow as agents and tools became more capable.

Understand the machine before designing the interface

I did not start with a wireframe. I mapped the platform first: the orchestrator sets goals, decides which agents are needed, routes work, combines outputs and handles fallback and escalation; worker agents specialise in narrower jobs such as provider search, claims reasoning, document summarisation or communication support. Then I translated each platform capability into the question a member is actually asking. Retrieval and reasoning becomes "What does this mean?". Orchestration becomes "Can you help me resolve this?". Proactive monitoring becomes "What changed or needs my attention?". Tool invocation becomes "Can you do something useful next?". Human escalation becomes "Can I continue this with a person?".

Design the member mental model around healthcare objects and needs, not around the internal agent topology.

Find the stable objects

The multi-agent architecture made object modelling more important, not less. I did not want "Agent" to become the organising principle of the UI. Members think in claims, providers, appointments, authorisations, documents, messages, medications and benefits, so I separated platform objects from member-facing objects and defined a stable OOUX backbone: Member, Conversation, Context, Domain object, and then Evidence, Recommendation or Handoff. Conversation became the central user-facing object. It carries messages, context, related healthcare objects, evidence, recommendations, follow-up prompts, attachments and a human handoff.

Attaching AI to an object changes the prompts. Instead of a generic "Ask AI", contextual help becomes "Explain this claim", "What does this authorisation mean?" or "Help me understand this document". The object establishes context before the AI even answers.

From chatbot to intelligence surfaces

I defined five surfaces with distinct jobs. Home answers "What deserves my attention?" and prioritises. Search answers "Help me find or understand something" and routes. Object pages answer "Help me understand this specific thing" and explain in context. Documents answer "What does this source actually say?" and summarise with evidence. Chat answers "Help me resolve it" and reasons, guides, acts and hands off. The member does not always need Chat. Often the right AI output is a ranked card, a short summary, a recommendation, a source-backed explanation or one contextual prompt.

Home surfaces attention. Search finds and routes. Object pages explain. Documents ground. Chat resolves.

A homepage that understands need without inventing content

A healthcare homepage tends to decay into a dashboard of links. The platform made a homepage possible that understands what deserves attention, under one safety rule: it interprets and prioritises existing signals and never invents content. I defined slots by member question, not by the backend that produced the signal: Today's Brief, Tasks, Status, Recommendations, Updates, Quick Access and Benefits. The source object is not the slot. The same appointment is a Status card while upcoming and an Update card when its time changes. Duplication is allowed when the object serves a new context; repetition is not.

Between many agents and one homepage I put a single decision layer, the composer: receive a signal, decide whether it is relevant now, map it to Task, Status, Update or Recommendation, deduplicate, rank, then render the shared card pattern and copy. The platform can add agents without the homepage growing new patterns.

Search: results first, assistant when useful

Traditional search answers "Find this". Conversational AI answers "Help me with this". They are related, not identical. My future-state model separates standard search from an AI help mode, but for V1 a visible mode switch would have been premature. The V1 rule: reliable object retrieval first, with a bridge into the assistant when the member needs explanation, comparison, summarisation or guidance. Global search executes on Enter, because AI-assisted retrieval, ranking and interpretation on every keystroke is wasteful and Enter gives the member a clear moment of intent. Local suggestions can still appear while typing, and when a suggestion matches on a secondary attribute it says why: a facility, a provider at that facility, a service code description.

Documents: explain without replacing

Members meet long plan documents, explanation-of-benefit statements, letters and supporting files they may not understand. The AI could help only if the source stayed visible and authoritative. I made evidence a first-class trust pattern: original document, AI summary, the source sections the summary used, and an optional path into the assistant. AI-generated information should remain visibly derived from something. In healthcare, confident prose without provenance is a black box, and a black box is a liability.

Contextual assistance: one Assist slot, not a button everywhere

The common temptation in AI products is to put an assistant prompt on every card. That creates noise and makes AI compete with the product's own information hierarchy. Prompt placement gets more useful as the member approaches the point of confusion: at list level they scan, at a detail page they may want an explanation, at a single service line the product can form a much more specific prompt. I defined one reusable card anatomy with an Assist slot: Header for identity and status, Notice for an important change, Body for core attributes, Assist for contextual help when justified, Footer for actions. One prompt per card; if the same prompt applies to many cards it moves to the section level. The Assist slot made the assistant compatible with the existing design system instead of spawning a parallel "AI card system".

Chat as the resolution layer

Chat still mattered, but I stopped treating it as the whole AI experience. Home surfaces something, Search finds it, an object page explains it; Chat is where the member continues the problem, asks follow-ups, inspects evidence and moves toward resolution. Context travels with the member: a conversation opened from a claim, authorisation, provider, document or appointment starts with that object attached, so nobody re-explains what they were looking at. Global chat starts from a need and has to find context; contextual chat starts from an object, which lowers friction and constrains the answer space.

Proactive AI: a grammar, not a notification firehose

The platform could trigger agents from events and data signals, which raised a new question: what happens when the AI has something to say before the member asks? I refused to let every proactive signal become a push notification or a new card type. Every signal maps to one of four member needs: needs action becomes a Task, needs awareness becomes a Status, something changed becomes an Update, could help becomes a Recommendation. That grammar scales independently of the number of agents.

Human handoff as continuity, not failure

In healthcare there are moments when policy is ambiguous, information is incomplete, a member disputes an outcome, an action needs a person or the AI cannot safely continue. The human support specialist is therefore part of the assistant's object model, not an exception outside it. Escalation keeps the member's context intact; nobody retells the story when a person takes over. This also set up the longer-term direction where AI conversations and care-team conversations feel like one continuous support experience rather than unrelated channels.

Design system and cross-platform

The assistant needed reusable patterns without looking like a second product embedded in the member experience. I treated AI as an extension of the existing anatomy: primitives, shared composites, domain components and contextual Assist patterns. Product work reveals new patterns; the design system standardises them once validated. Across web and React Native the object relationship stays stable while the container adapts: an inline assist on desktop stacks below content on mobile, a popover notification panel becomes a full page when collection management is substantial, hover-revealed overflow actions are always tappable.

V1 without blocking the future

V1: answer a question, use related member and object context, show or make evidence available, offer a useful follow-up, escalate to a person when needed. Future: form a plan across multiple agents, retrieve and reconcile information, use tools and take permitted actions, confirm the result, continue with shared state. The member-facing architecture supports the second without pretending it already exists.

Outcome

This work spanned an evolving platform and multiple initiatives, so I will not invent business metrics that were not measured. The impact was architectural. It established the distinction between AI platform architecture and member-facing AI; an object-centred model for contextual assistance; one shared system connecting Home, Search, Object Pages, Documents, Chat and human support; a grammar for proactive signals; an AI-assisted global search that preserves reliable retrieval; a source-aware document model; rules for prompt placement, evidence and contextual handoff; and a foundation for 3M+ members that scales as agents and tools become more capable.

The most important contribution was not one screen. It was the product architecture connecting intelligence to the healthcare objects members already understand.

What changed in my own thinking

At the start it was easy to frame the problem as "where should Chat live?". The useful question turned out to be "where does intelligence belong?". Chat became one interface, Search another, Documents another, homepage cards another, object-level assistance another, and the assistant became the connective tissue between them. Designing AI is a systems problem before it is an interface problem. Healthcare AI needs visible grounding, not confident prose. Stable objects and context matter more as agent architectures get more complex. A mature AI experience uses the smallest amount of AI that solves the member's problem. And human escalation is designed as continuity, not as failure.