A Process in Someone's Head Is a Bottleneck

Procedures are institutional memory. Your agents were hired yesterday.

One failure pattern shows up wherever automation meets old workflows. Call it a pattern, because that is what it is, not a report of any particular event. An automated flow runs cleanly through its early steps. Then it reaches a step that looks routine in the written procedure and is not routine in practice, because for years an experienced person has been handling an exception there, applying a rule that was never written down since nobody ever asked for it in writing. The system cannot consult a rule that exists only in someone's practice. So one of two things happens. The system stops, safely, and the team calls the automation disappointing. Or it does not stop, and it sails past the point where a person would have paused, and the exception gets processed like the routine case for as long as it takes someone to notice.

Neither outcome is a technology failure, and neither is fixed by a better model. The organization was unable to explain itself to its own system. This chapter is about that inability: where it hides, what it costs, and how to see one instance of it clearly enough to fix.

The flow that actually runs

Define the condition through the work. Process is the enacted flow: how a piece of work actually moves, hand to hand, system to system, with its handoffs, entry conditions, exceptions, checks, and the evidence each role uses to know the previous role finished. The test is whether the flow survives the absence of any one person; when it lives only in someone's head, it is a bottleneck, not a process. The definition is deliberately about movement, because documents describe intentions, and movement is what a machine inherits.

Scope the consistency claim carefully, because the strong version is wrong. A good process does not mean every case returns the same outcome; expert judgment legitimately produces different answers when the conditions differ, and a flow that forbade discretion would be a worse flow. What repeatability means here is narrower: for the repeatable part of the work, the conditions, the authority, the evidence, and the exception path are inspectable. Two people can see why this case went left and that one went right. Discretion survives. Invisible discretion is what does not.

Most companies hold two versions of any flow: the official procedure and the enacted one. Some official documents are current and accurate; plenty were written for a purpose other than doing the work, and drifted. The enacted flow lives in practice, distributed across the people who run it, holding exceptions nobody thinks of as exceptions. Recovering it has become more approachable: where use is lawful and permitted, logs, tickets, recordings, demonstrations of the task, and existing documents can reconstruct much of how work moves. Hold the limit alongside the help. That evidence yields a skeleton, the visible sequence of steps and queues. It does not explain why step five exists, what the person at step five checks for, or which of their pauses is a habit and which is a safeguard. The muscle on the skeleton is human explanation and observation, and no export replaces it.

Automation forces the real conflict. Inside any mature flow, two kinds of unwritten things coexist: expired residue, steps that outlived the platform or incident or argument that created them, and learned safeguards, judgment accumulated from cases that went wrong. Automation obeys both with identical loyalty. It will faithfully preserve the pointless step and faithfully skip the protective pause, depending only on what made it into the specification, because the specification is all it has. An organization that cannot tell its residue from its safeguards is about to cast both in concrete. Telling them apart is the rest of this chapter.

Why your agents stall

The evidence that this condition gates automation comes from attempts to skip it. A research team built TheAgentCompany, a self-contained environment simulating a small software company, and set AI agents loose on consequential workplace tasks: browsing, writing code, running programs, communicating with simulated coworkers. In the published benchmark, presented at NeurIPS in 2025, the strongest tested agent completed about 30 percent of tasks autonomously. The authors' texture matters more than the headline number: simpler tasks were sometimes completed, while difficult, long-horizon tasks stayed beyond the tested systems.

Treat the result as what it is, a dated benchmark in one simulated company, and resist the tidy conclusion. Long-horizon failure has several parents: planning that loses the thread, tool use that breaks, state that gets dropped, ambiguity the agent resolves wrongly, context that was available to a human and absent from the system, and workflow designs no participant could execute cleanly. Undocumented process is one cause on that list, and often a large one, because a chain of dependent steps fails wherever any step depends on something written nowhere. But the benchmark does not decompose its failures for you, and neither will your own deployment unless you make it.

