The Reporting Line

There is a question I have started asking instead of “how autonomous is this agent?”

How often does it need to talk to me?

It sounds like a smaller question. It’s actually the bigger one, because it’s the only part of an agent system a normal person experiences. Nobody feels an architecture. Everybody feels a notification.

And the answer has changed three times in about four years.

Three interfaces

Version one was completion. The agent finished your sentence. GitHub Copilot suggested the rest of the line, autocomplete guessed the rest of the word, and the interface was the cursor. You were in the loop continuously—hundreds of times an hour, at sub-second latency—because the unit of work was a few tokens long. The agent never held an intention. You held all of them, and it filled in the gaps.

Version two was conversation. This is where most people still live. You describe a problem, the agent proposes something, you correct it, it revises. The interface is the chat window, and it works because the unit of work grew from a few tokens to a few minutes. It genuinely feels like collaboration, and it genuinely is: the good outcomes come from the back-and-forth, not from either party alone.

But look closely at what you’re doing in that window. You are the scheduler—nothing happens until you type. You are the memory—when the context fills up, you’re the one who remembers what was decided on Tuesday. And you are the clock: the system runs at exactly the speed you read.

Version three is a reporting line. The unit of work is now a week. There is not one agent; there are several, running on a schedule you didn’t trigger, coordinating through a shared store rather than through you. And the interface is not a conversation at all. It’s a Friday email, a dashboard you glance at, and an escalation when something needs your decision.

The relationship stops resembling a tool and starts resembling a department that reports to you.

I want to be precise about what’s new here, because most of the ingredients aren’t. Multi-agent systems, autonomous loops, self-improving agents—these are well-trodden. There is even a good published taxonomy of agent autonomy levels (Cihon et al., 2025) running from operator through collaborator, consultant, approver, and observer. That work grades how much latitude the agent has.

This piece is about a different axis: what happens on the human’s side of the wire. Latitude is an engineering property. The interface is the product. And the interface is what’s actually shifting under us.

Why the chat window has to break

Here is the mechanical argument, and it’s the load-bearing one.

METR has been measuring something they call a model’s time horizon: the length of task a model can complete on its own with coin-flip reliability. In their published dataset, Claude 3 Opus sat at roughly four minutes. Claude Opus 4.6 sits at roughly twelve hours. Since 2023 the number has been doubling about every four months.

Sit with what that does to a chat window.

A conversation is a synchronous protocol. Turn-taking means the total throughput of the system is capped by its slowest participant, and after a certain point that participant is you. When the agent’s unit of work was two minutes, waiting on you cost the system very little. When the unit of work is twelve hours, a turn-taking interface means the agent finishes a full day of work and then sits idle for fourteen hours waiting for someone to read it.

You didn’t supervise it. You paused it.

This is the part I think gets missed in the “human in the loop” conversation. Keeping a human in the loop is not free and it is not neutral. Every checkpoint converts a parallel system into a serial one at the checkpoint. The literature on agentic workflows has a blunt name for the result: human-as-bottleneck—all of the cost of human involvement, none of the speed of automation.

The counterintuitive part: more oversight can be worse

I expected the bottleneck argument. I did not expect this one.

There’s a 2026 paper by Emre Turan with the excellent title Oversight Has a Capacity. It looks at the standard safety pattern—risky agent actions pause and wait for a person to approve them—and asks two questions the field mostly skips.

First: do humans even agree on what’s risky? On a hand-labeled set of 125 agent actions, reviewers reached a Fleiss’ kappa of 0.52. That’s moderate agreement. There is no clean ground truth to escalate toward.

Second, and this is the one worth the price of admission: what happens when you model the reviewer as a human being who gets tired? Once the reviewer fatigues as the escalation load grows, realized safety becomes an inverted U in the escalation rate. Escalate too little and bad things slip through, obviously. But escalate too much and safety falls again, because the person approving everything stops actually reading. The safety-optimal policy escalates below full escalation.

More oversight, past a threshold, makes the system less safe.

