Counting the inbox: what an agent message corpus records about roles nobody designed

An earlier note described running an app-development workflow as four Claude Code sessions coordinating through a shared on-disk inbox, then pointing a fresh session at the accumulated messages and asking it to write the skills. That note ended by admitting the thing that most weakened it: the transcripts lived on another machine, were never counted, and were never quoted, so a reader had no way to check any characterization in it against what the sessions actually wrote.

This note answers the narrower question that admission left open: what is actually in that corpus, and what can counting and reading it establish? The route runs from the outside in. First the shape of the pile — how many messages, over what span, under how many names. Then two views of that pile that need nothing but the filenames: how long each name lasted, and how the traffic rose and fell. Then the parts that need reading rather than counting — how a seat outlived the name attached to it, what a promotion looks like when one session writes it to another, and what the sessions invented in the only structured field the medium gave them. The boundary is stated at the end, and it is a real one: this is a single private corpus, I am the person who ran it, and the counting cannot rescue the sample size.

The shape of the pile

The inbox is a directory tree of Markdown files. There is one directory per Git worktree, a _archive/ subtree for finished correspondence, and a README.md that specifies almost nothing: a filename convention of YYYY-MM-DD_HHMM_from_<sender>.md, a recommended header block, and the note that the sender field “is whatever the writing session self-identifies as” and is “for context only, not routing.”

Counting what accumulated under that convention: 1514 message files, 6.1 MB of Markdown, filed across 32 inbox directories, spanning 87 days of which 61 carry at least one message. The filenames parse into 48 distinct sender labels.

That last number is the first thing worth pausing on, because the earlier note named 4 roles and described the rest as “a few other codenamed agents” that “came and went.” A few is not what the filenames say. The four survivors — Sightline, Bosun, Shipwright and Drawbridge — account for 38.3% of the dated traffic, so the majority of the corpus was written by names that are not in the skill definitions at all.

The names themselves are not accidental. Each session was asked to pick a code name, and the ones that stuck came from a nautical and construction vocabulary that the sessions maintained without being told to. Conway’s observation runs from an organization’s communication structure to the structure of the system it builds.¹ What is odd about this corpus is that the communication structure is the only part of the organization that was ever written down — there was no org chart for the messages to mirror, so the messages are the whole record of who the organization was. When one session promoted another, it wrote the constraint down explicitly: “existing topology uses nautical / construction-infrastructure metaphors (drawbridge = gate, shipwright = builder, lookout = watcher, trim = sail-trimmer, quartermaster = records-keeper). Pick something that fits.”

How long each name lasted

Sorting every label by the date of its first message and drawing a bar to its last gives Figure 1. I find it the single most informative view of the corpus, because the thing the earlier note asserted from memory — that most roles did not survive — is either visible in it or it is not.

Figure 1. Every sender label parsed from the message filenames, ordered by first appearance, with a bar spanning that label’s first to last dated message; the four roles that became skills are drawn in blue and labelled with their message counts, as are a few short-lived labels discussed in the text. Bars shorter than the minimum drawn width are widened to remain visible, so single-day labels appear as ticks rather than as zero-width marks.

What Figure 1 shows is not a team. It is a churn. Of the 48 labels, 23 have their first and last dated message on the same calendar day, and only 9 span two weeks or more. A handful of those one-day labels are not trivial: trim wrote twenty-one messages and vanished, shakedown fourteen, dockmaster thirteen. These were not sessions that failed to start. They did a day of real work under a name and then the name was never used again.

The earlier note offered a hypothesis for the pattern — that surviving roles each own a decision (what to build, where to build it, what to write, whether to ship) while the ones that died owned a chore any other role could do in passing. Figure 1 is consistent with that and does not test it. Ownership of a decision is a reading of the message contents, not a property of the filename, and I have not coded the corpus against that definition. What Figure 1 establishes is only the shape it draws: a small number of long bars and a long tail of short ones.

How the traffic decayed

The earlier note claimed the bootstrap phase was “very token-expensive,” said the cost was capital rather than operating, and then conceded it had no figures. Message volume is not token count, and I want to be careful not to let one stand in for the other. But the message counts do exist, and they have a shape (Figure 2).

Figure 2. Messages written per calendar week over the life of the corpus, counted from the filename dates. The four-week plateau at the left is the hand-run multi-session phase; the long right tail is the period after the skills existed, when the same workflow ran from a single orchestrator session.

The first four calendar weeks carry 77.4% of all dated messages. The busiest week holds 370 messages and the busiest single day holds 192; the final week of the corpus holds 3, a ratio of 123.3 to one. Inter-agent coordination traffic did not taper gently. It collapsed, and what remains in July is a thin residue of provisioning and retirement notes from Bosun.

The honest reading of Figure 2 is narrower than “the capital cost was worth it.” Coordination messages stopped because the coordination moved inside a single context window, where it costs tokens I did not record and leaves no files to count. Figure 2 measures the disappearance of the artifact, not the disappearance of the work. What it does establish is that the expensive phase was bounded, which was the part of the capital-cost claim that a reader could reasonably have doubted.

The seat outlived the name

