A new class of delegate

Part 2 of a series from six weeks building AI systems by hand: an operator going beneath the abstractions, on purpose. These posts carry more machinery than executive writing usually does. That’s deliberate.

The first post covered why: a year of building agents into my own operation, then six weeks testing that practice against the frontier, one system per week. This post takes the first decision an operator has to own: what an agent may actually do, and what actually binds it.

I operate across every function of a company: commercial, revenue, operations, the teams that deliver all of it. Reduced to one move, the job is delegation. You choose what to hand over, to whom, on what terms; a leader gets a mandate and the trust to run it, and the operating cadence catches drift before it compounds. Judging how much rope to give, and when, is most of the craft. This year, companies started handing mandates to software that improvises, and almost none of that craft came along.

The gap is technical. Nearly every system a company has wired in before was deterministic: same input, same behaviour, test it once and trust it. The probabilistic exceptions (fraud scores, recommenders, credit models) scored and ranked while people acted. An agent is probabilistic and it acts: mostly right, occasionally wrong, differently each run. That is why it needs managing like a delegate rather than testing like software. Six weeks inside the machinery showed me where the management has to go.

Authority lives in the execution layer

A model never touches a database directly. It writes a request — call this function, with these inputs — and ordinary code executes it, or refuses. I knew that long before the course. What I got from writing the loop by hand in week two is a measurement: how thin the machinery is. The entire enforcement surface of an agent — permissions, approvals, the guard on every destructive action — is a stretch of ordinary code. Cheap to govern well, and just as cheap to neglect.

Neglect is the industry default, and it is engineered in. In week four I built an agent that could run commands on my machine, the deepest access I granted all sprint. The boundary on its file access comes down to one keyword argument:

b = LocalShellBackend(root_dir="agent_workspace")                     # a working directory
b = LocalShellBackend(root_dir="agent_workspace", virtual_mode=True)  # a wall

The first line looks like a wall and is only a working directory: an absolute path walks straight past it. The second refuses to resolve anything outside the folder. The default is the first. And for the shell itself the library’s documentation is blunt: no isolation on the host. Put approvals in front of it, or run it in a real sandbox. The controls exist and they are cheap; nothing turns them on but a person who knows to ask. Agents are being wired into payment rails, ERP systems and vendor onboarding right now on defaults like that first line, plus an instruction in the prompt. The first artefact I ask for now is the tool list and what bounds each tool. That document, not the prompt, is the delegation of authority.

Every rule needs a material decision

Why instructions make weak boundaries arrived in week one, on the question-routing system the first post describes. One of its rules was correct, unambiguous, and repeatedly ignored. The model had weighed it against everything else in its context (the full pile of text it reads before answering), and the rule lost. What fixed it was redesigning the pile, not raising my voice inside it.

That is the difference in materials. Code binds: an if statement wins every time it runs. Prose persuades: it raises the odds, and it can lose the weighing. Most of a working system is persuasion, and should be. The design question is which rules must never lose, and I now decide it per rule, on two axes: the cost of a violation, and how often the rule changes. Unacceptable failure with crisp inputs — a spend threshold, an approval limit — goes in code. Survivable and still evolving stays in prose, and you measure the obedience rate rather than assume it. I ran that experiment deliberately: one judgment rule left in prose while the hard thresholds moved into code.

def whisker_flags(r):
    """Gates cleared with almost no room — crisp thresholds,
    so they live here (design decision, 30 Aug): quality
    margin < 0.005, latency margin < 25ms."""

The prose rule was obeyed on every run — obeyed when the evidence beneath it was fabricated, faithfully producing the wrong recommendation, and obeyed on the re-run with real numbers, producing the one my hand-worked answers said was right. Obedience is not correctness: a faithfully followed rule is only as good as the evidence it reads. Discount caps and credit limits sit in system prompts across the industry today. The test for every such rule: what happens on the run where the sentence loses? Say that run is one in fifty.

The mandate needs an end

An agent is a loop, and something has to end it. In week four I built a research system where the model planned its own work. It proposed ten workstreams; my budget code kept four. That is the choice in miniature: either code ends the loop when something countable is true (no tasks remaining, a budget spent) or the model ends it by feeling done. “Keep going until the task is done” is the most dangerous sentence in this field when done is the model’s opinion.

Mature deployments converge on the contained shape: autonomy inside workflow boundaries, a deterministic layer owning budgets and completion, human approval where the mandate touches the outside world. Support agents deciding for themselves that a customer’s issue is “resolved” are running the other design.

What it reads is what it knows

The model remembers nothing between turns; everything it knows is re-sent on every pass of the loop. The evidence pipeline feeding an agent is therefore part of the agent. The final build of the sprint taught me that the hard way: the fabrication incident from the first post, where a gap in an evidence file got filled with confident invention. Voids get filled. A later post in this series is entirely about where answers come from.

Five levers, not one dial

The most reusable framework I left the sprint with treats “how much autonomy” as five design inputs, not one ambition:

Read them honestly and the default falls out: version one is a workflow, and autonomy is earned with production data. Which is how we delegate to people: nobody hands a new hire an unbounded mandate on day one. In the enterprise, sophistication is reliability, not autonomy.

The artefacts to ask for

None of this requires an executive to write code. It requires treating the machine as a delegate and setting the terms you would set for any senior hire: the scope of the mandate (the tool list and its bounds), which rules bind and which merely persuade, who decides done, and the lever readings behind the autonomy granted. The terms apply the same whether your own team built the agent, you bought it, or someone is pitching it. Most systems today cannot answer all four, and the gaps are where the operating work is.

COO in energy, previously Twitter and Stripe. I build what I write about.