Skip to main content
The Corti Agentic Framework adopts a multi-agent architecture to power development of healthcare AI solutions. As compared to a monolithic LLM, the Corti Agentic Framework allows for improved specialization and protocol-based composition.
This page provides an overview of the systems and services that are supported by the AI Agent, as well as some fundamental definitions. Please refer to the other pages in this space and the full API specification for more information.

​
Benefits of a Multi-agent System

  • Each agent is minimal in scope, trained or prompted to perform a constrained set of reasoning steps.
  • Communication between agents is explicit, typed, and protocol-bound (A2A for reasoning-to-reasoning, MCP for reasoning-to-tools).
  • Agents can be reasoners, tool providers, or hybrids, but agents are not tools — a reasoning agent may call multiple tools over its lifecycle without being reducible to a single function.
  • The orchestration layer enforces stateless reasoning agents with ephemeral lifetimes; all intermediate state is persisted centrally, not in the agent process.
  1. Context collapse: The more roles and tools a single agent handles, the higher the prompt entropy and the lower the reasoning reliability.
  2. Coupling between reasoning and tooling: Single agents tend to entangle reasoning logic with tool invocation logic, making both brittle.
  3. Scaling bottlenecks: Expanding capability requires re-prompting, re-tuning, or increasing context windows, rather than attaching specialized, isolated capabilities.

​
Orchestrator

The Orchestrator is the central intelligence layer of the AI Agent system that interacts with users and manages the flow of conversations or tasks. It does not perform specialized work itself but delegates to the appropriate Expert. It is a stateless API layer per tenant namespace, with pluggable persistence for state (Postgres, Redis, etc.), ensuring data isolation and horizontal scaling.

Orchestrator is the only component aware of the following key details:

Thread stateA canonical, persistent record of all agent calls, tool calls, intermediate outputs, and contextual injections.
Client interfaceUser-facing API surface for initiating threads, injecting additional context, and retrieving results.
Expert registryDynamic discovery and registration of MCP-compliant agents (Experts). Maintains metadata, capabilities, and versioning.
Execution graph constructionTranslates a user request into an execution plan across multiple reasoning agents and tools.
GuardrailsRuntime validation of requests and responses, with policy-driven rejection or escalation. Includes hard constraints (schema validation, allowed tool sets) and soft constraints (model-based harmful content detection).

​
Reasoning Service

A Reasoning Service is any service that:
  • Accepts an A2A Task Object.
  • Produces a valid A2A Task result or sub-task request.
  • Implements domain-specific reasoning over one or more tools.
  • Idempotent and able to be replayed given the same task input.
  • May be stateful or stateless depending on the goals of the Agent reasoning service.
Typical instantiation: 
POST /call
Content-Type: application/json
Authorization: Bearer <token>
Body: { "a2a_task": { ... } }

​
Experts = MCP + Reasoning Service

An Expert is a modular, domain-specific agent that performs specific tasks. Each Expert encapsulates one or more tools, APIs, or models specific to its function.
  • The model context protocol (MCP) layer exposes tool metadata (list_tools) and execution (execute_tool) in standard MCP schema.
  • The reasoning layer decides when and how to call these tools, potentially chaining multiple tool calls before returning.
  • Some Experts expose a response pseudo-tool to allow direct end-user replies without Orchestrator post-processing (useful for short-circuiting when an intermediate agent has terminal output).
Benefits
EncapsulationTool protocol logic is separate from reasoning prompts/weights.
ReplaceabilitySwap MCP server or reasoning layer independently.
ParallelismMultiple Experts can execute in parallel if dependencies are resolved.
Heterogeneous reasoningReasoning can be LLM-based, symbolic, or programmatic without changing the orchestration contract.

​
Tool Providers

Tool Providers may be:
  • Pure MCP servers (e.g., FHIR data fetcher, medical coding API).
  • Wrappers over non-MCP services with schema translation.
  • Hybrid providers that extend MCP spec for advanced capabilities (streaming responses, structured multimodal input).
All Tool Providers:
  • Implement list_tools and execute_tool endpoints.
  • Must be callable by any agent.
  • Are stateless (i.e., stored in memory) with tool execution being in the relevant target system.

​
Dataflow

1

Client → Orchestrator

Thread initiation with task payload and optional context injections.
2

Orchestrator → Reasoning Service

A2A request with task definition, constraints, available Experts.
3

Reasoning Service → Tool Provider

MCP tool calls to retrieve or mutate domain data.
4

Reasoning Service → Orchestrator

A2A return with results, new sub-task requests, or terminal output.
5

Orchestrator → Client

Final aggregated result or streamed partials.

​
Why This Works in Practice

Protocol separationA2A for agent coordination, MCP for tool execution. Minimizes protocol scope creep.
Stateless computeReasoning services scale horizontally with no warm-state concerns.
Strong typing & validationAll cross-service messages are JSON Schema–validated.
Replaceable layersMCP servers, reasoning services, and Orchestrator can evolve independently.
Developer autonomyThird parties can author Experts without touching orchestration code—just expose MCP and wrap in a reasoning layer.

Please contact us if you need more information about the Corti Agentic Framework.