In the Gen AI / LLM space, two standards have emerged as the de facto choice in their domains:
One nuance to be fair to both: MCP can also act as an agent's public interface, when an agent is exposed as an MCP server inside a single trust domain. So A2A covers the cross-organization contract, and MCP covers everything inside it. Either way, the conclusion stands: neither protocol defines what an agent is.
To me it seems the terms 'agent' and 'agentic' are still not well defined, and this article is my attempt at an operational definition: one precise enough that you could build a host around it. That claim is not hypothetical — I am building an MCP host, and this definition is what fell out of that work.
"An agent is an LLM using tools in a loop" (Anthropic's framing) is directionally right, but it is not operational: it does not tell you what belongs in your agents.json
. The academic definitions (rational agents, BDI, FIPA) predate LLMs and do not map to context windows, token budgets or MCP servers. I want something in between: a definition you can serialize.
Scope: this is a definition for agents that live in an MCP host. Frameworks like LangGraph organize things differently, but I believe the same components show up under different names.
I split the concept in two parts, like a class and its instances. Both live in the MCP host. From here on: an agent definition is the class, an agent is the instance.
The agent definition consists of:
An agent is an instance of that class. In C# terms:
record AgentDefinition(
HostLoop Loop,
SystemContext Context,
McpServerSet Servers,
CapabilityBoundary Capabilities,
Model Llm,
TerminationLimits Limits,
TaskContract Contract,
ContextStrategy Strategy);
record Agent(
AgentDefinition Definition,
AgentTask Goal,
ContextWindow WorkingContext,
Principal Credentials,
Budget Consumed);
Note the symmetry: the definition holds limits, contracts and capabilities; the instance holds counters, goals and credentials. Static in the class, dynamic in the instance.
The new MCP spec removes protocol sessions entirely. A server no longer remembers you between calls. All state now travels in explicit handles that the model itself can see: task handles for long-running work, workflow ids, and the requestState
blob a d call hands back.
This breaks my 'working context window' as defined above. Those handles land in the context window, which means compacting — or worse, top-x-ing — becomes a correctness concern instead of a cost concern. Summarize away a task handle and the agent has orphaned remote work it can never resume, because the stateless server has no session through which to remind it.
So the instance needs a split:
The host loop also stops being free-form. It must now support:
tasks/get
)Here is where the stateless core points. If instance state is exactly {goal, context, handles, credentials, consumed budget}, and the protocol holds no hidden session on your behalf, then an agent is a serializable value. You can suspend it, persist it, and resume it in a different host process. Not a running process you must keep alive — a record you can store.
Production reality will take a while to catch up (connection reuse, servers caches, ...), but the direction is set by the spec itself.
I'm looking for feedback on this — especially from people running MCP hosts in production: what is in your agent config that this definition misses?