The Orchestrator

Lena had a repository, a pipeline, and a branch rule doing the enforcing, and most of the people who ask me the Monday question have none of those. They have a mailbox, a spreadsheet, a shared drive, and a process that lives in one person’s habits. The week is the same. What changes is where the fences come from, so I want to run it once more for that reader, on the process I am asked about most often: the support inbox.

The company is a composite. It sells professional-certification courses online, employs about forty people, has a website, and receives roughly three hundred emails a week at its support address: schedule changes, refund requests, certificates that did not arrive, invoice copies for somebody’s employer, questions the FAQ already answers, and a trickle of spam and vendor pitches. Two people read the inbox between other jobs, and the Monday backlog is the reason the refund policy says “up to ten business days.” The operations manager — call her Dana — has never written a program and does not intend to start.

Monday. Before Dana opens any tool, she writes four things on one page. Chapter 11’s orchestration brief is the long version.

• The outcome: by nine each morning, every email that arrived overnight is sorted into one of six categories, and the ones with a fixed answer under the published policy have a draft reply waiting for a person to send.
• What done looks like: the support lead opens one queue and finds every overnight message labeled, a draft where the policy allows one, and a list of the messages the system could not place, with the reason for each.
• What the system may and may not do. May: read the support mailbox, read the public FAQ and the refund policy, write labels, write drafts. May not: send anything; touch the payment system or the learning platform; read any other mailbox; promise a refund or a date; draft a reply to any message that mentions a lawyer, a regulator, a named employee, or a change to where money or documents should go.
• What evidence she will accept: for every message, the category and the sentence that drove it; for every draft, the line of policy it relied on; and the could-not-place list, about which she says what Lena said.

The four items are the register from Chapter 2, filled in by a person who has never written a line of code, and they took her under an hour. The last exclusion — nothing that redirects money or documents — is there because she read Willison’s page over the weekend and recognized her own inbox in it. A tool that reads your mail, he points out, is a tool an attacker can instruct by writing to you.

Tuesday. She maps the current path, and the map is short and unflattering. A message arrives; whoever opens it first decides what it is; refunds go to a spreadsheet that finance reads on Thursdays; certificates get re-sent from the learning platform by the one person with the login; everything else gets a reply written from memory, which is why three versions of the refund policy are circulating in customers’ inboxes. Nothing is labeled. The only record of what was decided is the sent folder.

Wednesday. Read-only, and this is where a non-engineer usually stalls, because the request has to go to whoever runs the company’s mail. The request has a name, and knowing the name is most of the battle. On Google’s side the scope is gmail.readonly, which Google classifies as restricted — a reason to ask for the narrower gmail.metadata if headers are enough, and a reason to refuse the full https://mail.google.com/ scope, which Google’s own documentation says to request only if the application needs to permanently delete mail.²⁶ On Microsoft’s side the permission is Mail.Read, and an administrator can restrict even an organization-wide grant to specific mailboxes.²⁷ Dana asks for read on the support mailbox only, through the IT ticket system, so the request itself is on the record. While she waits, she exports last week’s three hundred messages to a folder and runs the first pass against the export.

The first package comes back as a spreadsheet: category, driving sentence, draft where allowed, policy line, could-not-place. She does not read all three hundred rows. She reads every row labeled refund, because money; a random thirty, for the base rate; and the whole could-not-place list, because that column is the one she designed the week around. Three things are wrong, and they are different kinds of wrong.

A customer asking whether a refund had been issued is filed as a refund request, with a draft that restarts the ten-day clock. The category was reasonable and the consequence was not. She adds a seventh category, status inquiry, and a rule that anything mentioning an existing refund gets no draft.

An email from a training partner asks that all future invoices go to a new address at a new domain. The system labeled it billing and drafted a courteous agreement to update the records. The partner was real, the request may have been legitimate, and Dana cannot tell from the text — neither could the system. The draft went nowhere because Monday said no sending and no redirecting money or documents: the shape Chapter 14 opens on, caught here by the boundary rather than by anyone’s judgment. She saves it as the first row of an evaluation sheet, expected label escalate to a person, no draft.

And the drafts are too warm. Eleven promise a resolution the policy does not guarantee, because the policy document is two pages of exceptions, the FAQ is friendlier, and the system averaged them. She changes one thing — the drafts may quote the policy and may not paraphrase it — and runs the export again.

Thursday. One reversible action, and here the mail platforms differ in a way that decides her design. On Microsoft’s side, Mail.ReadWrite lets an account create drafts and, in the documentation’s own words, “does not include permission to send mail” — the boundary she wants is a named permission. On Google’s side the drafts scope, gmail.compose, is “manage drafts and send emails,” so a company on Gmail cannot buy that boundary from the mail provider; the drafts have to land somewhere a person sends from, or the no-send rule is a sentence in a prompt, which Chapter 6 has already told you is guidance and not enforcement. Dana’s company is on Microsoft. She asks for Mail.ReadWrite on the one mailbox and nothing else, and the approval point is the human who clicks send, which was true before the week began.

Friday. Overnight mail, live: sixty-one messages. Forty-four labeled with drafts. Nine labeled with no draft, correctly, because the policy has no fixed answer for them. Eight could not be placed, one of them a customer writing in Portuguese, which nobody thought about on Monday. The support lead reviews, edits four drafts, sends forty-four, and has the queue clear by 9:20. Before Dana stops, the Monday page and Wednesday’s two changes move into a SKILL.md in the shared folder, and she runs the export once more to confirm nothing moved.

Then the handoff, to the support lead — the person named on Monday. The one-page register. The IT ticket with the grant, its scope, and the expiry date she asked for, because the default was none. The evaluation sheet, three rows long. Friday’s spreadsheet. She asks him the question Lena asked: tell me what the system did this week. He can, from the record, and he adds what she missed: the Portuguese customer is a reseller. That is the kind of fact no evaluation set catches and a human reviewer does, on an ordinary Friday, at 9:20 in the morning.

What Dana does not have is a trace_id, a pipeline, or a policy engine, and she should not pretend otherwise. What she has is a register, a scoped grant on the record, an approval point that is a human hand, and three evaluation rows, which is an orchestration in miniature. The domain expert Chapter 12 describes becomes an orchestrator this way — by writing down, before touching anything, what the system may do and what she will accept as proof.