Reading rather than counting starts here. Several of the short bars in Figure 1 are not separate roles at all; they are the same seat under successive names, and the handoffs are written down (Figure 3).

Figure 3. Three documented successions among short-lived labels. Solid arrows mark handoffs stated in a message; the dashed arrow marks a succession I infer from an identical remit and adjacent dates, with no handoff note in the corpus.

The gate seat is the clearest case, and it contains the detail I did not expect to find. portcullis ran the admin gate for three days in late May and went quiet. Five days later the seat resumed — spelled porticulis, in its own filenames and in its own signature line: “From: porticulis (gh-gate / admin verbs decomp)”. Its counterpart that day, keelson, adopted the misspelling too, and the two exchanged messages under the wrong name for the rest of the day without either noticing. The correctly spelled form still appears more than two hundred times in message bodies elsewhere in the corpus.

I think this is the most instructive accident in the pile, because it is the failure mode of the whole distillation idea in miniature. If a role’s identity lives only in a filesystem record, then resuming the role means reading that record, and a transcription error in the record becomes the role. Nothing caught it, because there was nothing to catch it with: no registry, no validation, no schema. Just a name in a filename, copied forward by whoever read it last.

A promotion, in writing

The scout to joiner arrow in Figure 3 is the one succession where both sides of the handoff survive in full, and it is the passage I would put in front of anyone who thinks role boundaries in a multi-agent system are a configuration concern.

quartermaster — the admin review seat — wrote to scout, a discovery-only seat, after a test sweep it judged good:

Sweep #5b was solid. You’re promoted to senior dev for the admin app, effective on your codename ack. Discovery work continues alongside … this isn’t an either/or, it’s expansion. Pick a new codename (NOT trim — that seat was scoped to optimize-not-add-features, you’ll be doing feature work).

The letter then justifies the promotion in six numbered points, of which the second is the one I keep re-reading:

Honest disclosure of the spec issue. The 2px sub-pixel “movement” assertion failure — you correctly identified it as chart re-layout from the auto-dismissed drawer, not a real movement. Didn’t paper over it.

The reply picks a name and argues for it:

joiner — a carpenter who specializes in fitting pieces together … Maps directly to the first feature on my plate — the drag-cascade proposal is literally about joining tasks together respecting their dependencies. The cascade engine is “if you move this joint, the joints connected to it move too.” Joinery is exactly that.

Then it restates the whole contract it has just accepted — expanded scope, continued scope, unchanged topology, who reviews it, who gates it — in a form the next session to read the file could act on cold.

And then joiner wrote 16 messages over 9.6 hours, all on one afternoon: six pull requests, two hotfixes, a synthesis note, and nothing afterwards. The ceremony was elaborate and the tenure was a working day.

It would be easy to read that as a joke about how cheap identity is when it is a string in a filename, and the joke is available. The more useful reading is that the ceremony did the one job it needed to do. What the promotion letter transferred was not status; it was a written contract — standing review conditions, gate authority, what continues, what expands — in the exact form the distillation step later consumed. The seat ended, and the record of what the seat was survived it.

What the filename became

The README.md specified a filename convention with two fields: a timestamp and a sender. It said explicitly that the sender was “for context only, not routing.” Neither instruction held.

457 filenames encode an explicit recipient — ..._from_sightline_to_shipwright_... — which is routing, in the one field the specification said was not for routing. And 146 filenames carry at least one all-capitals status token, from a vocabulary of 29 distinct tokens that nobody specified (Table 1).

Table 1. The most frequent status tokens appearing in message filenames, with counts over the whole corpus and the state each one marks. Case variants are merged (pr-ready includes PR_READY; deploy-live includes DEPLOY_LIVE); the full table of 29 tokens is in the committed input file named in the reproducibility section below.

Drawn as transitions, those tokens are a workflow state machine (Figure 4).

Figure 4. The filename status vocabulary drawn as the state machine it implies, with each transition labelled by its token and the number of filenames carrying it. The dashed edge is the kickback path from the gate back to implementation. Counts are filename occurrences, not distinct work items: a single feature typically generates several pr-ready and deploy-live messages across its revisions.

Two things about Figure 4 seem worth saying and one seems worth resisting.

The first is that the vocabulary is roughly what a ticket tracker’s status field would contain, arrived at without a tracker, in the only structured field a flat directory of files offers. Whether that is a quirk of this corpus or a thing message-file coordination tends to grow is now a question with a shipped product attached, since Claude Code’s experimental agent-teams feature gives each agent a per-agent mailbox file on disk and leaves the message conventions to the agents.² The second is the asymmetry between merge-ok and merge-block. The earlier note said the reviewer “rejected branches that looked done and were not,” and a single blocking filename against thirty-six clearing ones might look like a contradiction. It is not, but only because the filename is a weak instrument: most refusals in this corpus are HOLD notes, correction notes, or objections filed in the body of a message whose filename says nothing about a verdict. Counting rejections properly means reading the messages, and I have not done that systematically.

The thing to resist is calling this convergent design. One person supervised every session in this corpus, and my own habits are in the training data of nothing here but the prompts I wrote. That the sessions reached for a ticket-tracker vocabulary may say something about how coordination protocols form under a minimal specification, or it may say that I have filed a lot of pull requests.