The paper’s framing is the useful part: agent oversight isn’t only a classification problem, it’s a resource-allocation problem. Human attention is a finite budget, and the agent’s escalation policy is what spends it. Turan even shows the attack this implies—flood the reviewer with noise, then slip the malicious action past them while they’re exhausted. Anyone who has worked in a security operations center already knows this attack by its older name.

So the reporting-line interface isn’t merely a convenience. Cutting the volume of agent-to-human communication is, under this model, a safety measure. Ten interruptions a day that you skim is a worse system than one weekly brief that you actually read.

A specimen

Abstractions are cheap. Here’s a real system, open source, that I’ve been running against a live campaign since July.

Publicist is a PR agency in a box: it researches outlets, writes a pitch that could only have been sent to that outlet, sends it, handles the reply, chases exactly twice, answers journalist source requests, and reports to the client every Friday on whether the week went well or badly.

Seven single-purpose agents run on a cron schedule, in the order a real agency works.

Agent	When	What it does
Strategist	daily, early	Researches each outlet’s recent work, picks the one angle that fits, writes a pitch brief
Outreach	daily	Sends pitches from those briefs, handles replies, chases exactly twice
Inbox	daily, afternoon	Inbound triage only—no new cold pitches
Source requests	3× weekly	Answers journalist queries before the query closes
Bookings	Mon/Wed/Fri	Works booking platforms through a real browser
Manager	daily, evening	Reviews every lane, enforces the budget, and is the only agent that emails the client
Writer	on demand	Drafts a bylined article against an accepted commission

Now compare that to a chat-shaped system doing the same job. In the chat version, you decide which outlet to pitch today. You remember whether you already contacted this person. You notice the follow-up is due. The agent is excellent at the writing and useless at everything around the writing, so you stay in the chair.

In Publicist, the only thing on my calendar is reading a Friday email.

The agents do not talk to each other

This is the design decision I’d defend hardest, and it’s the one that cuts against the obvious instinct.

There’s a well-known critique of multi-agent systems—Cognition’s Don’t Build Multi-Agents—arguing they’re fragile because splitting a task across agents is a game of telephone. Context gets lost in transmission. One subagent builds a Mario-style background while another builds a photorealistic bird, and the coordinator inherits an impossible merge. It’s a fair critique and it kills a lot of naive swarms.

Anthropic’s multi-agent research system reported the other side: a lead agent with subagents outperformed a single agent by 90.2% on their research eval—while burning about 15× the tokens of a chat interaction. Parallel agents work, expensively, if you respect the guardrails.

Publicist’s answer to the telephone problem is to not play telephone.

The lanes never message each other. The strategist hands work to outreach by writing a row in a database. Any lane escalates to the manager by appending a line to a file. The manager pushes guidance back down the same way, and every lane reads the newest entries at the start of every run—so a correction written tonight is in force tomorrow morning.

Every lane is also stateless. It starts with no memory of yesterday, is told so explicitly, reconstructs what it needs from the store, does one job, records what it did, and exits.

That sounds like a limitation. It’s the whole design. The alternative—one long-running agent that keeps the campaign in its context—fails in a specific and predictable way. Context is finite, so the campaign’s history gets summarized, then summarized again, and summaries lose exactly the detail that matters here. Did we already email this person? is one line among hundreds, and it’s the one that must never be lost. The agent doesn’t fail loudly when it forgets. It cheerfully pitches someone for the second time, in a warm tone, having lost the memory that there was a first time.

The line from the architecture doc that I keep coming back to:

An agent that has been running for six weeks is not a colleague with six weeks of experience. It is a colleague with six weeks of increasingly lossy notes.

Trust is bought in code, not in prompts

Here’s the part that makes the low-bandwidth interface legitimate rather than negligent.

You cannot responsibly stop watching a system because you’ve decided to trust it. You stop watching because the things that would hurt you have been made impossible, and impossible is a property of code, not of instructions.

Publicist’s guarantees are enforced in the store and covered by tests:

