# What is an 'agent'? A class/instance definition, updated with the 2026-07-28 MCP spec

## Industry standards

In the Gen AI / LLM space, two standards have emerged as the de facto choice in their domains:

* **A2A** (v1.0, Linux Foundation) defines how agents integrate and communicate with their peers. It defines the *interface* of an agent, but not the agent itself.
* **MCP** (2026-07-28 spec, finalizes today) defines how an agent uses tools. It defines the *internal plumbing* of an agent, but not the agent itself.

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.

## Prior art (and why it is not enough)

"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.

## The definitions

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:

* **the host loop** — the core. The LLM deciding actions, observing results and iterating. Without a loop you have a chatbot with tools, not an agent.
* **system context** — persona, instructions. Static and authored.
* **MCP server set**
* **capability boundary / tool policy** — which servers and tools this agent *may* use, and what needs approval. This is a role, not a login.
* **LLM** — the actual model we are using
* **termination limits** — max iterations, token budget, stop conditions
* **task contract** — the schema of what this agent accepts and what it must return
* **context-size strategy** — compaction vs top-x
```csharp
record AgentDefinition(
    HostLoop Loop,
    SystemContext Context,
    McpServerSet Servers,
    CapabilityBoundary Capabilities,
    Model Llm,
    TerminationLimits Limits,
    TaskContract Contract,
    ContextStrategy Strategy);
```

An agent is an instance of that class. In C# terms:
* **goal** — what the user actually asked
* **working context window** — conversation history, tool results
* **credentials** — the principal: whose OAuth tokens, on whose behalf. Two instances of the same definition, running for two different users, differ only here.
* **consumed budget** — iterations elapsed, tokens spent
```csharp
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.

## Enter the 2026-07-28 spec, or more precisely: the stateless core

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 paused 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:

* **compressible context** — conversation history, safe to compact
* **load-bearing context** — outstanding handles and request state, never compacted

The host loop also stops being free-form. It must now support:

* the multi-round-trip pause — a tool call returns input-required plus request state; the loop surfaces the question and re-issues the call with the answer
* task polling (`tasks/get`)
* unsolicited task handles arriving in results

## Serializable Agents

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?