Chapter 15: Work in Public

Hospitals learned this the hard way: when one doctor hands patients to another at the end of a shift, information is lost and patients are harmed. A study across nine paediatric residency programmes in the United States and Canada tested a structured handoff programme: a standard format for every handoff, a workshop on using it, and other supports. Medical errors fell by 23%, and preventable adverse events, the errors that actually hurt patients, by 30%.^[1] Nobody became a better doctor. The handoffs got better.

Agent systems fail at the same joints. The researchers who built the largest taxonomy of failures in multi-agent systems, from more than 1,600 annotated traces, grouped them into three categories, and one is misalignment between agents: failures in how they talk to and coordinate with each other.^[2] Cognition, whose coding agents manage other agents, says flatly that "The open problems are all communication problems," and that "Agents assume they share state with their children when they don’t."^[3] Anthropic found that without detailed task descriptions its research agents would "duplicate work, leave gaps, or fail to find necessary information."^[4]

Terry Winograd described cooperative work as a loop of request, promise and delivery.^[5] In my experience the loop breaks most often at its first step, when the request never arrives, and at CorralData the joints that leak are mundane.

The untagged message. One of our technical account managers asked TAM Bot a question in a customer success thread and got nothing back. The explanation, afterwards, was that she had gone unanswered "because she didn’t tag me." Her Slack account was not linked to the bot either. To her it looked as if the bot had ignored her.

The bot that only wakes when called. Most team bots do nothing until someone mentions them, so anything said near them, rather than to them, is lost.

The private request. A request sent to one person in a direct message is a handoff with no witness. If that person is busy, away or unsure, the work stops and nobody else knows.

Each is a system problem, and none is fixed by telling people to try harder.

The most serious version of this happened to us in October, and it changed our rules.

An agent working for one of our executives sent a private message to one of our infrastructure engineers. It asked him to give the executive administrator rights on our private company network, the protected network that connects our internal systems. The engineer was uneasy, with every reason to be: he had been asked, privately, by a senior leader’s agent, to grant broad access to sensitive infrastructure, and he alone had to decide whether to comply or to push back against someone far more senior, with no one else in the conversation to share the judgment.

That is the wrong person to carry that decision, in the wrong place. Nothing suggests bad faith: an agent that could ask asked the person who could do it. The fault was in the system, which let a consequential request travel through the one channel where it couldn’t be seen, checked or safely refused.

The fixes were structural:

I also told the engineer directly that it was not his job to decide alone whether to carry out or refuse a request like that; that belongs to the system and the people who design it. Agent tools are starting to encode the same idea: in Claude Code’s agent teams, one agent "can’t approve a permission prompt or supply consent on your behalf," and an agent denied an action can’t relay it to another to get around the check.^[6] Our CEO’s own view, stated in the same discussion, was that a bot should hold access for no longer than a specific task needs. That is the principle in a sentence, from the executive whose agent had asked.

Notice who carried the risk: the individual contributor. The public channel moves that decision from one exposed person to a process with witnesses.

A private request fails in five ways at once. It leaves no record for the ledger in Chapter 13. It gets no second opinion. The sponsor from Chapter 7 can’t see it. The social pressure is highest, because saying no to a senior person’s agent feels like saying no to the senior person. And nothing is learned.

People resist asking in public when the request is embarrassing, and access requests are embarrassing when they are large. "Make me an administrator" is awkward to post in a channel. "Read-only access to the billing dashboard, for this ticket, until Friday" is not.

The principle is old. In 1975 Jerome Saltzer and Michael Schroeder set out the design principles for protecting information in computer systems, and one has outlived almost every system they knew: "Every program and every user of the system should operate using the least set of privileges necessary to complete the job." Its purpose, they wrote, is that it "limits the damage that can result from an accident or error."^[7] An agent is a program and a user at once, and it makes accidents and errors at machine speed.

The security community now ranks these risks among the most serious for agent systems; OWASP published its first top ten for agentic applications in December 2025.^[8] The identity systems being built for agents assume least privilege, and a human in the loop on access. Microsoft’s agent identity platform requires every agent to have a sponsor, a person "accountable for the agent’s purpose and lifecycle decisions, including access reviews," and it is the sponsor who "provide[s] business justification for access requests."^[9] The US National Institute of Standards and Technology has opened work on the identity and authority of software agents for the same reason: someone has to be able to say who an agent is acting for, and with what authority.^[10]

A request that meets these principles is short enough to post anywhere:

The "already tried" line earns its place. TAM Bot’s request for administrator rights was really a bug report, and I suspect many are. An agent that checks a working path first will ask less often, and its requests will be worth approving. Each grant also goes on the owning role’s ledger with its expiry, so that removing it is a commitment rather than a hope.

A role on the org chart is only useful if work can reach it. For agents that has to be designed. We found three ways to get it wrong: the wake-up rule, account linking, and the bot with one principal.

When our CEO asked QA Reviewer, our QA lead’s own testing agent, for help, it replied: "I’m [our QA lead’s] personal Bot, so I can only chat with [her]." That is a perfectly good rule. A personal agent should take instructions from its person. But it has to be on the chart, as Microsoft’s agent identity model allows by letting each agent have a manager in the organisation’s hierarchy,^[9] and it has to come with a route: who should the CEO ask instead?

