Designing AI agents patients and staff actually trust

The platform needed to let non-technical hospital teams assemble an AI agent from their own knowledgebase and a set of skills, without writing prompts from scratch.

Escalation and uncertainty were designed as first-class states rather than error cases. When confidence is low or an intent falls outside the agent's skills, the conversation transitions to a live agent with full context carried over, so the patient never repeats themselves.

Building an AI agent is not a form, it is a set of decisions. I anchored the platform on the four inputs a client has to get right before an agent can go live:

• Objectives: what this agent is responsible for, written in plain language, which frames every other choice in the builder.
• Instructions: tone, boundaries, and escalation rules, authored as guidance rather than raw prompt text.
• Knowledgebase: which sources the agent may answer from, with visibility into what is connected and what is stale.
• Skills: the concrete tasks the agent can perform, scoped so a client can add capability incrementally.

The builder presents these as a persistent left-hand structure rather than a linear wizard, because configuration is never finished. Clients return to tune instructions or swap sources long after launch, and the layout had to make that ongoing work feel routine instead of like a re-setup.

Paired with the configuration is a system output window: a live test surface where the client talks to the agent as it is currently configured, and sees not just the reply but why it answered that way, which source was used, and where confidence dropped. That feedback loop was the piece that made the platform trustworthy. Without it, clients were tuning blind and had no way to tell a knowledge gap from an instruction problem.

The AI platform was a new product, not a module of the enterprise suite. It needed its own identity: a forward-looking surface that signaled a different class of capability, without inheriting a decade of legacy patterns from the flagship platform.

Rather than extend the existing component library, I stood up a separate design system with shadcn/ui and Tailwind CSS as the base. That gave us primitives we owned outright and a token layer we could theme independently, so the platform could look and behave like itself while still meeting the same accessibility bar.

The tradeoff was two systems to maintain. I mitigated it by keeping shared semantics, naming, spacing logic, and accessibility rules aligned with the enterprise system, so a designer or engineer moving between products recognizes the grammar even when the visuals differ.