Why Amigo
What makes Amigo different from conventional healthcare AI - architectural decisions, not marketing claims.
This page describes the architectural decisions that differentiate Amigo from conventional IVR systems, chatbot platforms, and healthcare AI products. These are structural differences in how the system is built, not feature comparisons.
Measurement-First Decision Making
Most healthcare AI systems rely on prompt engineering without runtime verification. When the LLM produces incorrect output, the fix is another prompt revision.
Amigo anchors every decision to measured state. The agent knows its position in the context graph, the confidence score of every data point it references, the caller's emotional trajectory over a rolling 30-second window, and its own confidence level. When confidence drops below a threshold, the agent escalates - it does not guess. When data confidence is low, the system gates it from flowing to the EHR. Behavior is driven by measured signals, not unchecked LLM output.
Confidence-Gated Data Flow
Conventional systems either skip verification entirely (data flows straight from conversation to database) or require all-human review (which doesn't scale).
Amigo uses three layers of gates between a voice call and a system of record. Source confidence scores rank data by reliability (authoritative API at 1.0, voice extraction at 0.5). An LLM judge evaluates flagged data against the original transcript. Human review catches what the LLM judge can't. Data only reaches the EHR after passing all applicable gates. See Connector Runner for details.
Event-Sourced World Model
Conventional systems store patient state in a CRUD database. When a field is updated, the old value is gone. There is no way to know what changed, when, or why.
Amigo's world model stores every fact as an immutable, timestamped event with a confidence score and source attribution. Entity state is a computed projection from events. When two sources disagree, the higher-confidence source wins. Every change is traceable. Nothing is overwritten.
Emotion-Aware Voice
Conventional voice systems have no awareness of how the caller sounds. They process words only.
Amigo runs three parallel emotion models on every call: prosody (how the voice sounds), vocal bursts (sighs, laughs, groans), and language (what the words convey). These models feed a rolling 30-second window that produces valence, arousal, trend, and coherence signals. These signals steer both navigation decisions (which conversational path to take) and delivery (how the agent's voice sounds). See Emotion Detection.
Hierarchical State Machines, Not Scripts
Conventional systems use either linear call scripts (rigid, can't handle deviations) or unbounded prompt chains (no structural guarantees).
Amigo uses context graphs - hierarchical state machines that define problem spaces with variable constraint density. Compliance-critical paths (medication verification, identity confirmation) have low entropy: the agent follows a tight, prescribed sequence. Open-ended paths (gathering patient concerns, scheduling preferences) have high entropy: the agent explores freely within defined boundaries. This gives you structural safety where you need it and flexibility where you want it.
Structural Safety, Not Bolt-On Filters
Conventional systems add safety as a content filter on outputs. The LLM generates a response, and a separate filter checks whether it's safe to send.
Amigo embeds safety in the architecture. Confidence gates prevent unverified data from reaching EHRs. Escalation triggers hand off to human operators when the agent's confidence drops. Monitor concepts detect safety-relevant patterns in real time. The conference-first operator model means escalation never drops a call. Safety is not a layer on top - it's in the data flow, the state machines, and the escalation paths. See Safety Overview.
Multi-Provider LLM Architecture
Conventional systems are locked to a single LLM vendor. If that vendor has an outage, latency spike, or pricing change, you have no options.
Amigo supports OpenAI, Anthropic, Google, and AWS Bedrock with per-interaction model selection. Different parts of the pipeline can use different models based on the task requirements: a fast model for filler speech generation, a capable model for clinical reasoning, a cost-effective model for data review. This avoids single-vendor dependency and lets you optimize for cost, latency, and capability independently.
Last updated
Was this helpful?