• You cannot pitch the same person twice. Claiming a target is a conditional database update—only one caller can win. A prompt that says “don’t pitch anyone twice” is a request. This is a guarantee.
• You cannot approach someone already approached on another channel. The dedup check normalizes outlet names and domains across every lane, and deliberately errs toward false positives, because a false positive costs one skipped pitch and a false negative costs a relationship.
• Silence is not permission. A target pitched six weeks ago who never replied still returns already reached.
• A crash cannot cause a double-send. Recovery asks a question with an unambiguous answer—does a mail thread exist for this target?—rather than guessing.
• Two lanes cannot run at once. A campaign-wide lock, released by the operating system if a process dies.
• A reply cancels the chase, in the same transaction that logs it.

Notice what’s not on that list: anything about writing a good pitch. That part is genuinely hard, genuinely judgment, and genuinely worth a language model. Everything around it—who to contact, whether we already have, how many sends are left, when to chase—is deterministic and handled by code that cannot have an off day.

This is the actual trade. Narrow the agent’s job to the part that needs judgment, and make the part that would destroy you unrepresentable. Once you’ve done that, you’ve earned the right to stop reading every message.

The manager lane is the interface

There’s one agent whose entire job is the reporting relationship, and building it changed how I think about this.

The manager pitches nobody. It reviews every lane’s work each evening, pulls two or three of the day’s outbound messages and checks whether they’re specific, within the length limit, free of hype, and consistent with the positioning document. It promotes and demotes targets. It enforces a hard budget ceiling. And it is the only lane permitted to email the client.

Its weekly brief has a fixed structure: the headline, the numbers week over week, conversations in flight with the next step and date for each, money committed or awaiting approval against the cap, what’s working and what isn’t, and a concrete plan for next week with named targets.

The instruction I’m proudest of is about tone:

Direct about wins and misses, numbers rather than adjectives, asks grouped at the end and never buried mid-paragraph. A miss reported crisply builds more trust than a padded week. If a number is bad, lead with it and say what you are doing about it.

And this one, which is the difference between a tool and a colleague:

You are also the only lane positioned to notice the campaign is not working. If the reply rate says the angle is wrong, say that to the client rather than sending more of the same next week.

The uncomfortable thing about writing that file is that I wasn’t inventing an AI interface. I was writing a job description. The structure of a good agency status report, refined over decades by humans managing humans, turned out to be exactly the right structure for an agent reporting to a person. The interface converged on the org chart because the org chart is a solved problem in low-bandwidth, high-trust coordination.

Which is the analogy I’d offer to anyone non-technical trying to picture this: it’s a concierge relationship. Your accountant does not text you forty times a month. A good estate manager does not ask permission to buy light bulbs. The volume of communication in a high-trust professional relationship is low, and the low volume is the signal of quality, not the absence of it. What makes it work is not that you’re watching—it’s that the boundaries are explicit, the exceptions are escalated, and there’s a statement at the end of the month.

Why you can afford to stop watching

There’s a fair objection here: a system you only check weekly is a system that can rot for six days.

Which is true, and it’s why the reporting-line interface only works on top of something that improves between reports. A system that only gets better when you talk to it must be talked to constantly. That’s not a communication design—it’s a dependency.

The evidence that agents can improve unattended is now solid enough to build on. Google’s AlphaEvolve runs an evolutionary loop that writes, tests, and improves algorithms with an automated evaluator in the inner loop instead of a person, and it’s been run against Google’s own production infrastructure.

Andrej Karpathy’s autoresearch is the cleaner illustration, because it’s 630 lines of Python. An agent reads the code, proposes a change, runs a five-minute training experiment, checks whether the validation metric improved, keeps or discards the result, and repeats—about twelve experiments an hour, no human input after you press enter. Karpathy let it run 700 experiments over two days and it found twenty stackable improvements that cut GPT-2 training from 2.02 hours to 1.80 hours. Shopify’s CEO ran it overnight against an internal model: 37 experiments, 19% better.

Nobody was in the loop. The loop was the point.

That’s the real unlock, and it’s why the human-in-the-loop math flips. In a chat system, improvement happens at the speed of your attention. In a scheduled system with a store, it happens on a cron. Between two Friday reports, a hundred and sixty-eight hours of experiments have run and you’ve spent four minutes reading.