The reframe the benchmark hands you is plain. A written process is the interface between your company and anything new: a new hire, an offshore team, an acquired unit, and now a machine. It is the connecting tissue through which work travels from one hand to the next. Procedures are institutional memory. Your agents were hired yesterday. A system may run that flow without knowing an exception exists, when a question is required, or who holds legitimate authority to answer it.

Delete before you automate

Now the expensive trap, the one that consumes budget while producing motion. The instinct on discovering an ugly flow is to automate it as found. Do not, at least not yet. Mature workflows accumulate steps whose reasons have expired: a limitation of a platform you no longer run, a control born in an incident nobody remembers, an approval that once settled an argument between two departments. Automating those is paying to make waste faster, and worse, hardening it, because people quietly route around a bad manual step and machines do not.

The advice is old and the lineage should be named. Eliminate before you automate has been industrial engineering doctrine since long before software, refined by the lean tradition into a discipline. What the current era adds is a new way to violate it: a system that infers a workflow from your records will encode the waste without anyone understanding it at any point, whereas earlier generations of automation teams at least had to comprehend the process they were freezing.

But deletion has its own failure mode. Not every unexplained step is waste. Some are controls, safety rules, contractual obligations, or learned exception handling whose author has left and whose reason was real. A step with no visible source is a deletion candidate, and a candidate only: it goes to review by whoever owns the relevant control, safety, legal, contractual, or risk authority, and it is removed through that authority or kept with its reason finally written down. Either result improves the flow. Deleting first and discovering the reason later is how automation projects become incident reports.

One public illustration of the order done sensibly, bounded to what was reported. The Commonwealth of Pennsylvania reported in April 2026 that its earlier twelve-month generative AI pilot with 175 employees across 14 agencies had grown to approved tools for more than 3,000 employees across 35 agencies, and that its Department of Labor and Industry rebuilt unemployment-compensation chatbots around approved, curated responses, with escalation to a live representative for anything outside approved content. The Commonwealth reported roughly a 65 percent increase in interactions handled entirely by the benefits chatbot after the mid-2025 relaunch. What the public record supports: redesign and controlled escalation accompanied the deployment. What it cannot tell you: how much of the reported change came from the redesign as opposed to model improvements, implementation quality, or a shifting user mix. Take the order, not a causal verdict.

So the practical discipline is archaeology, one artifact at a time. For a given handoff or control, recover why it exists: the policy, the incident, the contract, the constraint. Test whether the cause still holds. Then keep it, redesign it, or remove it, through the authority that owns it. It sounds slow. It is faster than discovering the reason for step five in production.

Mapping work changes the relationship

Excavation has a cost no vendor deck itemizes, and it is relational before it is technical. To map how work really happens, you observe it or instrument it, and the evidence that reveals a broken flow is the same evidence that reveals which individual is slow. Process data becomes performance data the moment someone reads it that way, whatever the stated purpose was, and the people being mapped know this before the project does.

The obligations are real and they vary by place. In Germany, for example, the Works Constitution Act gives a works council co-determination rights over the introduction and use of technical devices designed to monitor employee behavior or performance, and that is one statute in one jurisdiction; consultation, privacy, employment, contractual, and sector-specific duties differ across borders and industries. The operating rule that travels: do not collect until any required consultation or co-determination is concluded rather than merely opened, and until a formal data-protection impact assessment has been completed wherever the collection amounts to systematic monitoring of people, which under European data-protection law it frequently does. Where a works council or equivalent body holds co-determination, its agreement is a precondition and not a courtesy, and the people who own legal, labor, privacy, and contractual risk sign off before the first log is pulled.

Then build the safeguards into the exercise instead of the apology afterward. Purpose limitation, in writing. Minimal collection. Restricted access. Aggregation to roles and flows instead of individuals. A retention limit. Consultation where it is required or simply wise. And a hard prohibition on repurposing the mapping for individual performance action, because the first time that happens, every future mapping meets a workforce that has learned the real purpose.

