# Overview Amigo is a reasoning engine that works across channels. Voice calls, SMS conversations, WhatsApp messages, email, and web-based data collection all run through the same pipeline. The agent uses the same context graphs, the same tools, the same safety rules, and the same world model integration regardless of how a patient reaches it. Healthcare conversations rarely fit neatly into one channel. A patient might answer a phone call, receive a text with a photo upload form, and get a reminder message the next day. These are not separate interactions handled by separate systems. They are one coordinated conversation. {% @mermaid/diagram content="flowchart TD phone\["Phone\n(real-time voice)"] --> engine\["Reasoning Engine\n(context graphs + tools + safety)"] copilot\["Clinical Copilot\n(in-person encounters)"] --> engine sms\["SMS"] --> engine whatsapp\["WhatsApp\n(text + voice notes)"] --> engine websocket\["WebSocket\n(real-time text chat)"] --> engine email\["Email\n(transactional, marketing)"] --> engine surfaces\["Surfaces\n(web forms)"] --> engine engine --> wm\["World Model"]" %} ## How It Works The platform's [reasoning engine](/agent/reasoning-engine.md) operates on a signal-and-effect model. Signals arrive from any channel - a voice utterance, a text message, a form submission - and the engine processes them through the agent's context graph, runs tools, applies safety checks, and emits effects. Those effects route back to whichever channel is appropriate: spoken audio, a text reply, a surface link. The engine is channel-agnostic - modality adapters handle the translation on both sides. Multi-channel orchestration works without duplicating agent logic. ## Channel Types ### Phone Real-time phone conversations with speech recognition, natural speech generation, and emotion detection. The agent calibrates emotional analysis to each caller's own vocal baseline, interprets emotional signals in the context of the conversation state, and adapts its tone and pacing accordingly. The agent handles inbound and outbound calls, manages turn-taking, and escalates to human operators when needed. Phone is the highest-bandwidth channel for complex discussions like care coordination or clinical verification. See [Phone](/channels/voice.md) for details on the audio pipeline, emotion detection, and operator escalation. ### Clinical Copilot Real-time AI-powered clinical documentation during in-person provider-patient encounters. The platform transcribes the conversation and produces structured SOAP notes, ICD-10 code suggestions, and clinical alerts. This is the same reasoning engine applied to a different modality - the provider and patient are in the same room rather than on a phone call. See [Clinical Copilot](/channels/clinical-copilot.md) for the full capability set. ### Text Sessions Text-based conversations over SMS, WhatsApp, and WebSocket. Text sessions support the same context graphs and tools as phone, but the interaction pattern is different - patients respond on their own schedule over SMS and WhatsApp, or interact in real time through a WebSocket connection embedded in a web or mobile app. WhatsApp adds voice note support, where patients send spoken audio and receive spoken replies in the same thread. All three channels share the same conversation persistence, so sessions can freeze and resume across disconnects. See [Text Sessions](/channels/text-sessions.md) for channel details, wire protocol, and how text conversations differ from phone in practice. ### Email Transactional and marketing email delivery with verified sending domains. Each workspace configures sending domains with full DNS authentication - DKIM signatures, SPF records, DMARC policies, and inbound MX routing. Email use cases are typed as transactional (appointment confirmations, care instructions, lab results) or marketing (wellness campaigns, program enrollment), with tiered sending that starts conservatively and scales as the domain builds reputation. Email integrates with the same outbound orchestration as voice and text. Triggers, campaigns, and conversational follow-through can dispatch email alongside other channels. The platform tracks inbound replies and maintains email thread continuity using standard RFC 5322 message threading, so replies from patients land in the same conversation thread as the original outbound. The platform manages domain verification, deliverability monitoring, and compliance (bounce handling, complaint tracking) so clinical teams configure what to send, not how to send it. ### Surfaces Web-based forms and data collection interfaces that the agent sends to patients mid-conversation. When the agent needs structured input - a photo of an insurance card, a list of medications, a signed consent form - it generates a surface link and delivers it over text. The patient fills it out in a browser. The results flow back into the same conversation context. See [Surfaces](/channels/surfaces.md) for how surfaces integrate with the conversation flow. ## Multi-Channel Orchestration A single patient interaction can span multiple channels without losing context. The agent calls a patient to schedule an appointment, realizes it needs a photo of their insurance card, sends a text with a surface link, and follows up the next day with a confirmation message. The context graph tracks the full interaction state across all of these steps. Channel selection is not random. The platform considers patient preferences, contact history, and the nature of the data being collected. Photos and document uploads require text or web. Quick confirmations work well over text. Detailed care instructions and pre-procedure materials work well over email. Complex clinical discussions route to voice. The agent picks the right channel for each step. ## Why This Matters for Healthcare Patients do not think in channels. They want their appointment scheduled, their prescription refilled, their referral processed. They do not want to be told "please call back during business hours" or "we can only handle that over the phone." A channel-independent platform means clinical teams configure one agent with one set of conversation flows, and the platform handles the channel logistics. No separate voice bot and text bot to maintain. No divergent behavior across channels. One set of safety rules. One audit trail. ## Learn More {% content-ref url="/pages/jyoxNhN4VGjrq9P6R26S" %} [Phone](/channels/voice.md) {% endcontent-ref %} {% content-ref url="/pages/xB6IEt05ykyLZHIqXEDe" %} [Clinical Copilot](/channels/clinical-copilot.md) {% endcontent-ref %} {% content-ref url="/pages/F9G0lrxZA31mW1pawkgs" %} [Text Sessions](/channels/text-sessions.md) {% endcontent-ref %} {% content-ref url="/pages/L5QVsqZuFuZalMUMRMw8" %} [Surfaces](/channels/surfaces.md) {% endcontent-ref %} {% content-ref url="/pages/8yGbb8LE1sy3JeaS7UnI" %} [Outbound](/channels/outbound.md) {% endcontent-ref %} {% content-ref url="/pages/uirHtW6W7wkJL0eKBdYK" %} [Email](/channels/email.md) {% endcontent-ref %} --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://docs.amigo.ai/channels/conversations.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.