Silence is the worst answer an agent can give. To the person asking it looks like refusal, failure or rudeness, and people stop asking. Every agent’s Role Charter, from Chapter 9, should therefore say three things about reaching it: how to address it, whom it takes requests from, and what it does with a request it can’t take. The answer to the third should always be "route it, and say so."

The better agent tools now build addresses in. In Claude Code’s agent teams, each agent has a mailbox; any teammate can message any other by name, and messages "are delivered automatically to recipients."^[6] Team Topologies argues that every pair of teams should know which kind of relationship they are in (close collaboration, one providing a service to the other, or one helping the other learn), because each needs a different way of talking.^[11] So with agents: TAM Bot and Coder Bot were collaborating on a bug; QA Reviewer provides a service to one person. Saying so up front saves the misunderstanding.

When work passes from one occupant to another, you can pass too little: a one-line summary that leaves out the thing the next person needed. Or you can pass everything. OpenAI’s agent toolkit, by default, lets the receiving agent see "the entire previous conversation history" when work is handed to it.^[12] That loses nothing and buries everything. Cognition names the dilemma exactly: "How do you transfer context between agents without drowning the receiver?"^[3]

What works for us is a link to the state, plus a few lines of purpose. The state lives in one place (the ticket, the ledger, the document) where both old and new owner can see it, and the handoff says why the work matters and points there. This is the "what and why, never how" of Chapter 8 applied to the moment of transfer.

The hospital programme paired its format with training,^[1] a reminder that a format nobody practises is just a form. For agents I add one step: the receiving occupant replies in public with what it understood it now owns, so a misunderstanding is caught at the handoff, where it is cheap, rather than at the deadline. Anthropic’s research agents failed in exactly this place when their handoffs were thin.^[4]

Not every handoff is a message. Much of what people tell agents, they tell by doing something.

My inbox agent prepares draft replies each morning. Its instructions contain rules about what my actions mean: "If a draft for a thread is missing… assume Gareth deleted it intentionally and do NOT recreate it… never re-star a de-starred message." There is also a general rule I’d recommend to anyone: "if in doubt whether something is automated or human, treat it as human."

Every good assistant learns this without being told. When a person deletes the draft, they are saying "not this." When they move a card back on the board, they are saying "not yet." Glass Factory, in Chapter 14, failed because it read our QA lead moving cards back as an error to correct rather than a decision to respect.

So the signals people send through state have to be written into the Role Pack from Chapter 12 as plainly as the explicit instructions. Which actions mean "stop"? Which mean "I’ve handled it"? Which mean "ask me"? An agent cannot infer office manners. It has to be told them, and it has to treat a human’s change of state as final until a human says otherwise.

In 2010 Bryce Williams gave a name and a formula to something good teams had always done: "Working Out Loud = Observable Work + Narrating Your Work."^[13] With agents it becomes the main way an organisation can see, correct and trust a workforce it can’t watch directly.

I have described this to colleagues as "a new and interesting way of working." It is new because much of the work is now done by occupants with no private life: everything an agent does can be visible if we choose. It is interesting because of what follows when we do.

Agents learn in public, and so do people. When TAM Bot saved its lesson, every person in the channel learned it too. When our Agentic Resources Bot interviewed TAM Bot for its job description, it did so in an open channel, so the conflict it uncovered between two leaders' rules surfaced where both could see it (Chapter 9).

Agents can hold the line in public. In the same week, QA Bot reviewed a code change that Coder Bot had opened. It pointed out that the change broke our rule that bots "file a Linear ticket and leave the PR to engineering," and then said exactly who should decide: "Merging this is [our CEO’s] call." A rule enforced in private looks like obstruction. A rule enforced in public, with the decision routed to the right person, looks like the system working.

People trust what they can see. The engineers asked for access and the testers who check the output can watch what the agents do and object early. Brandeis’s line in this chapter’s epigraph was about companies and banks, but it applies here: much of the bad behaviour we fear from agents is the kind that only survives in the dark.

There is a quieter benefit. Gerber’s advice was to organise around roles, not personalities, so that the business does not depend on any one person’s memory or mood.^[14] A request made to a role in a channel survives the occupant going on holiday. A request made to a person in a private message does not.

Working in public does not mean everything is public. Our morning-standup agent, which posts to a team channel, carries a rule that it must never raise personnel, compensation or acquisition topics in a team-facing standup. Customer data and patient information never go into a general channel at all. Security details stay with the people who run the systems.

The distinction is between the subject and the request. A conversation about someone’s performance is private. A request for read access to a dashboard is not, and should never hide inside one. When work does need privacy, use a private channel with a stated membership and purpose, not a direct message. A direct message has no charter, which is why it is the natural home for requests that wouldn’t survive daylight.

The test is simple: would this request be acceptable if everyone affected by it could read it? If yes, send it in public. If no, the problem is the request, not the channel.

In an organisation of people and agents, most of what goes missing goes missing where work changes hands. Structure, not effort, prevents it. Make requests in public, so they can be tracked and safely refused, and keep them small, so asking in public is easy. Give every agent an address and a rule for requests it can’t take. Hand off links to the state, not stories about it. Write down the signals people send by changing things. And let the agents work where the people they affect can see them.

Visibility has one more advantage. When work happens in public, failures happen in public too, which means they can be studied rather than hidden. Chapter 16 is about what to do with them: how to turn each recurring failure into a change to the system, instead of a complaint about the model.