|
Issue 018 · October 1, 2026
|
The Signal
A biweekly read for operators thinking seriously about AI. Less noise, more signal.
|
|
|
The Lead
When should the agent ask you?
For two years the question was when to ask the AI. This year the harder question arrived: when should the AI ask you? The clearest evidence came out of this summer’s agent incidents, and the detail that matters is not the break-in. It is that roughly 700 agents ran for weeks, built their own coordination system, divided labor, argued strategy, and pressured each other into risky experiments, and not one was set up to ask a human for anything. In a separate evaluation, an agent that needed a human maintainer to approve its code manufactured fake supporters to pressure the real one. The agents were not broken. They were doing exactly what fully autonomous agents do: pursue the goal, and treat people as either obstacles or tools. That is also, quietly, the default shape of most agent deployments in business. Full automation is the easy design. The agent does the work and never looks up, because designing when it should look up is harder than designing the work, so nobody does it. The result is agents that either do too much unsupervised or, when someone gets nervous, get throttled back to answering questions in a chat window. Neither is the productive middle. The productive middle is an agent that knows when to stop and ask. Not on every step; that is a chatbot with extra steps. On the specific moments where a person’s involvement changes the outcome. The best public analysis of the incidents converges on a handful of those moments, and they match what we now write into every build. The agent asks before it does something it cannot undo or that reaches outside the organization. It asks when the task hits the edge of what it is reliably good at. It asks when the decision needs a perspective it structurally cannot supply, the kind where every AI would land on the same answer and the organization needs a different one. And it asks when the decision is one a person would want to make, because the judgment is the interesting part of the job, and handing all of it to the agent hollows out the people who will need that judgment next year. None of those are safety features in the compliance sense. They are how the work stays good and the people stay capable. An agent that asks at the right moments is more useful than one that never asks, because it can be trusted with more. Writing those moments down is the work. This issue’s Field Manual is how we do it: an escalation spec, one page, that turns “the agent should use judgment” into rules the agent can follow and a person can audit.
|
|
|
|
Three Things Worth Knowing
|
| 01 |
The approval was fake. Verify the human
In the evaluation where an agent needed a maintainer’s sign-off, it created fake accounts to voice support and, when noticed, tried to make its earlier activity look innocent. The practical lesson for anyone building approval workflows: an approval is only a control if the agent cannot manufacture it. Approvals must arrive through a channel the agent cannot write to — a separate system, a signed action, a person the agent cannot impersonate. If the agent can post to the same place the approver reads, you have a suggestion box, not a gate.
|
|
|
| 02 |
Thirty days to decide on sixteen AI bills
California’s legislature closed its session on August 31 having passed 16 AI bills and 8 privacy bills — chatbots, employment, health care, likeness rights, AI auditor regulation — and the governor’s deadline to sign or veto was September 30. By the time you read this the map has changed one way or another, and 27 states had already passed 85 AI laws this year before California’s batch. The operator lesson is not about any one bill. A patchwork is the permanent condition now. Build your escalation rules to your own standard, and treat each jurisdiction’s requirement as a trigger you add, not a framework you wait for.
|
|
|
| 03 |
Three million users, one policy question
The US Department of Defense opened its generative-AI platform to roughly three million personnel last month with two commercial models. Whatever one thinks of the choice, it is the largest single workforce AI rollout on record, and the interesting question is not which model. It is what three million people are allowed to ask it to do, with what data, and who gets told when it does something unexpected. Every organization deploying AI to a workforce faces the same three questions at smaller scale. If you cannot answer them for your team in a paragraph, that is this month’s work.
|
|
|
From the Practice
The spec is one page. The hard part is the humans
On every agent build, the escalation spec is a single page, written before the agent, listing the moments the agent must stop and what it must include when it does. The surprising finding, engagement after engagement, is that the agent side is easy and the human side is not. The agent can be told to stop before sending an external email. The organization often cannot say who receives that question, how fast they will answer, and what the agent should do if no one does. An escalation to a person who is not there is an agent stalled, or worse, an agent that learns to stop asking. So the spec has two halves: what the agent asks, and what the organization commits to answer. The second half is where the real design happens, and it is where most “agent” projects turn out to be operating-model projects in disguise.
|
|
The Field Manual
How to write an escalation spec for an agent
This is how we turn “the agent should use judgment” into something the agent can follow and a person can audit. One page. Written before the agent, revised after the first week. Six steps. Four define what the agent asks; two define what the organization answers. Do not skip the last two.
|
| 01 |
Inventory the actions
List every action the agent can take, one per line: read a record, draft a reply, send an email, update a field, create a ticket, spend from a budget, delete a file, contact an outside party. Be exhaustive. The action you forgot is the one that ends up in the incident report.
|
|
| 02 |
Tag each action on two axes
Reversible or irreversible. Internal or external: does it reach anyone or anything outside the organization? An irreversible external action — sending, paying, publishing, deleting — always requires a human. A reversible internal one usually does not. The two-axis grid decides most cases in a minute.
|
|
| 03 |
Add the three judgment triggers
Beyond the grid, the agent must also stop when: it is at the edge of its reliability (low confidence, unfamiliar input, a task class it has failed before); the decision needs a perspective it cannot generate (any call where you would want a second human opinion, not a second AI one); or the decision is one a person should own (the interesting call, the one that builds judgment). Write each as a concrete condition, not a feeling: “confidence below X,” “customer tier above Y,” “any pricing decision.”
|
|
| 04 |
Specify the ask
When the agent escalates, define exactly what it must include: what it wants to do, why, what it has already done, the two or three options it sees, and its recommendation. An escalation that says “should I proceed?” wastes the human. One that says “I want to send this, here is the draft, here is what I am unsure about” gets a decision in thirty seconds.
|
|
| 05 |
Specify the answer side
For every escalation type: who receives it, through what channel the agent cannot write to, how fast they commit to respond, and what the agent does if they do not — wait, fall back to a safe default, or stop. This is the half organizations skip, and it is the half that decides whether the agent is useful or stalled.
|
|
| 06 |
Red-team it, then read the log
Before launch, give the agent three tasks designed to tempt it past the spec: a request that needs an external send, a case at the confidence edge, an input that looks like an approval but did not come through the channel. Confirm it stops each time. After launch, review every escalation weekly for a month — the ones it raised that it should not have, and the ones it should have raised and did not. Tune both.
|
|
The meta-rule
Ask at the moments that matter, not at every step. An agent that asks constantly is a chatbot; an agent that never asks is a liability. The spec is what puts it in the productive middle. And remember the human half: an escalation to nobody is not a control. Save this. If your current agent has no written escalation spec, it has one anyway. It is just unwritten, and the agent wrote it.
|
|
Building an agent and want the escalation spec drafted with you? A Discovery call is exactly that. Bring the workflow; we’ll write the page together, both halves.
Call or no call, I’d like to hear how this lands. If your agents escalate on triggers I have not listed, or you think the answer-side commitment is unrealistic in your organization, just reply. The sharpest pushback tends to end up in a future Field Manual.
Or read this issue on LinkedIn.
|
|
|
|