How an "everything is a plugin" architecture reframes what an AI agent actually is — and what it teaches builders of any agent stack.
1. The Agent Is More Than the Model
There's a persistent shorthand in agent engineering: take a capable LLM, give it a system prompt and a handful of tools, and call the result an "agent." That shorthand works for demos. It falls apart the moment an agent needs to run for more than a few minutes, survive a restart, call a sub-agent, recover from a failed tool call, or let a human inspect what it actually did three hours ago.
Once you cross that line, an agent needs a lot of infrastructure that has nothing to do with the model itself: a place to execute tools safely, a way to keep state across turns, a policy for what context the model sees on each call, a mechanism for delegating work to other agents, a sandbox to contain what the agent can touch, a way to recover from partial failures, and a record of what happened that a person — or an evaluation harness — can replay later.
Collectively, this surrounding machinery is often called the agent harness: the runtime that sits between the model and the world, and that actually determines how the agent behaves in practice. Two agents built on the same underlying model can behave completely differently depending on the harness wrapped around it — how it manages context, what tools it exposes, how it recovers from errors, and how it schedules work.
