Tools · Our own agent factory, in daily use

Composer: one brief, a crew of AI agents, every step checked.

Composer turns one job into a plan a crew of agents can carry out: research it, build it, then try to break it. The agent that built it never grades it.

Installed privatelyMac and Linux workers, one coordinating hub. Updated October 30, 2026.

A completed Composer run: a project with its workflow stages, Investigate, Build and Test, each showing its agents, all steps finished.
A real completed Composer run (archived, Oct 15). Not a live, mid-run view.
195projects held in ComposerReported · Oct 28
16agents at once, seen on LinuxObserved · Oct 27
2computers, one hubMac and Linux
193runs on record, failures includedReported · Oct 28

What it does for a team running agents

01 · Plan the crew

Agents stop babysitting each other.

I watched one of my agents coordinate a job by hand: picking workers, briefing them, checking on them and gathering their results. Composer does that part. Lay out who researches, who builds and who reviews, in order; Composer launches them, tracks them and collects what comes back. My agents were its first users.

Notebook sketch, Fig. 3: one brief branching into research, build and review, with a person watching from the side.
Fig. 3 · One brief, one crew.
Notebook sketch, Fig. 4: one seat reached through four doors labeled CLI, API, plan and plug-in, beside a receipt reading requested model A, served model A.
Fig. 4 · The model is the seat; routes are doors. The receipt records the model the provider reports.

02 · Models and provider routes

Mix AI companies. Keep the model receipt.

Models from several AI companies work side by side. Compatible OpenAI-style chat APIs can be added by configuration; other protocols need adapters. Supported plug-in routes record the requested and provider-reported model IDs and flag a mismatch. That records what the provider reports, not an independent inspection of its model.

03 · Checked by the other side

The builder never grades its own work.

The builder tests and reviews its own work; then a reviewer from a different AI company checks it, often blind: it sees the work, not the builder’s explanation. We use a fresh reviewer from another model family to bring a separate perspective.

Notebook sketch: a builder hands work across a line to two reviewers who see only the work, then an arrow to an independent checker.
The reviewers see the work, not the builder’s notes. Then an independent check.
Composer’s review screen before a run, listing who may run each step, with a separate Start step. Sample data.
Review before Start · sample data.

04 · Nothing runs by surprise

Save, review, then press Start.

A person or an approved agent can set up a run. Reading a project doesn’t grant permission to launch it. Nothing starts until someone reviews it and presses Start, and the run that starts is the one that was reviewed.

05 · A record of every run

“Finished” means something you can check.

Every run keeps its record: what was asked, who did it, what came back and what was checked. Failures stay in, so the next project starts from what actually happened.

RoomKit’s read-only project records view, listing a project’s steps, statuses and checks, with the project name blurred.
RoomKit’s project records, a related view. Project name blurred.

Results, failures included

On real work.

● Sept 26

One review, start to finish

Seven blind reviewers from two AI model families found 18 problems. Sixteen were fixed; two were put off on purpose, with reasons.

Follow the recorded run →

● Partial

Useful research, a failed repair

A recorded Video Evidence Engine job returned useful research, but its repair stage errored and produced no verified patch. A useful partial result is still partial.

● Blocked

The run that never started

An October comparison stopped after two Start timeouts, with zero workers dispatched. Its cause is unknown, so it stays blocked rather than becoming a duplicate.

More experiments and their limits →

Design choices

Two choices built into Composer.

Separate the review from the build, and keep a record of the provider route.

Independent review

Builders test and review their own work first.

Then a fresh review

A separate agent checks the work; the September 26 run used two model families.

Model receipts

A request alone does not establish which model answered.

Supported plug-in routes

Receipts retain requested and provider-reported model IDs, with a mismatch flagged.

Where it stands

Useful, and still evolving.

Composer is our private workflow tool; it isn’t available to install. Installed jobs have used native workers and provider plug-ins. The text plug-ins return text; they don’t give a model a filesystem, browser or executed tool loop. We haven’t measured a general speed-up or how much operator intervention each finished job saves.

We run our work this way every day. Want your agents run this way too?

Composer is our own tool. The thinking behind it, crews from rival AI companies, checks they can’t skip and a record of every run, is what I bring to a team.

A dated working report, not peer-reviewed research. Read it as Markdown · Meet Foundry →