This page visualizes the system architecture of the Corti Agentic Framework. Please review the full API specification for details.
Architecture Components
The Agentic Framework is comprised of three central components:| Component | Description | Context |
|---|---|---|
| Reasoning service | A stateless service that is given a task, context, available tools and resources and is expected to respond with what it deems should be the next step towards completing the task. | The simplest case would be a wrapper around an LLM with a specific prompt that guides the LLM to completing certain tasks; however, any service that meets the requirement above can be a reasoning service. |
| Tool provider | A configured service that provides a list of tools and their requirements in a standardized format (e.g., MCP), and, assuming the requirements are fulfilled, is able to execute the usage of a tool and return the result. | This could be a MCP server directly, a wrapper around an existing MCP server that extends it, or a wrapper around a non-MCP resource that adapts it to our requirements. |
| Orchestrator (Agent API) | Acts as a link between the user, the reasoning services and the tool providers. It stores and manages thread state, passing data and call commands between components (including the user). | Manages thread state in persistent storage, sends requests and receives responses from both reasoning services and tool providers. |
Communication Protocols
Specific communication protocols are used according to the task at hand:| Protocol | Task |
|---|---|
| Agent API | Thread-based API for invoking agents. |
| Agent2Agent (A2A) Protocol | Communication between agents and sub-agents in accordance with the standard specification. Primary information exchanged is the task designated to the (sub)agent (A2A server) and the results or further requests from the agent to the A2A client. |
| Model Context Protocol (MCP) | Agent internal tool calls. These are the individual tool calls performed by the (sub)agent to complete the task it is given. |
| Storage API | An internal API available to all sub(agent) services to store task related state so that each (sub)agent does not store state within themselves, but rather push it to the backend. |
While all tool providers can function as MCP servers, not all MCP servers can function as tool providers.
The Three Perspectives
The Corti Agentic Framework can be considered from three perspectives, each providing different context for the system:| Perspective | Relevance | Construct | Benefits |
|---|---|---|---|
| Experts | AI reasoning | An Orchestrator has the ability to call sub-agents for specific tasks. These sub-agents have Experts at their availability to complete their tasks and report back to the Orchestrator. | Each sub-agent and Expert is focused on a specific task or purpose, making them fast. The hub-and-spoke network create powerful daisy-chain reasoning capabilities. |
| Architecture | Data flows | The Orchestrator sits between the components and the user, validating each step, each Expert or sub-agent call. | Ensuring that each component is operating within the defined guardrails as it generates new data or takes actions. Additionally, the Orchestrator Backend is tasked with thread management: Saving the current user state after each step of the execution. |
| Platform | Infrastructure deployment | Hosted- or sovereign-cloud deployed multi-tenant environments, where some resources are shared and others are tenant-specific. | Maintain AI infrastructure that is secure, scalable, extensible, cost efficient, and reliable. |
The Orchestrator also serves as the guardrail against any malformed or dangerous requests by the reasoning services, and it ensures that requirements are met for the tool providers.
Bringing it All Together
Working through the above results in the following view of the Agentic Framework:
Please contact us if you need more information about the Corti Agentic Framework.