> ## Documentation Index > Fetch the complete documentation index at: https://docs.corti.ai/llms.txt > Use this file to discover all available pages before exploring further. # System architecture > Learn how the Agentic Framework's agent runtime receives requests, routes through connectors, and returns results. The Agentic Framework uses an agent runtime architecture to power AI solutions. Instead of a monolithic LLM, the runtime coordinates between connectors, contexts, and the reasoning layer to deliver specialized, safe, and auditable results. ## Architecture overview Diagram illustrating the Agentic Framework architecture, showing the agent runtime, connectors, and contexts and how they interact. The architecture consists of three core components: * **Agent runtime**: The central reasoning layer that receives user requests, plans steps, selects and invokes [connectors](/agentic/connectors), and generates responses * **Connectors**: Typed integrations that provide tools and data sources to the agent. Connectors replace v1's experts, MCP servers, and sub-agents with a unified model * **[Contexts](/agentic/context-memory)**: Maintain persistent conversation state, enabling the agent to make informed decisions and ensuring continuity across messages Together, this architecture enables complex workflows through protocol-based composition while maintaining strict data isolation and stateless reasoning. ## Request flow When you send a message to an agent, the following flow occurs: 1. **Message received**: The A2A server receives the message via the HTTP+JSON or JSON-RPC binding 2. **Context resolution**: The server resolves or creates a [context](/agentic/context-memory) to scope the conversation 3. **Reasoning and planning**: The agent runtime analyzes the request and determines which steps to take 4. **Connector selection**: The runtime decides which connectors to call, in what order, and with what data 5. **Connector invocation**: Selected connectors are invoked to retrieve information or perform actions 6. **Response generation**: The runtime aggregates results from connectors and generates the final response 7. **Response returned**: The client receives either a `Task` (for long-running work) or a `Message` (for quick responses) ## What the agent runtime does The agent runtime is the central intelligence layer. Its core responsibilities include: * **Reasoning and planning**: Analyzes user requests and determines the necessary steps to complete them * **Connector selection**: Decides which connectors to call, in what order, and with what data * **Task decomposition**: Breaks complex requests into discrete steps that can be handled by individual connectors * **Response generation**: Aggregates results from connectors and generates the final response * **Context management**: Has access to the [context](/agentic/context-memory), ensuring continuity across the conversation * **Safety enforcement**: Enforces guardrails, type validation, and policy-driven constraints to ensure safe operation in production environments The runtime does not perform specialized work itself. Instead, it delegates to appropriate connectors and coordinates their activities to accomplish complex workflows. ## Interaction mechanisms The A2A protocol supports two interaction patterns: * **Request/response**: You send a message and wait for the response. For long-running tasks, you can poll the task endpoint for status and results. Use `message:send` with `configuration.returnImmediately: false` (the default) for this pattern. * **Streaming with Server-Sent Events (SSE)**: You open an SSE stream to receive incremental updates in real time. Use `message:stream` for streaming a new message, or `tasks/{id}:subscribe` to stream updates for an existing task. The server writes event IDs but does not yet read the `Last-Event-ID` header, so resumption without gaps is not yet implemented. See [Stream responses](/agentic/guides/stream-responses) for details on SSE streaming. ## Observability The Agentic Framework provides two observability surfaces: * **[Traces](/agentic/guides/export-traces)**: OpenInference-format traces for each context, showing spans for LLM calls, connector invocations, and tool usage. Useful for debugging and performance analysis. * **[Usage](/agentic/guides/view-usage)**: Aggregated usage metrics per agent, including invocations, unique contexts, and token consumption. Useful for cost tracking and capacity planning. ## What changed from v1 In v1, the architecture was described as an "Orchestrator + Experts + Memory" triad. The orchestrator was a separate concept that delegated to specialized experts and MCP servers. In v2, the orchestrator is the agent runtime, and experts, MCP servers, and sub-agents are all unified under the [connectors](/agentic/connectors) model. The memory concept is formalized as [contexts](/agentic/context-memory) with their own API endpoints. | v1 concept | v2 equivalent | | ------------ | -------------------------------- | | Orchestrator | Agent runtime | | Experts | `registry` connectors | | MCP servers | `mcp` connectors | | Sub-agents | `agent` connectors | | Memory | Contexts (first-class resources) | The v1 Orchestrator page is preserved in the [v1 archived documentation](/agentic/v1/orchestrator). ## Next steps * Learn about [connectors](/agentic/connectors) and the five connector types * Read about [contexts and memory](/agentic/context-memory) * Understand the [A2A protocol](/agentic/a2a-protocol) and its two bindings