What the sessions wrote to each other

Three passages do more to characterize the corpus than any count I can compute, and I include them because the earlier note’s central claim — that the arguments were the valuable training material — is unverifiable without them.

The first is a race condition, found and named by the session that hit it. Two messages crossed on a file-based bus with no ordering guarantee:

Timing: my 1705 went out two minutes before your 1707, so 1707’s lock … didn’t account for the trace in 1705. I don’t want to silently ship against a locked design OR silently ship a flake — so flagging before I finalize.

The message continues under a heading reading “Agreement first,” lists three points of agreement, and only then states “the one divergence,” with a step-by-step trace of the case where the locked design fails.

The second is a test seat contradicting the implementer that had just declared the branch green:

Ran your on-disk fix against a CLEANLY RESTARTED dev server … Result: 2 failed / 2 passed — and STABLE across two back-to-back runs (deterministic, not flake)

It then hands over a table isolating which listener shape fails, proposes a cause, and declines to assert it: “I’m giving you the repro + the discriminator, not asserting the internal cause.”

The third is the reviewer pushing back on the scoping seat, having been told its authority was equal:

Peter just clarified to me explicitly that drawbridge sits at parity with sightline — push back when something you clear from shipwright smells funny.

Four objections follow. The one I would not have raised myself argues that the scoping seat should not have left a user-facing decision to the implementer’s convenience: allowing it to be folded away “risks regressing the feature’s load-bearing requirement on a fungible-feeling polish call.”

I cannot show you that these excerpts are representative, and I should not imply it. They are three passages I selected from a corpus I hold privately, in support of a claim I made earlier from memory, which is close to the weakest evidentiary position a quotation can occupy. They are offered as existence proofs — this is the register the messages are written in — and nothing more.

How the counts and figures were made

The corpus itself is private and is not published: it is working correspondence from a real business, it names customers and subcontractors, and committing it to a public repository would be publication regardless of whether the site routed it. Excerpts above are transcribed by hand from the message files and lightly redacted — a subcontractor’s name replaced, a feature name generalized — with wording otherwise unaltered; ellipses mark omissions.

What is committed is the aggregate layer the counts come from. An indexing pass parses every filename in the tree for its date, time, sender label and optional recipient, and records each file’s size; from that index four CSV tables are written — per-label first and last dates with message counts, per-day message and byte counts, filename token counts, and corpus totals. Those four tables are the committed analysis inputs, and they contain no message text. A Node.js generator projects them into the typed metrics quoted throughout this post and verifies, in check mode, that a fresh projection of the committed tables reproduces the committed metrics exactly. The bars and coordinates in Figures 1 and 2 are emitted from the same CSVs rather than typed by hand, so a drawn bar and a quoted number cannot disagree.

Environment: CPython 3.13 for the indexing and figure-coordinate emission, Node.js 22 for the metrics projection, standard libraries only, no third-party dependencies and no network access. Figures 1 through 4 are TikZ compiled at site build time by the Hakyll and dvisvgm pipeline described in an earlier note; the source in the repository is the exact input.

The reproducibility level this earns is analysis-reproducible: every metric-referenced count resolves from the committed tables, the coordinates of Figures 1 and 2 are emitted from those tables, and the counts drawn into Figure 4’s labels are checked against the token table by a committed script. The drawn structure of Figures 3 and 4 — which boxes exist and which arrows connect them — is editorial reading, not a generated artifact. The post is not end-to-end reproducible, and cannot become so, because the input corpus will not be published. This is the archived-evidence case — the upstream input exists and is withheld — and a reader who wants to check the step from messages to tables has no way to do it.

Where this reading stops

The counting fixes one of the earlier note’s limitations and leaves the rest standing.

It is still n = 1. One person, one business, one three-month stretch, one set of prompting habits. Nothing here supports a claim about what agent inboxes do in general, and the churn in Figure 1 may reflect my own restlessness about naming sessions more than anything about role formation.

The filenames are a weak instrument. Every count in this post is a count of filenames, and a filename is a label a session chose. Sender labels are self-assigned and unvalidated — portcullis and porticulis are counted here as two labels, which is right for a filename census and wrong for a census of seats. Message counts are not token counts, not work, and not cost.

The excerpts are unverifiable. They come from a corpus the reader cannot see, selected by the person whose earlier characterization they support. I have tried to select against myself — the promotion letter is faintly absurd, and the misspelling is an embarrassment — but selection bias is not something the selector gets to certify.

And the causal claim from the earlier note is still untested. That message history makes better role boundaries than up-front design remains a hypothesis these figures decorate rather than examine. The experiment that would test it — the same workflow, skills authored both ways, judged blind — is still not one I have run.

If you have a corpus like this one and have counted it, I would like to know whether the shape in Figures 1 and 2 is anything like yours, and particularly whether your short-lived labels cluster the way mine do. And if the succession pattern in Figure 3 has a name in the literature on organizational memory or on multi-agent systems, I have not found it and would like to be pointed at it.

References