What an agent actually is

When people say they are “using AI”, they usually mean a chat: you type, a model replies, you read. Useful, but it is one model call. An agent is a different thing, and the difference is not the model. It is everything wrapped around it, and it is the wrapping we spend our days building.

01What an agent is

For two years the industry could not agree on what “agent” even meant. That argument has mostly settled. Simon Willison, after collecting hundreds of definitions, landed on a plain one: “an LLM agent runs tools in a loop to achieve a goal.” Anthropic uses almost the same words, “LLMs autonomously using tools in a loop”, and draws the sharp line in its widely read Building Effective Agents: a workflow follows predefined code paths, while an agent is a system where the model “dynamically direct[s] their own processes and tool usage, maintaining control over how they accomplish tasks.”

Read that back. A chat is request and response. An agent is goal, plan, act, observe, repeat, and the model, not you, decides the next step.

A system is more “agentic” the more an LLM decides how the system can behave. Harrison Chase, LangChain · “What is an AI agent?”

Chase frames it as a dial rather than a badge. Andrew Ng makes the same point from the other side, that there are “different degrees to which systems can be agentic.” A bare chat sits at zero on that dial. Hand the model tools, memory, and a loop and it climbs.

The whitepaper puts the inside cleanly: a model (the brain), tools (the hands that reach the outside world), and an orchestration layer (the loop that runs think, act, observe). Weng adds two more parts everyone now takes for granted: planning (break the goal into steps, reflect, correct) and memory (hold context across steps, not just one message). The model is necessary and nowhere near sufficient.

02The ladder we actually climbed

None of this arrived as a single decision. Like most teams, we climbed a ladder, and the rungs are worth naming because you can locate yourself on them.

Rung one was copy-paste: answer in the chat, code into the editor, human does all the wiring. Rung two was inline completion, the editor finishing the line. Rung three is the one most teams live on now, a back-and-forth conversation with the model until the change is right. Rung four is where it gets interesting: you point an agent at a goal and let it run, write, test against the spec, read the result, fix, repeat, until a finish condition is met. This is the loop, and Calvin French-Owen, who worked on OpenAI’s Codex, names the constraint that governs it: “the agent is doing next token prediction, and each token must fit in a context window. To use coding agents well, you must understand context.”

We formalised this ladder because we sell it. Internally our stages run Supervised, then Co-Author, then Spec-First, then Autonomous Routine, then a narrow Selective Autonomy, and teams climb them over quarters, not weeks. The key point at every rung: you are still in the loop. What changes is where you stand in it.

03Why the layers are the whole point

Here is the part that decides whether any of this is safe to run in a business. A chat that gives a wrong answer wastes a minute. An agent that acts can open a pull request, move data, or touch production. The moment a model can do things, you need layers a chat never required: what it is allowed to touch, proof that it works, and a record of what it did.

That outer ring is what we build. We do not build the model and we do not build the coding agent. We build the skill (the capability an agent is given), the policy (what it is permitted to do), the evals (evidence it does the job), and the audit trail (proof, after the fact, of every action). In our platform an agent is literally the binding of those things: a signed bundle of skill, policy, evals, a manifest, and a trigger, none of which a generic runtime carries.

The product is the boundaries. The product is the controls. Permissions and approvals and limiting the scope of your API integrations, having audits and reporting and logs and alerts. Jake Stauch, Serval · Sequoia Training Data, May 2026

This is not an idiosyncratic view. James Everingham, formerly of Meta and now building an AI control plane, said the same on Dev Interrupted: “you need to be able to understand what these agents are doing in your infrastructure instead of just give them access to everything and let them yolo it.” And Simon Willison, writing on designing agentic loops, is blunt about why: “agents are inherently dangerous, run your agent in a secure sandbox, if a credential can spend money, set a tight budget limit.” We do exactly that. Every unit of work runs in its own throwaway sandbox, a policy decision is checked before any tool call fires, and an over-budget call just stops.

04Onboarding an agent, and keeping it current

Two things quietly decide whether an agent is any good, and neither is the model.

The first is onboarding: what context you give it. Harrison Chase calls this context engineering and puts the failure mode plainly: “most of the time when an agent is not performing reliably the underlying cause is that the appropriate context, instructions and tools have not been communicated to the model.” For us onboarding a capability means writing a skill in the open Agent Skills format, pairing every feature with a verification spec before any code is written, and, for routine agents, an eval suite that stands in for that spec. A partner’s own domain expert can author one through a wizard: skill, then evals, then policy, then connectors, then autonomy level, then publish. A check runs before it is signed so the policy and the autonomy level cannot contradict each other.

The second is staying current. Anthropic’s context-engineering work describes “context rot”, the way a model’s recall degrades as the window fills, and the fixes: compaction, and “structured note-taking, or agentic memory” written outside the window.

The bottleneck for making these models more useful these days is not really raw intelligence, but understanding new and evolving contexts. Jessy Lin, Engram · Sequoia Training Data, June 2026

Our agents carry a memory that accumulates across runs and a consolidation step that turns each run into memory and candidate skills, and a candidate only graduates once it clears its eval bar. Learning here is accumulation and retrieval, never retraining the model. When a skill or an eval suite changes, the agent re-certifies against its level before it ships.

05Context is not only the company

The context that shapes an agent is not just your codebase and your house style. It is the regulatory environment it operates in, and that is a first-class input, not a footnote. In our healthcare-staffing pack the agent runs the actual labour rules inline, registration validity, the collective-agreement rest and hours caps, and any pairing that trips a blocking rule is surfaced as “needs review”, never auto-confirmed. A regulated tenant can set a stricter floor as policy that applies everywhere.

This is where the audit layer earns its place. Harrison Chase, writing on agent observability, makes the point that governance rests on: “you don’t know what your agents will do until you actually run them, agent behaviour only emerges at runtime.” So we capture it at runtime. Every gate decision and action becomes an immutable, content-blind record, the field that changed and the policy version, never the private data itself, built so an EU AI Act high-risk audit can reconstruct what happened.

06What success looks like, and a way to start

Success is not “we adopted AI”. LinearB’s 2026 benchmark found AI-assisted pull requests merging at 32.7 percent, less than half the rate of human ones, and its team put the warning cleanly: “don’t confuse adoption with impact.” Ori Keren, its CEO, sharpened it: “we’re generating 2X more code, but the gains are somewhere between 10 to 15 percent.” Success is an agent whose work actually ships and holds up. Anthropic’s eval guidance gives a usable test for “good”: a task where “two domain experts would independently reach the same pass/fail verdict”, and failures that “seem fair”. Harrison Chase offers the honest shape of it: agents “aren’t reliable to nine nines”, but pointed at long-running work that produces “a first draft of something”, they are the killer application.

The honest caveat is worth stating. Logan Kilpatrick of Google DeepMind argues that “the model eats the harness”, that scaffolding running ahead of the model today gets absorbed into it tomorrow. He is right about the mechanical scaffolding. But the model does not absorb your permission boundary, your evidence that it met your standard, or the record a regulator will ask for. Those are the layers that survive the next model, and the harness layer around production agents has been getting bigger, not smaller.

So the next time someone says they have “an AI agent”, the useful question is not which model. It is: what tools, what memory, what loop, and who governs it. The model is the easy part. The agent is everything around it.

Which layer do you think is hardest to get right in production?