What an agent actually is

2026-07-09T00:00:00+00:00

Field notes · Becoming AI-native</p>

What an agent actually is</h1>
A chatbot answers. An agent acts.</b> Almost everything that matters for a business sits in the gap between those two sentences.</p>
Mik Nijhuis</span></span> 14 July 2026</span></span> 9 min read</span> </p> </div>

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.</p>
01</span>What an agent is</h2>
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.”</a> 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>: 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.”</p>
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.</p>
A system is more “agentic” the more an LLM decides how the system can behave. Harrison Chase, LangChain</b> · “What is an AI agent?”</cite> </blockquote>
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.</p>

Tools</text> Memory</text> Planning</text> Loop</text></p>
Skill</text> Policy</text> Evals</text> Audit</text></p>
GOVERNED LAYER · what we build</text> THE RUNTIME</text> </svg></p> </div>
A chat is the center dot. An agent is the whole diagram.</b> Google and Kaggle’s “Introduction to Agents” describes the inside (model, tools, orchestration); OpenAI’s Lilian Weng adds planning and memory. The outer ring is the part we build.</figcaption> </figure>
The whitepaper puts the inside cleanly: a model</strong> (the brain), tools</strong> (the hands that reach the outside world), and an orchestration layer</strong> (the loop that runs think, act, observe). Weng adds two more parts everyone now takes for granted: planning</strong> (break the goal into steps, reflect, correct) and memory</strong> (hold context across steps, not just one message). The model is necessary and nowhere near sufficient.</p>

</th> A chat</th> An agent</th></tr> </thead>

Interaction</th> Request, then response</td> Goal, then plan, act, observe, in a loop</td></tr>
Control</th> You decide each next step</td> The model decides the next step</td></tr>
State</th> One message, stateless</td> Memory across steps</td></tr>
Reach</th> Words only</td> Tools: code, APIs, files, systems</td></tr>
Ends when</th> You stop typing</td> A stop condition is met</td></tr> </tbody> </table> </div>
02</span>The ladder we actually climbed</h2>
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.</p>

More autonomy left to right. You stay in the loop; what changes is where you stand in it.</b> By rung four you stop typing the change and start approving, or vetoing, the pull request the agent opens.</figcaption> </figure>
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.”</a></p>
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.</p>
03</span>Why the layers are the whole point</h2>
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</em> 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.</p>
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</strong> (the capability an agent is given), the policy</strong> (what it is permitted to do), the evals</strong> (evidence it does the job), and the audit</strong> 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.</p>
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</b> · Sequoia Training Data, May 2026</cite> </blockquote> 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.”</a> And Simon Willison, writing on designing agentic loops</a>, 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.</p>

The loop is the agent. The gates are why you can leave it running.</b> A policy check before an action fires, an eval check before anything irreversible, an audit stamp on every step, and a human approve or veto at the pull request.</figcaption> </figure> 04</span>Onboarding an agent, and keeping it current</h2>
Two things quietly decide whether an agent is any good, and neither is the model.</p>
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.”</a> 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.</p>
The second is staying current. Anthropic’s context-engineering work</a> 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.</p>
The bottleneck for making these models more useful these days is not really raw intelligence, but understanding new and evolving contexts. Jessy Lin, Engram</b> · Sequoia Training Data, June 2026</cite> </blockquote>
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.</p>
05</span>Context is not only the company</h2>
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.</p>
This is where the audit layer earns its place. Harrison Chase, writing on agent observability</a>, 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.</p>
Why it matters</span> For a small team this is the whole business case for the layers: they are what let one person safely run work that used to need a team, without losing the trail a customer or a regulator will ask for.</b> </div> 06</span>What success looks like, and a way to start</h2>
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.”</a> 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</a> 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.</p>

A simple way to start</h3>
In order · reversible before autonomous</p>

Pick one narrow, valuable, reversible job.</b>Something a draft pull request or a proposal can carry, where a wrong answer is cheap to catch.</span></li>
Write the goal and the check first.</b>What it should do, and how you will know it did. The check is the spec.</span></li>
Give it a tight scope and a budget.</b>A sandbox, a short list of tools, a spend cap. Least privilege, not “access to everything”.</span></li>
Keep a human at the pull request.</b>Approve or veto. Autonomy is earned as the accept rate holds, not granted up front.</span></li>
Log every action from day one.</b>You cannot govern what you cannot replay.</span></li>
Let it learn, then re-check.</b>Feed back what worked, and re-run the evals before you widen the scope.</span></li> </ol> </div> The honest caveat is worth stating. Logan Kilpatrick of Google DeepMind argues that “the model eats the harness”</a>, 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.</p>
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.</p>
Which layer do you think is hardest to get right in production?</p>

Sources</h4>

Simon Willison, a widely agreed definition of “agent”</a> and designing agentic loops</a></li>
Anthropic, Building Effective Agents</a>, Effective context engineering</a> & Demystifying evals</a></li>
Harrison Chase / LangChain, What is an AI agent?</a>, The rise of context engineering</a> & agent observability</a></li>
Google & Kaggle, Agents whitepaper</a>; Lilian Weng, LLM Powered Autonomous Agents</a></li>
Jake Stauch, Rebuilding IT for the AI Age</a>; Jessy Lin, Memory and Continual Learning</a>; Logan Kilpatrick, Why the Model Eats the Harness</a> (Sequoia Training Data)</li>
LinearB Dev Interrupted, 2026 Benchmarks</a> & an AI control plane</a>; Calvin French-Owen, Coding Agents in Feb 2026</a></li> </ul>
</span>Aitonomy</span> Governance for AI workloads · EU-sovereign</span> </div> </div> </div> </div>

Aitonomy — Insights

What an agent actually is