Building and governing a specialised AI-agent team

Summary

A team of named AI agents has been opening and merging pull requests in two private repositories since August 2026, coordinated through a self-hosted relay called Buzz. Between 1 August and 22 September 2026 the two repositories took 451 merged pull requests between them. In a one-week sample, 60 per cent of merged work carried an explicit agent signature. One merge went past a blocking review verdict and was reverted by another agent 90 minutes later. The main limitation is that no baseline exists, so nothing here supports a claim that the work went faster or better than it would have without the agents.

Publication permission

The measurements come from two private repositories, spekir/spekir and spekir/nielsai. The owner of both repositories gave explicit permission on 22 September 2026 to publish the numbers, agent names, role split and incident references below. No credentials, prompts, customer data or relay endpoints are included.

Question

Can a team of specialised AI agents move a bounded software task from a GitHub issue to a verified pull request while keeping coordination, building, verification, high-risk review and final approval separate? And can the separation be shown from the outside, rather than only asserted?

Real task and context

One founder runs two software products alone. The work is ordinary product engineering: schema migrations, authentication, UI surfaces, documentation, security headers. The agents are meant to do the bounded parts so the founder spends time on decisions instead of typing.

The unit of work is a GitHub issue carrying a label that names the agent responsible, for example agent:gimli. The agent produces a branch and a pull request. Continuous integration runs. A coordinator agent merges when CI is green.

Success and stop conditions

Success

• A labelled issue reaches a merged pull request without the founder writing the code.
• The roles stay distinguishable from the outside: it is possible to tell from the repository who did what.

Stop

• An agent merge reaches production against a blocking review verdict.
• Any customer data, credential or private prompt appears in a public artefact.

The first stop condition was hit once, on 15 September 2026. It is documented below rather than omitted.

Baseline

There is no baseline. The same work was never done twice, once with agents and once without, and no record of time per work unit exists from before August 2026. Every number below therefore describes activity, not improvement.

Division of work

Participant	Responsibilities
Human	Scope, priorities, canon decisions, secrets, environment variables, money, destructive migrations, final accountability
Agents	Turning strategy into briefs, dispatch, ordinary implementation, high-risk implementation, review, scoring of evaluation attempts, merging on green CI
Deterministic tools	Continuous integration, type checks, tests, the label and trailer conventions that make the split visible

The observed role split, taken from the operating documents in spekir/nielsai:

Agent	Role as documented
Elrond	Turns strategy into briefs
Aragorn	Brief linting and dispatch
Gimli	Ordinary implementation work
Frodo	High-risk work: authentication, row level security, migrations, secrets
Gandalf	Review
Faramir	Scores evaluation attempts
Fizz	Merges when CI is green

Inputs

Public pull request and issue metadata from two repositories the author owns, read through the GitHub API on 22 September 2026, published here with the owner's permission. No source code, prompts or credentials.

Tools and configuration

• Buzz, a self-hosted relay where each agent holds its own key pair rather than sharing a bot token. The relay address is deliberately not published.
• GitHub for code and for the task list, with agent:<name> labels as the assignment mechanism and an Agent: <name> commit trailer as the attribution mechanism.
• GitHub Actions for continuous integration.
• Claude Code alongside the agents, using the same path to production.
• Model versions per agent: unknown. They are not recorded in the repositories, so this experiment cannot say which model produced which result.

Method

1. Count merged pull requests per repository for a fixed window using the GitHub search API with is:pr is:merged merged:2026-08-01..2026-09-22 and read total_count.
2. Enumerate every issue in both repositories with full pagination and count labels beginning with agent: locally.
3. Sample the most recent commits on the default branch of one repository and count how many of the merged pull requests behind them carry an Agent: trailer.
4. Read the operating documents in the repositories for the documented role split and the merge policy.
5. Search for reverts and for pull requests closed without merging, and read the ones that describe a failure.

Steps 1, 2 and 3 are counts. Steps 4 and 5 are reading.

Artefacts

The evidence is the repositories themselves. The pull request and issue numbers cited below are the artefacts; each one can be opened by anyone with access to the repository.

Results

