A whole development team, one specialist at a time.
Not one model reading your diff. 23 specialists, each reviewing through exactly one lens, verified against their own criteria, re-scored by an independent consultant, and merged by defect rather than by reviewer. Then the same machinery run backwards: an acceptance contract, a build loop, and a gate that decides after every increment whether you are actually closer.
Developer preview
- 9 teams
- 23 devteam specialists
- 19 review scopes
- 7,360 tests
One model reading a diff has one opinion. This has twenty-three, and they disagree.
Ask a single reviewer to check security, concurrency, data persistence, accessibility and test coverage in one pass and you get an average of five shallow passes. Every specialist here reviews through exactly one lens, in its own dispatch, and no reviewer ever sees the whole roster — so no reviewer can quietly assume someone else covered it.
A review bot
One pass, one voice, one confidence number.
- Reads the whole diff through one general prompt
- Scores its own findings’ confidence
- Drops everything under a threshold to look precise
- Duplicates the same defect once per concern it noticed
- Tells you what it thinks; the fix is your problem
The Agentic Developer Team
A roster, a verifier, and an independent scorer.
- One dispatch per specialist, chosen by a deterministic signal floor plus an agentic interest poll
- A verifier checks each specialist against that specialty’s own criteria and can force a bounded re-review
- Confidence recomputed by a consultant that is blind to who found it — and that never deletes a finding
- Findings merge on file and symbol, so two lanes hitting the same line corroborate instead of duplicating
--fixturns the report into commits, gated by an independent re-review rather than by its own contract
The no-muting rule is the one worth arguing about. Dropping low-confidence findings is the industry default; this pipeline refuses it and asserts the refusal in a test. A missed expensive-to-unwind defect is the costly failure. A low-priority note you skim past is not.
Eight stages between your diff and one ranked report.
Nothing here is a single prompt with a long system message. Each stage has one job, and the ones that matter most — selection, verification, scoring — are deliberately performed by something that did not do the stage before it.
- Changeset
- The merge-base diff, with every file classified by technology signal.
- Scope
- A named roster resolved from team data before anything agentic runs — nineteen of them, composing as a union.
- Selection
- Two tiers: a deterministic signal floor plus the always-on specialists, then an agentic interest poll for the discretionary candidates.
- Pre-checks
- Your repo’s own linters and typecheckers run first, and their diagnostics are folded in as leads so the workers stop re-reporting them.
- Reviewers
- One dispatch per specialist. An oversized diff is chunked hunk-aware and map-reduced — nothing is truncated.
- Verifier
- An independent pass checking each specialist’s findings against that specialty’s own Verify criteria; a fail drives a bounded re-review.
- Consultant
- Every finding re-scored 0–100 against an anchored rubric and a false-positive catalog, blind to who found it.
- Report
- Deduped by defect, ranked, written per model, coalesced, and posted to the pull request.
Nineteen rosters, one default
risk is the default: the union of the eight focused defect scopes — security, safety, data, api, reliability, architecture, code-quality, performance — which is thirteen specialists, plus an always-on fourteenth, the test-coverage reviewer, narrowed under the default to the one question of whether new risk-bearing code is covered at all.
The remaining concern scopes (accessibility, i18n, observability, ui-ux, platform-native, completeness) are opt-in on purpose: a default review that also grades you on internationalization drowns the defects in backfill work.
One root cause, one finding
The merge key is file plus symbol with a line-bucket fallback — and deliberately not the specialist. Two lanes that independently spot the same problem collapse into one row that records both.
It exists because a real run filed one blocking-loop issue five times and one path traversal six times across lanes. Cross-cutting concerns now have owners, and an out-of-lane finding is filed as a capped cross-reference.
Findings in, commits out
A contract is synthesized from the findings you select, a pinned coder with no Bash and no Agent tool edits code, and every path:line it cites must resolve to a line it actually wrote.
The gate is an independent re-review, never the synthesized contract — a loop that grades itself against a target it wrote for itself is not a gate. Three passes maximum, one commit each.
Pin what “done” means before you write any of it.
An acceptance contract is atomic criteria, each with a check hint, pinned before the work starts and never edited mid-run to make a gap disappear. Then the loop runs: pick a lane, brief a coder, verify every citation, commit, and put the result in front of a conformance oracle.
Met, unmet, or divergent
Three verdicts, and the third is the one that matters: divergent means the criterion was satisfied in a way that conflicts with the intent behind it. That is the failure a naive fix hides, and the reason the gate adjudicates per criterion rather than scoring the diff.
While anything is unmet or divergent above severity 50, the readiness record says ready: false. It is written by the gate, not by the coder.
Decided in Python, not in prose
Whether to continue is never re-derived by a model. A recorder compares the current criterion statuses to every prior iteration and returns one action — finish_ready, continue, rerun_gate, reset_and_retry, retarget_unjudged, escalate_once, or a halt with a reason.
Halts fire on done, diminishing returns, budget, an iteration backstop, confirmed oscillation, regression, or a stall.
- Carry-forward semantics. Only criteria this iteration targeted trust the fresh verdict; the rest keep their prior status. Without it the oracle silently forgets what it already proved.
- Anchor checking. A coder can hallucinate an execution claim, but not a diff anchor — so every cited line is checked against the increment, and a second failure blocks the commit.
- One lane per increment. Lane selection is deterministic signal ranking with zero model calls; only a genuine tie escalates to exactly one dispatch, and a failure there degrades loudly rather than guessing.
- The session commits, never the coder. Each increment is its own commit, so the git history is the rollback trail.
| Run | Contract | Outcome | Iterations |
|---|---|---|---|
| reusable-document-search-view | 20 criteria | ready | 4 |
| adh-test-infra-reliability | 5 criteria | ready | 1 |
| land-the-beast | 33 criteria, 3 repos | halted — gate failure | 2 |
Three of ten recorded runs, and the halt is here because it is the informative one: the gate killed that run twice without ever rejecting the work, because the first gate run’s state was destroyed mid-run by the archiver. Six of the ten reached ready and four halted — two of those on budget, one after burning 13.5M tokens against a 10M ceiling. All ten are in the table behind this link. How convergence is measured →
The engine names no team. A team is data.
The composition is registry → team → specialist → specialty, and dispatch is team-first: the first argument is a team, the second is one of its commands. All the Python lives in one generic engine. A team ships a spec, a roster, prompts, and the eval fixture it is judged against — and nothing else.
myteams <team> <command> [args]
myteams devteam review code --base main
myteams devteam plan code
myteams devteam build --contract ~/.myteams/contracts/devteam/feature.json
myteams researchteam research "loop engineering"
myteams teamtester campaign start --spec ./spec.json
myteams registry listNine teams ship today. The available surface is the union of what the installed, enabled teams contribute — there is no intermediate grouping layer and no verb-first fan-out.
- devteam — review, conformance, build
- projectteam — planning
- researchteam — verified research
- storyteam — narrative
- cookbookteam — recipe authoring
- brainstormteam — deliberation
- teambuilder — creates and improves teams
- teamtester — the run observatory
- socialteam — generated, not written
23 specialists, 187 lenses
A specialist is a domain reviewer; a specialty is one narrow competence inside it, carrying both the focus a worker reviews against and the criteria a verifier checks the findings for. That second half is what makes the verifier pass possible at all — it asks “did this specialist cover its own declared ground?”, not “is this finding correct?”
One skill per installed team
Installing a team regenerates the plugin from the live registry, so each enabled team appears as /myagenticteams:<team> alongside the roster and config skills. The skills shell out to the same CLI, so your editor and your terminal run the identical pipeline.
9 teams. One job each.
A team is a directory: a spec, a roster of specialists, the prompts they read, and the eval fixture it is judged against. These are the ones that ship.
brainstormteam
Facilitated, phase-gated brainstorming that crystallizes any idea.
brainstorm
cookbookteam
Authors cookbook recipes, principles, and guidelines from code or intent.
recipe principle guideline project report
devteam
Multi-specialist code review for software projects.
review code-review plan build report
researchteam
Multi-specialist research into cited, ranked claims.
research report
socialteam
Scans AI and agentic-dev news against Mike’s interest profile and writes cited, tiered digests with post angles.
research report
storyteam
Multi-specialist storytelling into grounded markdown stories.
narrate report
teambuilder
Designs, materializes, and improves complete myteams teams from intent.
create-team improve-team report
teamtester
Continually tests and improves the installed teams across LLM backends.
calibrate campaign analyze campaign-report evidence report
47 specialists and 252 review lenses across the 9, unevenly spread on purpose: devteam alone carries 23 of the specialists and 187 of the lenses, because reviewing code is the job with the most distinct ways to be wrong.
8 of the 9 produce runs, so they also answer the six shared commands — report, pause, resume, log, findings and insights — against their latest run without being told which one. A card omits what its team does not have: no scope flags, no scope figure; no roster of its own, and it says so.
The teams are the subject. Something else is the judge.
teamtester runs teams against their own eval fixtures, across models, repeatedly — then reads the results three ways, so a flaky team and a mediocre team come out as different findings instead of one muddled score.
- Tier 1
- Nine deterministic probes over every run, at zero token cost — completion, run records, session outcome, dispatch hygiene, fan-out, verifier coverage, artifact substance, event delivery, stall. They read the subject run’s own SQLite rather than parsing its prose.
- Tier 2
- A sampled slice judged 0–10 per criterion with quoted evidence. The judge is always the same high-reasoning Claude model, whatever backend produced the artifact under test.
- Tier 3
- Campaign-wide defect mining: probe failures, run states and score means pre-compressed by plain
GROUP BY, then one tools-disabled dispatch returning findings from a fixed enum — each linked back to the runs that evidence it. - Capacity
- Median wall time, median dispatches and total tokens per team-and-model pair, rendered as runs per five-hour window. The campaign cadence comes from that number rather than a guess.
Claude, Codex, Qwen
A campaign cell pins its backend in the invocation itself, and the account token rides only in the child environment — never in argv, never in config, never in a log. Comparative reads are queries: same team, same scenario, per-criterion deltas grouped by model.
Variance is first-class. A team scoring 85 with a spread of 3 is better than one scoring 88 with a spread of 20, and re-judging is append-only, because the disagreement between two judgments is itself the data.
7,360 unit tests
Grown from 5,159 in about a month, green at every recorded checkpoint, across 388 test files and 3,506 test functions — 73,298 lines of test Python against 51,299 lines of engine.
With one lesson attached: a routing bug once passed the entire end-to-end suite, because a mock that ignores its prompt cannot reveal that the prompt was missing its most important input. Routing is asserted deterministically now.
A team is scored against its own rubric — then edits itself.
Every team carries an intent contract with at least three weighted excellence criteria and scenarios that are exact command invocations. improve-team runs them, judges each artifact 0–10 per criterion with quoted evidence, proposes edits to the team’s own prompts and rosters, applies the ones you approve, and re-runs to measure whether the edit actually helped.
- 20.0
- socialteam, baseline
- 68.18
- after iteration one
- 87.27
- after iteration two
- halted
- one criterion at 7 of 8
The 20.0 was not bad writing. The generated authoring objective denied its own child web access, so the team honestly reported that it was blocked and produced nothing. Fixing the tool grant took it to 68.18 — but freshness regressed to 1, because a prose instruction was being overridden. Iteration two moved that window into fixed doctrine and freshness went to 10. The lesson written down afterward: doctrine files bind, method prose gets overridden.
The walls, all of them structural:
- The proposing dispatch is read-only. It can propose; it cannot write. The session applies approved edits.
- Nothing under
evals/is ever a valid target. The loop must not edit the rubric it is being judged against. - A clean git tree is required to start, because the rollback trail is load-bearing — a confirmed regression reverts to the best-scoring commit with a revert, never a reset.
- Every iteration pauses for you. A plain “keep going” is enforced by a guard that refuses to advance an un-acknowledged iteration.
- Fixtures are hashed, so a run records exactly which version of the rubric produced its scores. Scores across a fixture edit are not comparable, and the system knows it.
The same machinery creates teams from scratch: eight phases from framing questions through research, design, your approval, materialization, a gate with at most two repair passes, install with a smoke check, and handoff into this loop — a new team is a baseline to be scored, not a finished thing. Nothing is written to the destination before you approve the design. How a team is built and improved →
Landing NOW…
Everything above this line runs on main today. Everything below is real code you cannot yet rely on — either because it is still on a branch, or because it landed with nothing in the box that uses it. Separated out rather than described in the present tense with a caveat a skimmer never reaches.
Memory
A team that forgets everything between runs relearns your codebase every morning. So memory is not a scratch file — it is a real database: Postgres on Crunchy Bridge, pgvector, its own isolated schema, with row-level security drawing the tenant boundary in the engine rather than in application code.
Recall is genuine semantic k-nearest-neighbour — Gemini embeddings in a 1536-dimension column under an HNSW cosine index, queried in strict-order iterative scan so a filtered search cannot quietly come back short. Nothing is overwritten: a fact that stops being true is closed out with a validity range and superseded, so the history of what the team believed stays readable.
Not yet: the part that injects memory into a Claude Code session or a team run automatically. The atomic supersede write is also unbuilt, though its columns exist and recall already filters to active records.
Automated testing
A team that tests the running product, not the source. It drives a real browser through the deployed site and asks the question a suite of unit tests cannot: does this actually work for someone using it?
The expensive part was never running the tests — it is deciding what a failure means. So the run costs nothing: a Playwright matrix sweeps every site at every sign-in tier with no model in the loop at all, and each failure is stamped with a fingerprint that survives the noise, so the same broken thing is recognised as the same broken thing tomorrow instead of being filed again. Only then do the specialists arrive — to judge whether it matters, who it hurts, and what to do about it.
Where it stands: eleven live runs against the real testing tier, a genuine issue filed and the recurrence path exercised, three of thirty-seven sites covered — the declared pilot set, not the finish line. And it is staged in private-teams/, so it is not one of the nine teams an install gives you.
Real tools, over MCP
MCP is how an agent stops being a text generator and starts being an operator. A team declares which servers an objective may use, and the engine hands its workers the real thing — a browser it can click, a test runner it can execute, a database it can query — with the grant scoped to that objective and resolved against a registry, so an unregistered server aborts the wave rather than silently degrading into a team that only pretends to have tools.
The Hub is itself one of those servers. It speaks MCP over a stateless HTTP endpoint today with fifty-two curated tools plus a generic gateway across the whole API, all behind scoped tokens — which is how memory, personas, projects and storage become something a team can reach for rather than something it has to be told.
Granting one is two acts, not one: registering a server does not hand it to anything, and a team is refused at dispatch until it is named in a separate config mcp allow. Its first version failed open in three ways — a substring membership test that consented dev for devteam, a refusal the partial-fan-out filters absorbed so the run finished green, and a path that reached a registered server around the outbound address allow-list.
What is not shipped: a team that uses it. The grant, the consent gate and the external test runner are all on main, and the one team driving a browser through them lives in private-teams/ — installed by the same installer, into the same registry, but deliberately not part of the bundled nine. So nothing you get by installing myteams drives a real browser today.
Named so you can go and look, and dashed so you cannot mistake them for shipped:
- a bundled team that drives a browser
- session memory injection
- atomic supersede
- point-in-time recall
- daemon sync
Pointed at its own commit, it found 95 things.
A review of the project’s own multi-provider review command returned 95 findings across 10 specialists and 2 models, spanning severity 14 to 92. The top one was a genuine concurrency defect: parallel provider runs each opening a separate backend against the same database file, producing intermittent locking and order-dependent failures.
Three separate findings independently flagged the same defect — provider calls gathered with no timeout, able to hang indefinitely. That is exactly what the merge key exists to collapse into one corroborated row. At the other end, the lowest-severity finding was an import inside a conditional block. The pass runs all the way down.
- 807
- commits since April
- 125k
- lines of Python
- 106
- dated history entries
- 1
- author
And the failures, written down with the same care as the wins — nearly all of them found by pointing the system at itself:
- A conformance gate that flipped
ready: falsetotrueon an unchanged target. The two dropped defects reappeared as the top two findings in the same day’s review. - A fully converged build misread as a stall, telling the operator to escalate to a stronger model and redo work that was already done.
- A live progress site that silently never opened for eight of nine teams, while printing a message saying it had.
- A fix wave whose own review found seven second-order defects introduced by the fixes themselves.
- A research run that produced a complete report and then exited non-zero, writing a failure report that admitted in its own words it had never crashed, timed out, or errored.
The limits, stated rather than implied: there is no precision-and-recall benchmark for this pipeline, so every claim about review quality on this page is qualitative. The published field ceiling on automated bug-finding is around 60% F1 and nobody is above it — this is not claimed to be. It is a single-author system exercised on a small number of codebases, and it has not been stress-tested by many independent authors. The whole record →
The rest of it, in one place.
Ticked is on main today. An open circle is real code you cannot rely on yet — either still on a branch, or landed with nothing in the box that uses it — and says which.
Review
- 19 composable scopes, risk by default
- Two-tier specialist selection
- Per-specialty verification with bounded re-review
- Independent confidence consultant, no muting
- Dedup on file and symbol, not on reviewer
- Hunk-aware map-reduce for oversized diffs
- Repo linters and typecheckers folded in as leads
- Multi-provider runs, coalesced into one report
- Pull-request posting
Build
- Acceptance contracts, pinned before the work
- Conformance gate: met, unmet, or divergent
- Deterministic next-action recorder
- Carry-forward criterion semantics
- Diff-anchor verification of every citation
- One lane per increment, signal-ranked
- Session-owned commits, one per increment
- Learned diminishing-returns backstop
- Budget guard before dispatch
Fixing
- Fix all, fix recommended, or pick interactively
- Per-finding fix-or-defer disposition
- Synthesized fix contract, one criterion per finding
- Coder restricted to Read, Grep, Write, Edit
- Re-review as the gate, not the contract
- Three passes maximum, one commit each
- A re-deferred finding is never reported as fixed
Operating
- Live progress site, opened at run birth
- Stateless per-machine broker with replay
- Events published only after the durable write
- Pre-emptive quota pause and auto-resume
- Steppable runs for long sessions
- A field report written for every run
- Archive checkpointing with a failure report
- Keychain token injection for child processes
Teams
- Registry: add, remove, enable, disable, describe
- 9 bundled teams, plus an unbundled private set
- Claude Code plugin regenerated per registry change
- Team creation in eight gated phases
- An improve-team scoring and proposal loop
- Hashed eval fixtures
- Inter-team dispatch through the arbitrator
- Two-tier hardening against untrusted teams
Testing
- Nine zero-token Tier-1 probes
- Rubric judging with quoted evidence
- Campaign-wide defect mining over SQL aggregates
- Claude, Codex and local Qwen backends
- Capacity calibration and account rotation
- 7,360 unit tests
- Worker MCP grants, consented per team
- An external test runner, called as a builtin
- A bundled team that drives a browser
The awkward ones, first.
Isn’t running twenty-three specialists wildly expensive?
It would be if they all ran. They don’t. Selection has a deterministic floor — a specialist earns a dispatch by declaring file signals the diff actually matches — and only a small always-on set skips that check and receives the whole diff every time. That set is deliberately tiny, because it is where most of the token spend goes.
Above that, the pre-checks run your own linters first so workers stop paying tokens to re-report what a typechecker already knows, and Tier-1 test probes cost nothing at all because they read a database instead of asking a model.
Why should I trust an AI review any more than the last one?
You shouldn’t, on the strength of a claim. What is on offer is structure: the confidence number attached to a finding was not computed by the thing that found it, a verifier checked each specialist against its own declared criteria, and nothing was dropped to make the precision look better than it is.
And a record. The 95-finding self-review, the halted build run, and the gate that once flipped to ready on an unchanged target are all published. Judge it on the failures.
How locked in am I?
Teams are data — a spec, prompts, specialties and an eval fixture — and they live in ordinary files you can read, diff and edit. The engine is generic Python that names no team. Three backends are wired for the harness (Claude, Codex, and Qwen against a local Ollama), so the model is a run-time choice rather than an architectural one.
What actually stops a coder agent from wrecking my branch?
Four things, in order. It is dispatched with Read, Grep, Write and Edit and nothing else — no Bash, no Agent, so it cannot fan out or run commands. Every path:line it cites is checked against the increment it produced, and a second failure blocks the commit. The session commits, never the coder, one commit per increment. And a confirmed regression reverts to the best-scoring commit with a revert rather than a reset, so nothing leaves the history.
Is it finished?
No, and the site says where. Review, the build loop, the fix loop, the team model and the learning loop run on main today. The test harness is a working preview with an unfinished fixture corpus. Memory stores and recalls in production but does not yet inject itself into a session. Real browser and test-runner control landed, but the only team that uses it is not one of the nine you get in the box. Every one of those is marked as such, in the page and in the data behind it.
Can I see one run end to end?
Yes — every run opens a live progress site at birth, streaming from a per-machine broker that replays whatever you missed before it starts pushing. Events are published only after the durable write, so the stream is a latency optimization and the log stays the source of truth even if the broker is down.
All of it, one topic at a time.
The same hierarchical browser the platform uses for its own navigation, pointed at this. Every topic is a real URL you can share, and every one says how far along it actually is.
Overview
A team of AI specialists you install and run from your terminal. Each one reads your work for a single thing it knows well, they check each other, and you get back one ranked report — not one model’s general impression.
Shipped · 10 topics inside · 1 in preview
The Pipeline
A review is not one model reading a diff. It is a sequence of stages with different jobs and deliberately unequal authority — the actor that finds a problem is never the actor that decides what it is worth.
Shipped · 34 topics inside · all shipped
Teams
Every team is a self-contained bundle you install into the registry. Open one to see what it is for, what it can do today, and every specialist and lens inside it.
Shipped · 437 topics inside · 4 in preview · 1 in flight
Research
Four research programmes and a reference library sit behind the design decisions on this site. Each one below says what the question was, what was actually found, where the sources are — and whether it changed the product or honestly did not.
Shipped · 7 topics inside · all shipped