What Is an AI Agent?
15 minute read
Most definitions of an “AI agent” describe what the agent can do: perceive, reason, call tools, pursue a goal. These notes argue that this is only half the picture. For any agent that acts in the real world, the more important question is who decides what it may do, and where that decision is enforced.
We develop two claims that the rest of the course builds on: an agent is a model plus a harness, and agency is not authority. To make the second claim precise, we borrow two mature fields that have studied delegation for decades: the law of agency and the economics of agency costs.
By the end of these notes you should be able to:
- explain the difference between a model and the harness around it, and say which parts of a system belong to which;
- distinguish agency (capacity) from authority (permission), and explain why a rule in a prompt is not a control;
- describe where an authority check must sit in an agent’s control flow, and what it decides;
- reason about the costs of delegating to an agent using monitoring, bonding and residual loss.
Consider a customer support agent (the course’s running example, the CSA) that can look up orders and issue refunds. Its operator has a simple policy: the agent may refund at most $50 on its own; anything larger needs a person. The policy is written into the agent’s system prompt, so the model “knows” it.
A customer asks for two refunds in the same session. The first is for $41.85, under the limit. The model proposes the refund; a deterministic check called the Gatekeeper compares the amount with the policy, allows it, and the refund executes and is recorded. Before the second request, the Gatekeeper is switched off. The customer asks for a $103.86 refund. The model proposes it in exactly the same way, and this time the money moves: nothing compared the proposal with the policy. The audit record marks the action UNGOVERNED.
| Run | Request | Gatekeeper | Outcome |
|---|---|---|---|
| 1 | Refund $41.85 (under the limit) | On | Proposed → allowed → executed and audited |
| 2 | Refund $103.86 (over the limit) | Off | Proposed → executed, recorded as UNGOVERNED |
The model, the prompt and the limit in the prompt were identical in both runs. Notice what this tells us: the refund in run 2 was not stopped by the model’s “knowledge” of the policy, and the refund in run 1 was not allowed because the model behaved well. In both runs, the decision that mattered was made, or not made, outside the model. The rest of these notes explains why that is the right design, and why it generalises.
The word comes from the Latin agere, “to do” or “to act”: an agent is, literally, a doer. Three definitions are worth keeping side by side.
- Russell and Norvig (Artificial Intelligence: A Modern Approach) define an agent as anything that perceives its environment through sensors and acts upon it through actuators. For a language-model agent, the context window plays the role of the sensor (it is everything the model perceives on a call) and tool calls are the actuators.
- Anthropic (Building Effective Agents, 2024) distinguishes agents, systems in which an LLM “dynamically directs its own processes and tool usage”, from workflows, in which LLMs and tools are orchestrated through predefined code paths. We study that distinction in detail in Workflow Design Patterns.
- In everyday usage, an agent is someone who acts on behalf of someone else: a travel agent, an estate agent, a sports agent.
The first two definitions describe capacity: what the system is able to do. Neither says anything about permission: what it is allowed to do, and on whose behalf. The third definition, the oldest, points at exactly that gap, and it is the one that matters once an agent can move money or data.
The first claim of the course is a decomposition:
\[\text{Agent} = \text{Model} + \text{Harness}\]The model, a large language model, is the part that reasons. On each call it reads whatever has been placed in its context window and proposes the next action, typically a structured tool call such as process_refund(order_id, amount).
It does not execute anything itself, it has no memory between calls, and it cannot see anything that is not in its window.
The harness is everything else. It decides what goes into the context window and in what order; which tools exist and with what schemas; what is remembered between turns; how many times the loop may run; which inputs are screened; who is permitted to do what; and what is written to the audit trail. Vivek Trivedy’s essay at LangChain puts it in one line: if you’re not the model, you’re the harness. Addy Osmani’s piece on harness engineering makes the practical consequence explicit: when an agent fails, the durable fix is usually in the harness, so the same mistake cannot happen again, rather than in the prompt.
This decomposition explains the motivating example. The Gatekeeper is part of the harness; switching it off changed the agent’s behaviour without changing the model at all. It also explains the structure of this course: loop control, context management, memory, hallucination checks, security and evals are all parts of the harness.
Read more about Large Language Models
Read more about The Transformer
The distinction between acting and being authorised to act is not new. The common law of agency has refined it for well over a century, and the Restatement (Third) of Agency (American Law Institute, 2006) summarises it.
Section 1.01 defines agency as the relationship that arises when a principal manifests assent that an agent shall act on the principal’s behalf and subject to the principal’s control, and the agent consents to act. The third element is the important one for us: control is not a feeling the agent has; it is something the principal can actually exercise.
Section 8.09 places a duty on the agent: an agent has a duty to take action only within the scope of the agent’s actual authority. Between people, we rely on the agent’s loyalty to honour that duty, and on courts to punish breaches afterwards. A language model has no loyalty to appeal to and cannot be sued. So the duty cannot be left to the agent; it has to be enforced mechanically, by the harness, before the act.
Several doctrines map directly onto parts of an agent harness:
| Doctrine | What the law says | Where it lives in an agent |
|---|---|---|
| Actual authority (§2.01) | The agent may do what the principal’s own words say is wanted | The agent’s policy, stored in a database the model cannot edit (e.g. the $50 limit) |
| Apparent authority (§2.03) | A third party believes the agent is authorised, and the belief traces back to the principal | Text in a chat or a ticket never grants authority |
| Ratification (§4.01) | The principal may adopt an unauthorised act afterwards | An over-limit refund is escalated, and a person may approve it |
| Duty of scope (§8.09) | Act only within actual authority | The Gatekeeper checks every proposal before it executes |
The law spent a century working out who may bind whom. We do not need to invent those rules; we need to compile them into code paths.
Why does delegating to an agent need any of this machinery? Because the agent knows things the principal does not, and does things the principal does not see.
The law’s answer to this is fiduciary duty (Restatement §8.01): someone trusted to act for another, such as a trustee, a lawyer or a company director, owes loyalty (no self-dealing), care (competence), obedience (following lawful instructions), and must stay within actual authority. These duties are enforced after the fact, through damages or losing a licence. None of those sanctions applies to a model.
Economics describes the underlying problem as information asymmetry, in two forms:
- Hidden action (moral hazard; Holmström, 1979): the principal cannot observe everything the agent does. A business deploying a support agent does not read each conversation.
- Hidden information (adverse selection; Akerlof’s “market for lemons”, 1970): the agent knows things the principal does not. The model reads customer text that nobody vetted, and sees context the principal never wrote.
The conclusion is the same in both fields: where the principal cannot see, it has to check. The harness is the mechanism that does the checking.
Agency law asks one question of every act an agent takes: does it bind the principal? There are four possible answers, and they give us a precise vocabulary for what an authority check can decide.
| Standing | Meaning | Example from the support agent | Gatekeeper verdict |
|---|---|---|---|
| Valid | Inside the agent’s authority | Refund $40 on the customer’s own order | ALLOW |
| Ratifiable | Outside authority, but a person may adopt it | Refund $120: waits for approval | ESCALATE |
| Voidable | Allowed, but can still be undone | An issued refund, before it settles | |
| Void | Never allowed; nothing can rescue it | Refund on someone else’s order | DENY |
The standing of an act is decided by the harness, not by the model. We return to these standings when we discuss security, evals (which check that each action ended up with the standing it should have), and resilience (where a voidable refund can be reversed).
If authority must be checked outside the model and before the act, where exactly does the check go? The answer follows from what the model produces. The model’s output is never an action; it is a proposal, a typed tool call. Between propose and execute we place the Gatekeeper: deterministic code that evaluates that exact proposal against the principal’s policy.