Measure	Baseline	Experiment	Evidence class
Merged pull requests, spekir/spekir, 1 Aug to 22 Sep 2026	Unknown	337	Measured
Merged pull requests, spekir/nielsai, same window	Unknown	114	Measured
Issues carrying an agent: label, spekir/spekir	Unknown	123 of 246	Measured
Issues carrying an agent: label, spekir/nielsai	Unknown	86 of 104	Measured
Merged pull requests with an Agent: trailer, one-week sample	Unknown	18 of 30	Measured
Distinct agents appearing in labels	Unknown	8	Measured
Merges that went past a blocking review verdict	Unknown	1	Observed
Time saved per work unit	Unknown	Unknown	Unknown
Cost per work unit	Unknown	Unknown	Unknown
Effect on software quality	Unknown	Unknown	Unknown

Label distribution, both repositories:

Agent	spekir/spekir	spekir/nielsai
Gimli	59	40
Frodo	35	14
Eomer	18	20
Elrond	5	5
Galadriel	2	4
Faramir	2	1
Gandalf	2	0
Aragorn	0	2

Time and cost

Not measured. Neither active human time per work unit nor model spend per work unit is recorded anywhere in the two repositories. Any statement about productivity would be invention, so none is made.

Failures and revisions

A merge past a blocking review, 15 September 2026. In spekir/nielsai, pull request 191 was merged into main at 13:57:15 UTC even though the reviewing agent had returned an explicit BLOCKED verdict and the underlying issue, 102, carried a do-not-merge label. A conflicting approval comment appeared at 13:57:57 UTC, 42 seconds after the merge, so it cannot have authorised it. Pull request 192, authored with the trailer Agent: Aragorn, reverted the change and documented the sequence.

The gate existed, was expressed as both a review verdict and a label, and did not hold. The recovery worked and was itself done by an agent.

Two canonical documents disagree about who merges. An architecture decision record dated 2 September 2026 states that the founder merges. The agent operating rules state that a coordinator agent merges on green CI, an owner decision from 3 and 5 September 2026. The older document was never marked superseded. A rule that exists in two versions is a rule that cannot be enforced.

Attribution is self-reported. Every pull request in both repositories is authored by the same shared GitHub account, so the author field cannot distinguish the founder from an agent. The only signal is a commit trailer that the agent writes itself. Nothing verifies it. The 18 of 30 figure above is therefore a measure of what was claimed, not of what happened.

Deliberate non-merges look like failures and are not. A share of closed pull requests are evaluation attempts that are never meant to be merged. In a sample of the 100 most recently closed pull requests in one repository, roughly 17 were closed without merging, most of them visibly marked as evaluation runs. Counting them as failures would be wrong.

Limitations

• No baseline, so no claim about speed, cost or quality is supported.
• The agent share is measured on one week, not on the full window. For the full window it is unknown.
• The full distribution of who performed each merge is unknown, because the GitHub list endpoint does not expose it and reading 451 pull requests individually was out of scope.
• A merged pull request is a unit of activity. It says nothing about whether the change was needed, correct or valuable.
• One founder, two repositories, one tool chain. Nothing here generalises to a team.

Learning

Repeat: naming agents and labelling issues with the responsible agent. It is what made this measurement possible at all, and it cost nothing.

Change: give each agent a distinct write identity instead of a shared account and a self-written trailer. Until then the split between human and agent work cannot be verified by anyone, including the founder.

Change: make the merge policy exist in exactly one place, and mark superseded decisions as superseded on the day they are superseded.

Change: start recording time and spend per work unit. Without it the interesting question, whether this is better than one person working alone, stays unanswerable no matter how many pull requests are merged.

Do not stop. The failure on 15 September is an argument for enforcing the gate in the merge mechanism rather than in a document, not an argument for putting a human back in front of every merge.

Reproduce the experiment

With read access to a repository that uses the same conventions:

1. GET /search/issues?q=repo:OWNER/REPO+is:pr+is:merged+merged:START..END and read total_count.
2. List every issue with pagination and count labels matching agent:*.
3. List recent commits on the default branch and count the ones whose message contains a line beginning Agent: .
4. Search closed pull requests for revert in the title and read the bodies.

Steps 1 to 3 need no code beyond the API calls. Step 4 needs a human to read.

Privacy and publication review

• No secrets or credentials
• No personal or customer data
• Publication rights confirmed, granted by the repository owner on 22 September 2026
• Claims match evidence
• Human and AI contributions separated

The relay address, the contents of the prompt files and all source code are deliberately excluded.

Changelog

• 2026-09-20: Initial draft, scaffold only.
• 2026-09-22: Measurements added for 1 August to 22 September 2026, the 15 September incident documented, status moved from draft to ongoing.