> For the complete documentation index, see [llms.txt](https://docs.amigo.ai/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.amigo.ai/reference/glossary.md).

# Glossary

Key terms used throughout the Amigo platform documentation. Definitions are kept short and practical. Terms are listed in alphabetical order.

## A

**Acceptance Region**: The set of outcomes that count as successful for a given use case. Defined across multiple dimensions (accuracy, safety, empathy, latency, cost). An outcome must satisfy all dimensions simultaneously to fall within the acceptance region.

**Action** (API: `tool`): A versioned code package or integration that an agent can execute during a conversation (Classic API). Actions connect the agent to external systems such as scheduling APIs, EHR lookups, or notification services. Called "tool" in the API.

**Agent**: A conversational AI system configured to handle a specific set of tasks. Platform agents combine versioned instructions and identity with a service, context graph, tools, and evaluation criteria. Classic agents can also use dynamic behavior sets.

**Agent Engine**: The modality-independent reasoning core of the platform. Processes typed signals (utterances, emotion, tool results, silence, barge-in, external events) and emits effects (respond, execute tool, filler, transition, terminate, observe, pause). Voice, text, and simulation are modality adapters that convert channel-specific I/O into signals and execute effects. See [Reasoning Engine](/agent/reasoning-engine.md).

**Agent Forge**: The CLI tool for managing agent configurations. Used to create, update, version, and promote services and version sets across environments. See the [Agent Forge](/reference/agent-forge.md) reference page.

**Auto-Enrichment**: A best-effort background process that can gap-fill registered enrichment keys for supported person and place entities. It writes source-tagged enrichment events asynchronously; higher-authority values can supersede the result. This is distinct from event embedding.

## B

**Backfill**: The process of replaying historical conversation data through an updated configuration to regenerate metrics and verify that changes produce the expected improvements.

**Barge-In**: Supported voice behavior that can stop agent playback after incoming caller speech satisfies the configured recognition, minimum-duration, and cooldown checks. Sensitivity and timing depend on the active voice path and service configuration.

## C

**Call-Phase Adaptation**: Prompt guidance based on call duration and recent emotional evidence. On an extended call with negative or deteriorating evidence, the voice runtime can ask for shorter, resolution-focused responses and suggest considering escalation. It does not automatically transfer or end the call.

**Channel Use Case**: A named channel identity (an email sender address or a phone-number pool) owned by a workspace. It captures the channel type, sender details, and inbox posture settings. Binding a use case to a service enables the channel - inbound traffic resolves to the bound service, and outbound dispatch routes through the use case.

**Clinical Tools**: Built-in tools available to supported agent runtimes for patient and appointment workflows, typed clinical reads, coverage and refill-request writes, outbound-queue lookup, and operational logging. Scheduled outbound work is created through explicit actions or workflows rather than a general built-in scheduling tool. Supported writes emit world-model events that can enter configured connector policy; recording the event does not prove external delivery.

**Compound Emotion**: A nuanced emotional state derived from fusing multiple signal layers (acoustic co-activation, temporal trajectory, behavioral signals, conversation context, and linguistic content) at each caller turn. Examples include Resignation, Process Frustration, Cold Hostility, Masked Distress, and Sarcasm. See [Emotion Detection](/channels/voice/emotion-detection.md).

**Confidence Score**: A numeric value used in different product contexts. **Data confidence** ranks a world-model observation by source class and participates in conflict resolution. Evaluation scores and model-reported certainty have separate meanings and do not automatically inherit data-confidence semantics or trigger operator escalation.

**Conference-First Architecture**: The Platform-managed voice-call model in which the caller and agent use a shared conference and an eligible operator can join without reconnecting the caller. Listen, takeover, and warm-forwarding paths have different behavior; conference participation does not guarantee a complete transcript or clinical briefing.

**Connector Runner**: The integration layer that ingests supported EHR, FHIR, REST, file, and webhook sources and routes policy-eligible event payloads to supported external destinations. Inbound recovery and outbound delivery semantics vary by connector and operation.

**Context Fusion**: The combination of available acoustic, linguistic, behavioral, and recent-turn evidence when deriving emotion-related prompt and delivery guidance. These signals remain incomplete, model-derived evidence and do not independently determine safety or escalation. See [Emotion Detection](/channels/voice/emotion-detection.md).

**Context Graph** (API: `service_hierarchical_state_machine`): The structured map of a problem space that guides agent behavior. Context graphs define states, transitions, decision points, and safety boundaries for a specific workflow. Called "service hierarchical state machine" in the API.

## D

**Data-MCP**: A standalone Model Context Protocol service that exposes read-only SQL exploration tools using Classic API organization credentials. For agent-side access during conversations, use [platform functions](/agent/platform-functions.md); external integrations using Platform API workspace credentials can use the Platform API MCP server. See [Data Access (MCP)](/data/data-mcp.md).

**Dominance**: A field in the normalized emotional-state shape intended to represent perceived control. The current runtime snapshot does not derive a live dominance value and reports the neutral placeholder `0`; it does not drive an empathy tier. See [Emotion Detection](/channels/voice/emotion-detection.md).

**Drift**: A gradual change in agent performance over time. Can be caused by changes in the input distribution (new types of conversations), shifts in agent behavior, or evolving requirements. See [Drift Detection](/testing/testing/drift-detection.md).

**Dynamic Behavior** (Classic API: `dynamic_behavior_set`): A Classic-only behavioral rule with semantic triggers and instruction or tool-candidate changes. Classic behavior sets are versioned and applied through Classic version sets. The Platform API does not expose or execute this resource; express conditional Platform behavior in context graph states, transitions, policies, and eligible tools. See [Dynamic Behaviors](/agent/context-graphs/dynamic-behaviors.md).

## E

**Effect**: An output primitive from the reasoning engine representing something the agent wants to happen. Effect types: respond (say something), tool called (execute a tool), filler (play/send filler content), transition (state change), terminate (end conversation), observe (emit analytics event), pause (deliberate silence). The modality adapter decides how to execute each effect - a respond effect becomes TTS audio on voice, an SMS message on text, or a trace entry in simulation.

**Email Channel**: A managed channel for transactional and marketing email with verified sending domains, typed use cases, inbound reply threading, and separate delivery-status records. Email has its own send API and is not a target of the Conversations API's outbound-start or channel-switch operations. See [Channels](/channels/conversations.md).

**Entity Resolution**: The process of associating an incoming record or caller with a workspace entity. Current paths use explicit source identifiers, caller bindings, and scoped lookups. `same_as` edges represent historical merges from the retired pre-SDP resolver; the current Platform pipeline does not produce new deterministic cross-source merge edges.

**Escalation**: The process of handing a supported conversation from the agent to a human operator. Escalation follows authored agent and context-graph policy, supported operator workflows, or an explicit user request; a generic low-confidence score does not automatically trigger it.

**External Principal**: An entity-anchored, role-scoped session identity for external users (such as clinicians or partner employees) driving agent conversations. A principal binds an external user identity to a workspace entity with assigned roles, and role grants scope which integration endpoints, skills, and knowledge base scopes the session can access. See [Compliance](/operations-and-safety/compliance.md).

## F

**FHIR Store Connector**: A connector type that integrates directly with FHIR R4 stores. Polls configurable FHIR resource types with per-resource cadences and supports outbound write-back with optimistic locking.

**File Drop Connector**: A connector type that ingests data from files (CSV, NDJSON, FHIR Bundle, JSON) deposited in cloud storage. Used for batch data imports from partners or external systems.

**Filler Speech**: Short spoken acknowledgements that can cover part of a voice-processing or tool-execution delay. Filler selection is channel-, state-, and emotion-aware, can be suppressed, and does not guarantee that every delay is covered.

**Function Store**: The workspace registries from which platform functions and workspace data queries are loaded at session start. A successfully loaded definition can become an agent tool when the selected runtime and any applicable Context Graph binding expose it; registration alone is not a universal visibility or authorization rule. See [Platform Functions](/agent/platform-functions.md).

## I

**Interaction Insight**: A Classic API response for a permitted conversation interaction, including the current state and action, transition logs, permitted working-memory or reflection records, and executed tool-call logs. The Platform API does not expose an equivalent hidden-reasoning contract; Platform simulation traces contain best-effort observed evidence instead.

## K

**Keyterm Boosting**: A speech-to-text configuration that biases compatible recognition paths toward domain vocabulary such as medication, provider, or organization names. It can improve recognition for selected terms but does not guarantee an accurate transcript.

## L

**LLM-Evaluated Metric**: A metric whose eligible evidence is scored by a model-based judge against authored criteria rather than by a deterministic rule. Availability, scheduling, and execution limits depend on the evaluation path, and results require calibration against human review. See [Metrics](/testing/testing/metrics.md).

## M

**Functional Memory**: Cross-session context built from source conversation records, model-extracted episodic observations, a bounded semantic user model with lineage, and separately projected structured clinical state. Current enrichment can load into later sessions, but it does not guarantee complete recall or eliminate authoritative data retrieval. See [Functional Memory](/agent/memory.md).

**Metric**: A configured measure of interaction or operational evidence. **Evaluation metrics** can score eligible conversations against rubrics. **Operational metrics** aggregate supported workspace evidence through producer-specific paths; a definition does not imply that every channel or interaction produces a value. See [Metrics and Quality](/testing/testing/metrics.md) and [Metric Store](/intelligence-and-analytics/metric-store.md).

**Metric Store**: The Platform API's common value model and query surface for operational, quality, and evaluation metrics. The current catalog has 41 built-in definitions and accepts up to 50 custom definitions per workspace. The schema contains five extraction modes, but supported custom modes have narrower rules. Latency tiers and freshness values describe intended processing and configured targets, not contractual delivery times. See [Metric Store](/intelligence-and-analytics/metric-store.md).

**Modality Adapter**: A channel-specific boundary that converts supported input into typed signals and translates reasoning-engine effects into channel behavior. Voice, SMS text, and simulation are current examples; each retains its own delivery, lifecycle, authorization, and failure semantics.

## O

**Operator**: An authorized human who can monitor eligible live runs and, for supported channels, listen, guide, take over, or hand control back. Run-scoped transcript and context can be available, but operator entry is not a guaranteed complete patient briefing or proof that a downstream handoff succeeded.

**Outbound Task**: A world-model entity used for scheduled outbound voice work. Supported actions or workflows write an `outbound.scheduled` event, asynchronous projection makes the task visible to the dispatcher, and the dispatcher selects eligible due tasks. Event acceptance, projection, dispatch, call completion, and recipient delivery remain separate milestones.

## P

**Persona (Agent)**: The conceptual identity and background carried by an agent version, including structured identity, background text, behavioral guidance, and communication patterns. The current Platform API does not expose the retired standalone persona resource; services resolve an agent version through version-set configuration. See [Agent Core](/agent/agents.md).

**Persona (Simulation)**: A synthetic user profile used in simulations. Defines the characteristics, behaviors, and communication style of a test user. See [Simulations](/testing/testing/simulations.md).

**Platform Function**: A workspace-registered, read-only SQL, AI, Python, or table-valued computation. Supported runtimes can expose named functions (`fn_*`) and workspace data queries (`wsq_*`) after successful loading and any applicable Context Graph binding. Management is available through workspace-scoped APIs and supported tooling. See [Platform Functions](/agent/platform-functions.md).

**Pre-Emptive Tone Adjustment**: A supported voice fallback that can select sympathetic delivery when no emotion-derived tone is available and the current Context Graph action matches a configured sensitive topic. This is delivery guidance, not a prediction that the caller is distressed or an independent safety control.

**Projection Function**: Downstream logic that folds world-model events into a current read model for an entity type. Projection is asynchronous from event acceptance, so a successful write can precede visibility in the serving projection.

## Q

**Quality Score**: Context-dependent call evidence. The terminal operational quality score runs from 0-100 and reflects latency, silence, barge-ins, loops, operator escalation, and tool failures. Optional recording-based post-call analysis separately scores five rubric dimensions from 1-5. See [Call Intelligence](/intelligence-and-analytics/intelligence/call-intelligence.md).

## R

**Reasoning Engine**: The modality-independent pipeline at the core of the agent engine. It processes signals through perceive, reason, and act stages, navigating the Context Graph, executing eligible tools, and emitting effects. Streaming delivery supports voice, while completed-effect processing serves supported text, simulation, and API consumers. See [Reasoning Engine](/agent/reasoning-engine.md).

**Review Queue**: Private-preview interface for authorized reviewers to approve or reject a specific proposed write to an external system. A decision authorizes or blocks that mutation; it does not change the source event's confidence.

## S

**Scenario (Simulation)**: A defined situation used in simulations. Describes the context, events, and goals for a test interaction. See [Simulations](/testing/testing/simulations.md).

**Service Binding**: The association between a channel use case and a platform service. Binding is the act that enables the channel for the workspace. Rebinding replaces the prior binding. Unbinding turns the channel off.

**Service Voice Configuration**: Per-service voice tuning that controls filler behavior (style, vocabulary, timing), barge-in sensitivity, response length limits, end-of-turn detection, TTS settings, and call forwarding. Different services within the same workspace can have different voice characteristics. Managed through the Platform API and Agent Forge CLI.

**Signal**: An input primitive to the reasoning engine representing something that happened in the conversation. Signal types: utterance (user said something), emotion (emotional state update), tool result (tool execution completed), silence (user inactive beyond threshold), barge-in (user interrupted agent), external event (operator guidance, surface submission), system (timeout, error, connection state). All modality adapters normalize input into these signal types before passing to the engine.

**Silence Monitor**: The voice-runtime component that detects caller inactivity. It uses backoff thresholds of 10, 20, and up to 40 seconds, then generates a brief goodbye and ends the call after the third unanswered threshold.

**Simulation Bridge**: An exploratory testing mode that generates scenario variations from a natural-language objective, runs each as a full multi-turn conversation with an LLM-driven persona, and collects interaction insights for coverage tracking. See [Simulations](/testing/testing/simulations.md).

**Skill**: An orchestrated companion definition configured through the Platform API. A skill declares a required system prompt, input and result schemas, model and execution bounds, and the integration or static tools it may call. The Platform API does not expose a five-tier skill model. See [Skill Execution](/agent/platform-functions.md#skill-execution).

**Speaker Normalization**: Per-call acoustic calibration that reports recent voiced-audio features relative to the caller's running baseline after enough evidence is available. Relative features reduce dependence on population averages, but they do not make emotion classification definitive. See [Emotion Detection](/channels/voice/emotion-detection.md).

**Surface**: A dynamic or template-based data collection interface that can be delivered by email or handed off as a web link. Eligible agent tools and configured state templates can create surfaces; creation, delivery, submission storage, event publication, and downstream mutation remain separate lifecycle steps. See [Surfaces](/channels/surfaces.md).

**SurfaceSpec**: The structured specification an agent generates to define a surface - title, fields, delivery channel, expiration, and entity association.

## T

**Test Run**: The execution of a test set that produces scored results for each unit test. See [Simulations](/testing/testing/simulations.md).

**Test Set**: A group of related unit tests that are run together. Test sets are often organized by capability area or risk level.

**Tone Momentum**: Voice behavior that retains the previous successfully derived emotion tone when a later acoustic turn is weak or unmapped instead of resetting immediately. It applies only to emotion-derived delivery; navigation and configured workspace tone can still take precedence.

**Transcript Extraction**: In the current Platform memory flow, asynchronous model-based processing can derive source-linked episodic observations and registered behavioral memory dimensions from a completed conversation. It does not automatically convert phone, date-of-birth, insurance, or address mentions into authoritative structured clinical state; explicit tools and connector projections have separate write semantics.

**Trigger**: A workspace-scoped automation that binds an action to a cron schedule or supported platform event. Triggers support event filters, timezone-aware scheduling, pause/resume lifecycle, manual firing for testing, and execution history tracking. Managed through the Platform API, Developer Console, and Agent Forge CLI.

## U

**Unification Engine**: The transformation layer through which supported inbound connectors can map raw records into world-model events using configurable rules, including dot-path extraction for nested source data. New vendor protocols or operations can still require connector-specific support.

**Unit Test**: A combination of a persona, a scenario, and success criteria that tests a specific agent behavior.

## V

**Version Set**: A named service configuration that can pin agent and context graph versions, model preferences, and a supported turn runtime. Platform services require a `release` version set; omitted version numbers resolve to the latest available version. Classic version sets have a different component model.

## W

**Webhook Connector**: A push-oriented data-source mode for supported external integrations. Request verification, resource retrieval, retry handling, and duplicate suppression depend on the connector path; do not assume universal content-hash deduplication.

**Workspace**: A container in the Platform API that groups related skills, agents, and configurations for a specific deployment context.

**Workspace Data Query**: A parameterized SQL template registered per workspace that runs directly against workspace-owned custom tables. Exposed to the agent as a `wsq_<name>` tool with typed parameters and write-time validation. See [Platform Functions](/agent/platform-functions.md).

**World Model**: The platform data layer that retains source-attributed events and asynchronously projects supported current-state views. Agents receive selected context and can use authorized tools for additional retrieval; the model is not a guarantee that every source or current fact is present in one session payload.

**Write Scope**: A server-constructed boundary that limits the workspace, entity, resource types, creation rights, and confidence available to supported model-originated write tools. Trusted services use separate service authorization; their access does not let an agent tool bypass its own scope.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## 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, and the optional `goal` query parameter:

```
GET https://docs.amigo.ai/reference/glossary.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

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.