The checks run in order: is the agent enabled; was this tool offered on this turn; is the target record within the turn’s mandate (for example, does the order belong to this customer); is the actor allowed; does the role carry the authority; do the business rules pass (the refund limit); and, where relevant, a cumulative ledger across actions. There are three possible verdicts. ALLOW lets the tool execute. ESCALATE parks the action for a person, which is ratification in code. DENY returns a deterministic refusal that the model then explains to the customer.
Two properties make this a control rather than a request. First, the policy is read from the database, not from the prompt: the number may also appear in the prompt, but the prompt is not where the Gatekeeper gets it. Second, every decision is audited, so the principal can later see what was decided and why. We develop the Gatekeeper further in Guardrails, Loop Control & State and Agent Security.
Economics offers a second lens. Jensen and Meckling (1976) showed that whenever a principal delegates to an agent whose interests may diverge, the principal bears agency costs of three kinds.

- Monitoring costs are what the principal spends watching the agent. In an AI system these are traces, the audit ledger and observability.
- Bonding costs are what it costs to bind the agent to commitments it cannot break: typed tool schemas, guardrails, the Gatekeeper.
- Residual loss is the divergence that gets through anyway. It is never zero; evals measure it and a human review queue caps the worst of it.
An honest caveat: an LLM has no self-interest in the way a manager does. But it does have divergent judgment: it hallucinates, it can be persuaded, and it can be injected with instructions. Divergent judgment produces the same cost structure as divergent interests, so the same remedies apply. A useful way to read the harness, then, is as the agency-cost budget of the system.
It helps to see the support agent as a graph of steps. With the Gatekeeper off, the model’s proposal goes straight to the side effect:

The turn starts by authenticating the customer (an identity check, not a model call), choosing the order under discussion, and prefetching the obvious reads. Then the model is called (propose), which is the only place in the graph a model is used. If it proposes a tool call, execute runs it and the loop returns to propose; otherwise finalize writes the reply.
With the Gatekeeper on, the same spine gains a Gatekeeper between propose and execute, surrounded by the rest of the harness: a front door of screens (PII filtering, a prompt-injection screen, content moderation, deterministic checks, intent classification, context assembly), and an await_approval step where an escalated refund pauses until a person decides.

The bare graph is small enough to write out in full. In LangGraph, it is six nodes and one loop:
graph = StateGraph(AgentState)
graph.add_node("authenticate", self.authenticate)
graph.add_node("choose_order", self.choose_order)
graph.add_node("prefetch", self.prefetch)
graph.add_node("propose", self.propose) # the model: proposes a typed tool call
graph.add_node("execute", self.execute) # the tools: no Gatekeeper wired in
graph.add_node("finalize", self.finalize)
graph.set_entry_point("authenticate")
graph.add_conditional_edges("authenticate", self._after_authenticate,
{"choose_order": "choose_order", "done": END})
graph.add_conditional_edges("choose_order", self._after_choose, {"next": "prefetch", "done": END})
graph.add_edge("prefetch", "propose")
graph.add_conditional_edges("propose", self._after_propose,
{"execute": "execute", "finalize": "finalize"})
graph.add_conditional_edges("execute", self._after_execute,
{"propose": "propose", "finalize": "finalize"})
graph.add_edge("finalize", END)
return graph.compile(checkpointer=self._checkpointer)
Notice that nothing about authority appears anywhere in this code. That is not an oversight: it is what an agent looks like before a harness is put around it.
In the full system, the Gatekeeper lives inside the single tool path that execute calls, so every tool call passes through it. The graph’s structure is studied further in Workflow Design Patterns.
If the legal vocabulary feels abstract, consider a corporate travel desk. The travel agent has real agency: they search, compare, and can actually book. But the company’s travel policy sets a fare cap, and anything above it needs a manager’s approval before it is booked. Nobody thinks the travel agent is less useful because of the cap; the cap is precisely what lets the company hand them a booking tool at all.
| Role | Corporate travel | The support agent |
|---|---|---|
| Principal | The company paying for the trip | The business that owns the refunds |
| Agent | A travel agent: searches, compares, books | The model: reads, reasons, proposes |
| Tools | The booking system | list_orders, process_refund |
| Authority | Travel policy: fares up to the cap | Agent policy: refunds up to $50 |
| Escalation | Above the cap → a manager approves | Above $50 → a human review queue |
| Monitoring | Expense audit | Audit ledger of every decision |
Switching the Gatekeeper off is the equivalent of keeping the booking tool and removing the manager.
- An agent is a model plus a harness. The model proposes; the harness decides what the model sees, what it may do, and what is recorded. Almost everything production needs is in the harness.
- Agency is not authority. Capacity to act is a property of the model; permission to act is granted by a principal, held outside the agent, and checked before the act.
- The law of agency gives us the vocabulary (actual and apparent authority, ratification, the duty of scope, the four standings), and agency-cost economics tells us what delegation costs (monitoring, bonding, residual loss).
- The Gatekeeper puts these ideas into the control flow: between propose and execute, deterministic, policy from the database, every decision audited.
Don’t ask what your agent can do. Ask who decides what it may do, and show me the code.
- Russell & Norvig, Artificial Intelligence: A Modern Approach: the standard definition of an agent as perceiving and acting.
- Anthropic, Building Effective Agents (2024): agents vs workflows, and why simple designs usually win.
- Vivek Trivedy, The Anatomy of an Agent Harness, LangChain (Mar 2026): the “Agent = Model + Harness” decomposition.
- Addy Osmani, Agent Harness Engineering (Apr 2026): fixing failures in the harness rather than the prompt.
- American Law Institute, Restatement (Third) of Agency (2006), §§1.01, 2.01, 2.03, 4.01, 8.01, 8.09; see also the overview on Wikipedia.
- Jensen & Meckling, Theory of the Firm: Managerial Behavior, Agency Costs and Ownership Structure, Journal of Financial Economics (1976): monitoring, bonding and residual loss.
- Akerlof, The Market for “Lemons”, Quarterly Journal of Economics (1970): hidden information.
- Holmström, Moral Hazard and Observability, Bell Journal of Economics (1979): hidden action.