The Orchestrator

Take a process nobody would call strategic. A software company with a website ships several times a week, and every Friday somebody has to tell three audiences what changed: customers, through a public changelog page; support, so they can answer Monday’s tickets; and the account managers. The job rotates among engineers, takes an afternoon, and is wrong often enough that support has learned to wait for customers to tell them what shipped. An engineering manager — call her Lena; a composite, but every piece of her week is ordinary — runs the sequence on it.

Monday. The outcome in one sentence: by Friday at two, support and the account managers have an accurate, plain-language account of what changed in production this week, and the public changelog is ready for one person to approve. Then five exclusions: nothing described as shipped that has not deployed; nothing behind a disabled flag described as available; no internal ticket text or customer names; nothing published without a named person’s approval; no access to the deploy pipeline or the source repositories except to read. She fills in the register from Chapter 2 by hand, and the truthful entry under what remains uncertain is that she does not know how the current notes get written.

Tuesday. So she maps it. No agents; she reads. The engineer on rotation scrolls the merged pull requests since the last release tag, pastes the titles into a document, and a product manager rewrites them Monday morning, which is why support gets them Monday afternoon. Three things get lost. Pull-request titles say what a developer meant, not what a customer will see. Squash merges hide which change belongs to which ticket. Merged is not shipped: the team uses feature flags, so a change can sit in main for a week with nothing visible, while the deploy log — the one record of what reached production — is read by nobody. The real path is merge, deploy, flag on, visible. The current notes are written from step one.

Wednesday. Read-only access, scoped the way Day 3 says: GitHub’s MCP server in its read-only mode, which drops every write tool from what the agent can see, including tools named explicitly in its configuration,²³ and a fine-grained personal access token limited to the two application repositories, granted contents: read, pull requests: read, and metadata: read, expiring in thirty days.²⁴ No deploy-system access yet; she exports the week’s production deploy log herself and hands it over as a file. Then the evidence package: for every pull request merged since last Friday’s tag, its number, title, ticket, and commit; whether that commit appears in a production deploy; and — the part she insists on — a list of what the system could not determine. If the list comes back empty, she wants to know why.

The first package arrives that afternoon, well organized, and wrong in one place. It describes a new export format as shipped. She checks: merged Tuesday, deployed Tuesday, behind a flag that is off. The system had no access to the flag service, so it could not have known; it should have put the item on the could-not-determine list, and instead it asserted. That is the failure the week was designed to catch, and what caught it was not the model’s judgment but the boundary. The wrong sentence went into a draft one person read, because Monday’s exclusions said no writes and no publishing without approval, and it cost her twenty minutes instead of a week of support tickets. She saves the case as a row in an evaluation set — pull request number, expected classification merged, not visible — changes one instruction so that shipped requires a production deploy and either no flag or a flag state a person has confirmed, and runs Wednesday again. The export format moves to the right section.

Thursday. One reversible action, the most boring one available: the system may open a pull request against the documentation repository containing the draft changelog page. That repository already requires a human review before anything merges to main, and the public site deploys from main, so a rule that existed before this week does the enforcing;²⁵ a second token, scoped to that one repository, gets write access to contents and pull requests and nothing else. What she refuses is the convenient list. No token for the deploy system. No access to the support queue, which is full of customer data whose handling policy she has not read. No access to the flag service until she has read its API herself, for the reason Chapter 12 gives Marcus.

Friday. The real case, end to end. The package lists fourteen merged pull requests — eleven deployed and visible, two merged and flagged off, and one it could not correlate to any deploy because the exported log ended Thursday night. It says so, in the list she asked for. The pull request opens with the customer-facing page, a note to support on the two flagged changes, and the evidence attached. The product manager fixes one sentence that describes a settings change from the wrong side of the screen, and approves. Support has the notes at 1:40 p.m. Before she stops, Wednesday’s instruction moves out of the prompt and into a SKILL.md in the docs repository, where it is versioned and reviewable, and the package runs once more to confirm nothing moved.

Then the handoff, to the engineer whose rotation starts Monday. The register. Both tokens, their scopes, and the date they expire. Wednesday’s evaluation row. The pull request. The trace_id of Friday’s run. She does not walk him through it; she gives him the record and asks him to tell her what the system did this week. That is the test. If they cannot reconstruct what the system did from that record, you do not have an orchestration yet. You have a private habit.