Notebook entry · 7 November 2026
The team that already existed
The research started with a broad idea, a small fixed team of agents, and ended with a much narrower question about where configuration and records belong.
These are sanitized notes, not a market survey. Third-party figures collected at the time, such as popularity counts and cost or speed anecdotes, are left out because they were not independently verified.
01 · Starting pointOne person, one project, one team
Working with a coding assistant is one person, one project, one agent. The first idea was a skill that turned that into a small team inside the same harness. After a first pass it narrowed to a fixed trio coordinated by the lead session:
| Role | Intended job | Not allowed |
|---|---|---|
| Architect | Short spec and acceptance criteria; split work; arbitrate | Editing code |
| Builder | Implement code and tests against the spec | Editing the spec; self-approval |
| Reviewer | Read spec and diff; run checks; report findings | Editing source |
Three rules seemed essential for review to catch anything: the reviewer never inherits the builder’s conversation; the reviewer uses a different model or prompt frame where possible; and the fix loop has a cap. Names and titles would be handles only; role prompts would carry scope, tool rights, file ownership and done criteria rather than personality.
02 · Prior workIt had been built, in several forms
Native features already offered most of the mechanics. Claude Code has subagents and an experimental agent-teams mode. Codex has subagents with custom agent definitions and parent-to-child coordination.
Open projects covered the rest: skill frameworks, persona collections, orchestrators and review plugins with implementer/reviewer loops, fresh-context reviewers, capped fix loops and per-role model selection. For example, superpowers includes a subagent-driven development workflow, and codex-plugin-cc provides cross-model review commands inside Claude Code. Feature details came partly from page summaries and may have changed; check current documentation.
03 · Practitioner reportsRecurring themes, held as hypotheses
- Orchestration can cost substantially more tokens, often from re-reading history.
- Context is lost or distorted at handoffs; a reviewer that inherits the builder’s misunderstanding tends to confirm it.
- For small tasks, one agent is usually cheaper and faster than a team.
- Clear file ownership and explicit handoff points work better than free-form messaging.
- Some argue for cross-vendor review because models have different blind spots. Not tested here.
04 · The turnThe real problem was smaller and more personal
Building another general team framework would add little to this experiment. Attention shifted to a narrower problem already visible in daily work:
- Configuration in the wrong place. Personal model choices, reasoning levels and review habits had been copied into several projects’ instructions, where they repeated, drifted and mixed with genuine project rules.
- Records leaking into project knowledge. Dispatch receipts, model assignments and review transcripts drifted toward project documentation.
- Evidence easy to overstate. “Requested high effort” slid into “ran at high effort”, and “fresh session” into “isolated”.
So the goal changed from a fixed team to a configurable personal profile, one writer per artifact, independent reviewers on demand, and private records kept apart from durable project context. No compulsory architect: the lead keeps scope and integration.
05 · DesignDecisions that came out of it
- The profile is small JSON outside projects, read as data and validated structurally. No credentials.
- The skill ships no personal defaults; example profiles are templates.
- Requested, interface-accepted and runtime-observed settings are recorded separately; unknown stays unknown.
- Deadlines are either supervised by a real mechanism or labeled advisory.
- Profile preferences only fill choices the instruction hierarchy leaves open, and never authorize production or publication.
- A runner would be justified only for repeated mechanics such as snapshot hashing, deadline enforcement or receipts. Version 1 has none.
06 · ScopeWhat this does not claim
It does not claim Agents Collab is the first, only or best approach to model collaboration. Neighbouring projects solve overlapping problems, often more completely. The contribution here is narrow: a configuration and records boundary, plus an honest account of trying it.