Skip to main content
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, 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: 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 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, 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 for details on SSE streaming.

​
Observability

The Agentic Framework provides two observability surfaces:
  • Traces: OpenInference-format traces for each context, showing spans for LLM calls, connector invocations, and tool usage. Useful for debugging and performance analysis.
  • 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 model. The memory concept is formalized as contexts with their own API endpoints.
The v1 Orchestrator page is preserved in the v1 archived documentation.

​
Next steps