I’ll add my own caveat, because I ran the experiment and it didn’t say what I wanted. When I tested self-improving agents in a controlled setting earlier this year, one skill library did produce a real, statistically-surviving lift—and a control condition where the same model wrote skills from priors alone, with no simulation at all, recovered most of the outcome gain. Some of what we attribute to elaborate self-improvement machinery is just a good model plus the right instruction.

Two things follow, and both matter for this argument:

Compliance and outcome decouple. In that experiment, a library the agent appeared to follow three times as often produced the same results as one it appeared to ignore. If your weekly report only tracks whether the agents followed the rules, you’ll happily preserve rules that don’t help. Report both, or your dashboard will be measuring obedience and calling it performance.

Unattended improvement is also unattended drift. The whole risk register of self-modifying systems—drift, reward hacking, compounding errors, context pollution—gets more dangerous when the review cadence stretches from minutes to a week. The mitigation isn’t more notifications. It’s anchoring the weekly numbers to a frozen baseline rather than to last week, so a slow slide is visible as a slide.

What this actually changes for you

If you build products, the shift is from designing a conversation to designing a management relationship. Concretely:

Your spec becomes your management artifact. Publicist has two documents that do more work than any prompt: a positioning file defining the outer bound of what may truthfully be claimed about the client, and a policies file with the budget ceiling, the banned words, the follow-up limits, the disclosure rules. These aren’t prompts. They’re the standing orders you’d give a team, and when the client changes their mind, the manager’s job is to write the decision into those files—because a decision that lives only in an email thread will be forgotten by every lane, including the manager.

You design the escalation threshold, not the escalation. Turan’s inverted U means the threshold is a real dial with a real optimum, and both ends are bad. Publicist’s version: free opportunities get accepted and merely reported; anything involving money stops and asks; anything that misleads a real person gets corrected in-thread and disclosed to the client, immediately, out of cadence. “A correction the client learns about from you is recoverable; one they discover themselves is not.”

Cadence becomes a design surface. Routine update every three days. Full brief on Friday. Immediate, cadence-breaking contact for exactly three triggers: an approval is needed, a booking is confirmed, or something went wrong. The subject line prefix tells you which before you open it. That’s three tiers, and three is enough.

Your UI is a dashboard and an inbox, not a thread. Luke Wroblewski catalogued the interface patterns emerging for agent management—kanban, dashboard, inbox, task list, calendar. It’s telling that not one of them is a chat window. When the thing you’re managing is five workstreams rather than one conversation, you need status at a glance and a queue of things needing your decision. Publicist regenerates a markdown dashboard at the end of every run and commits it to git, so the campaign’s history is a diff.

And the honest scoping question: this only works where the catastrophic action can be expressed as an invariant something can enforce. Never contact the same person twice is checkable. Never say anything tasteless is not. If the thing that would ruin you can’t be made structurally impossible, you don’t get to lower the bandwidth yet—and no amount of prompt discipline substitutes.

Where this leaves us

The last four years of agent progress have been narrated as a story about capability. I think the more consequential story is about interface, because the interface is what decides whether a capable system is usable.

We went from completion, where you were in the loop every few seconds, to conversation, where you were in the loop every few minutes, to something that doesn’t have a good name yet, where you’re in the loop every few days and the system is genuinely working the whole time in between.

Each step made the channel narrower. Each step made the thing on the other end of the channel more capable of being left alone. And what we’re converging on—standing orders, a budget, exception escalation, a weekly brief, and a dashboard—is not a new invention at all. It’s the interface humans built for managing other humans, arrived at from a completely different direction, for exactly the same reason: attention is the scarcest thing in the system, and the whole art is spending it only where it changes an outcome.

The measure of a good agent, increasingly, isn’t how well it talks to you.

It’s how little it needs to.

---

Publicist is open source under Apache 2.0 at github.com/chasewhughes/publicist. Related reading: The Post-Graph Era on why rigid workflows are giving way to primitives, The Team That Isn’t There on manufacturing disagreement with persona agents, and Self-Improving Agents on what trial and error actually teaches them.

Illustrations generated by an image model and cleaned up by hand.