There is a softer version of the same cost, and it decides whether you get truth. Asking a person to document the knowledge that makes them consequential changes your relationship with them; I have watched workflows look stable for years precisely because experienced people were silently absorbing the exceptions, and the moment you ask them to write that down, they are entitled to ask what happens to them next. Treat the transfer as organizational design, with the current holder designing the new flow and receiving something transparent and policy-compliant in exchange: credit, a development path, a role in the improved system. What no one should promise is that documentation protects a job. The defensible offer is a designed next role, and if the organization cannot describe one, it has heard its own answer.

One handoff, from both sides

Watch the shape on the carried schematic, which remains a schematic and not evidence. In the disputed-renewal workflow, frontline support at some point hands the exception upward: a customer insists they tried to cancel, the standard reply does not cover it, and the case moves to whoever owns approvals. For that handoff to be real, the sender's side needs a definite form: what support sends, through what channel, with the customer's claim and its evidence attached, and what makes the case ready to send instead of half-investigated. The receiver's side needs its own form: how the approval role knows the case arrived, what authority they actually hold over exceptions, and what happens when the case fits no category. And billing, downstream, needs the decision and its reason to travel together, because a refund without its reason is unreconstructable later. None of that says how any real company does it. It says what a handoff is made of.

Now take one handoff from the workflow you selected in chapter nine, and build its record from both sides. From the sending side: the role that releases the work, the artifact that carries it, the system or channel it moves through, and the conditions that make it ready. From the receiving side, gathered separately: the role that takes it, how receipt is actually known, and the exception, the case that arrives at this handoff and cannot follow the standard path. Ask the person who runs the flow daily for one side and the downstream recipient for the other, without letting them confer, then put the two accounts on one page. The divergence between them is the finding, and the exception is where the finding gets interesting, because the exception is where the unwritten rule lives.

Then find the written source for the handoff or its control: the policy, the regulation, the contract, the customer commitment, the documented incident. A source that exists tells you what the step protects. A source nobody can find makes the step a review candidate for the authority that owns it, and a candidate is all it makes it.

Run this under authorization, and keep it about the work. Record roles and process differences, never names or performance judgments; do not observe, time, or rank anyone's individual productivity. If role-level recording cannot be done safely in your environment, stop, and use whatever authorized protected process your organization has instead. The exercise is not worth a person.

The artifact is one page, two sides, four things visible: where the accounts agree, where they diverge, what the exception is, and what the source says. Call it a probe. One handoff cannot grade your Process condition, and it does not need to; it needs to show you what your company knows about its own flow, and what only its people know.

The person-side consequence is a conditional one. A Blank Collar externalizes the repeatable knowledge in their part of the flow, which makes the old value portable and does no more by itself. Growth toward designing the improved flow, teaching it, and owning the exceptions and consequences it cannot settle depends on what the organization supplies: legitimate authority, transition support, learning access, recognition or credit, and a credible next responsibility. Absent those, the transfer design is incomplete, and no seat appears.

What the map permits

What one mapped handoff permits is smaller than a program and more useful: it lets you automate with your eyes open. The dependency runs one way. Observe and review the real flow first, because people describe the process they believe they follow, and the enacted version diverges from the described one in exactly the places automation will find. Prefer observation and records, lawfully gathered, over interviews alone; ask people to explain what the records show, which is a different and better conversation than asking them to recall.

One handoff, mapped from both sides, reveals the mechanism: how flows hold unwritten rules, and how to surface one. The map earns automation of the mapped; it earns no conclusions about the unmapped.

And a legible flow leaves the largest question standing. Suppose the map is drawn, the residue deleted through the right authority, the safeguards written down. The flow will still need to change, next quarter and the quarter after, and every change will land on people who can either carry it, challenge it, and improve it, or execute it silently while working around it. A process is only as alive as the organization's ability to rewrite it. Only as alive as that. Whether your organization can actually do that, and how you would know, is the next condition.