Every Department's Agent Map Looks the Same
I mapped agents onto twelve company functions. The maps converged on one design, and the real work turned out to be the refusal list.
The views expressed here are my own and are not related to or reflective of my work or any organization I am affiliated with.
Somewhere around the fifth agent map, I stopped designing and started transcribing.
I’d spent the weeks before on a design exercise: mapping agents onto every function of a company. By agent I mean a language model wired into tools and given a job: it reads your systems and takes the next step without a person driving every click.
Engineering, sales, customer success, people, finance, legal, marketing, product, design, data, support, and the exec team. Twelve maps, one per function, each answering the same question: which work goes to agents, and which work does the department refuse to give up? It’s a software company’s org chart; the maps say nothing about work done with hands.
A design exercise is a wind tunnel. You can rewire all twelve functions at once and delete any meeting you like. And paper is more honest than a slide deck: there’s no incentive to round the numbers up.
Each map is a document: one process written out twice, before and after, plus a one-page spec and a starter prompt for each agent. The exercise produced 93 prompts and 92 specs. None of them is the artifact that matters.
Each map ends with a named pattern: one line on how the work splits between agents and people. Engineering’s came out as delegate, review, own. Two functions later I wrote it again for customer success, with an always-on monitor bolted on the front. By the fifth map, finance, I caught myself typing the same three beats a third time with the department’s nouns swapped in: delegate the reconciliation, review the variances, own the decisions.
Map twelve departments to agents, one after another, and you draw the same map twelve times.
One hand drew all twelve. Hear that objection now; it’s the real one. A pattern that captures the mapper at map five isn’t tested by maps six through twelve; it’s transcribed. The convergence is a hypothesis one mapper can generate but cannot confirm. What follows is the hypothesis, drawn as sharply as I can.
The unit is the process, not the department
You can’t give a department an agent. “Department” is an org-chart word; work doesn’t happen at that altitude. It happens as processes: a feature ships, a call gets prepped, a month closes, a contract gets redlined, a ticket gets answered.
So for each function I picked the one process where the week actually goes, and wrote its timeline twice. Once as it runs today, with an honest clock against each step. Once with agents in the loop.
The before-timeline is the whole method. Writing it honestly is uncomfortable, because most steps turn out to be one of three things: watching (checking a dashboard, waiting for a signal, sitting in a status meeting), typing (reconciling two systems, re-keying a CRM, rebuilding a deck from a template), or judging (deciding, pricing, subtracting, saying no). Only the third kind reliably needed the person.
Walk the departments and the shape repeats. In engineering, the process is shipping one feature: the agent-able work is the scaffolding, the tests, the draft pull requests (code changes queued for review), and the three parallel prototypes you’d never staff with humans; the human work is the architecture call and the review.
In sales, it’s call prep and follow-up: an agent fans out across the calendar, the CRM, and every past note, and compresses the tab-hopping into a one-page brief. The rep’s edit of that brief is the value. Customer success runs the same shape overnight: watch account health, draft the save plan, let the human decide whether this customer gets an email or a call.
In finance, the month-end close sorts into the three piles, not purely: reconciliation is typing with grains of judgment in it (someone decides which record wins), and the agent’s job is to hand the controller the short list that needs a person. In legal, a redline agent drafts counter-language for the pattern-match clauses (payment terms, auto-renew, data residency) so the human hour goes to the one clause that matters.
Support, on my map, drafts every reply and sends none of them. Plenty of real orgs auto-send the easy tier; I drew the stricter line, because a boundary written down can be loosened on purpose. Data correlates an anomaly and proposes a root cause; a human verifies it with a direct query, because the query doesn’t hallucinate and the agent might.
Even the exec team reduces to a process: the Monday status ritual. An agent assembles the digest from the systems of record (the CRM, the ledger, the ticket queue) before anyone wakes up, which changes what the meeting is for.
Meetings that existed to move information die. Meetings that exist to make a decision survive.
That single distinction cleared more calendar, on paper, than any individual agent did.
Three shapes of agent, three things humans keep
Here’s the convergence. Across twelve functions I thought I was designing dozens of agents. I was designing three, over and over.
The watcher. An always-on process that monitors a system of record and raises its hand: account health dropping, a metric drifting, a contract landing in the inbox. Watchers replace the human habit of polling, and the weekly meeting whose real job was polling on a schedule.
The drafter. Given a signal, it produces the first version of the artifact the process needs: the reply, the redline, the brief, the board pack, the save plan. Drafters don’t shorten the judgment. They move the human from a blank page to a review.
The reconciler. The pure-typing tier: moving the same fact between two systems, categorizing, scheduling, logging. (Routing stayed out; triage looks like typing and is mostly judgment.) I wanted to write that reconcilers tolerate the most autonomy, because the work was never judgment to begin with. That’s wrong, and my own evidence says so.
Autonomy tolerance tracks reversibility and blast radius, not how boring the work is. Watchers tolerate the most autonomy because they only read. A reconciler earns autonomy only where its writes are cheap to verify and cheap to reverse. The dangerous middle is a reconciler writing silently to a system of record.
None of the three shapes is new. The industry already sells them as monitoring, copilots, and RPA (the software that has clicked through forms for a decade); three categories converged on these shapes before I drew anything. What the maps add is where each shape stops.
In every function, the humans kept the same three things. The send: nothing leaves the building (an email, a reply, a wire, a filing) without a person behind it. The signature: money, offers, terminations, attestations. The subtraction: deciding what not to build, which deal not to chase, which clause not to concede. Agents are additive by temperament; every one I’ve run suggests more, never less. Choosing less stayed human on every map I drew.
The agent drafts. The human sends.
If the twelve maps compress to one sentence, it’s that one.
It has a cost. There’s a fourth keep buried in the first three: the check. Drafters relocate judgment into review; doing-time becomes reviewing-time, and at volume that’s what bites first. A person can read a hundred drafts a day or rubber-stamp a thousand, not both. The maps hold only if review hours are budgeted as real work. A send without a check is a stamp with a person’s name on it.
The refusal list was the hardest artifact
Every map ends with a section I first treated as a disclaimer and finished treating as the design itself: the list of things agents never do there. No agent moves money. No agent sends to a customer. No agent drafts any part of a termination. Brand voice is written by a person. Deals above a threshold get human eyes on every clause.
The automation was easy to write. The refusal list took the design.
Easy, because the drafting-and-watching layer is almost generic on paper: the same patterns, the same reusable instructions, lightly re-skinned per function. On paper is the load-bearing phrase: the connector plumbing (auth, permissions, data quality) is where deployment goes to die.
Hard, because every refusal is a claim about where judgment actually lives in that department, and you can’t write it without understanding the work. When a function’s refusal list wouldn’t come, the reason was the same each time: I didn’t understand the function yet. The automation I’d sketched for it was the least trustworthy thing on the page.
You wouldn’t get the list by asking, either. Ask a department head what they’d refuse to automate and I suspect you’d get a blank, because intuition doesn’t know its own address. Ask what they’d never let a brand-new hire send without review, and the list writes itself. Every department already has a refusal list. It’s filed under supervision.
The regulated corners wrote theirs down long ago: approval matrices, maker-checker rules, segregation of duties. Those were written for humans; extending them to agents is unclaimed work.
The failure mode is shipping the automation without the refusal list. That’s the org that lets a support agent auto-send at 2 a.m., discovers the hard line only after crossing it, and then swings to banning agents entirely. The refusal list is what lets you delegate aggressively everywhere else. It’s the trade in everything I’ve built with agents: autonomy is purchased with boundaries, not with trust.
A department’s agent map is two lists: what the agents take, and what the humans refuse to give.
What’s real here, and what isn’t
These are maps, and I want to be precise about what that buys. The timelines are designs, not measurements: every map carries a before-clock and an after-clock, the after column is always flattering, and none of those paper numbers appear here. I have not watched a real company close its books faster because a map said it could.
Designed is not deployed. A pattern that recurs on paper is a hypothesis, not a result.
What I’ll stand behind is the method: pick one process, write the before-timeline honestly, sort the steps into watching, typing, and judging, put agents under the first two, then hunt the judgment hiding inside them.
The longest-running agent I operate is the watcher on my own money. It reads a read-only mirror of my accounts and sends a two-line morning brief, plus a flag if something looks off. Its refusal list is physical: the app holds transactions and nothing else, so the worst it can do is read back what I already spent. It ran like clockwork for months, then I stopped tending it and the briefs thinned out. Click-through plumbing is brittle; it rots quietly when nobody looks.
That’s the part no map can tell you: designed patterns don’t decay, deployed ones do. The maps get you to the right design. Somebody still has to keep it running. And it grounds only one shape. The watcher I’ve run; the drafter and the reconciler I’ve only drawn.
On paper, the convergence held all twelve times: the three agent shapes, the three human keeps, the refusal list as the real design surface.
Running the exercise on a department you own needs no vendor and no model picked first. It’s a document and four questions:
Which single process eats the week?
Of its steps, which are watching, which are typing, which are judging?
What should an agent draft, and who sends it?
What will you refuse to automate, in writing, before you automate anything?
Building the agents the answers describe is a separate problem. Drawing the map isn’t.
The maps will never ship a feature or close a quarter. That was never the point. I drew them to find out whether twelve different departments would produce twelve different answers. On paper, from one hand, is as far as the finding goes. Whether it survives other hands and real orgs is the experiment I haven’t run.
They produced one.
Related: what happened when this lens met a real engineering org is in I Wrote a Plan. The Work Steered It.
The views expressed here are my own and are not related to or reflective of my work or any organization I am affiliated with.