Repository navigation
History RFC 000 Foundation
Replaced by the Charter (Tier 0) on 2026-10-11. This page stays readable as history; the Charter is the current Tier 0 of the RFC series.
Authors: the project's founder, with Claude (Opus 5.5)
Revised and accepted 2026-10-08 by TeamCLI's board (founder's vote), reviewers unanimous after six rounds — four labs (GPT Sol 6, Kimi, Gemini, Grok), none the author's lab. This revision makes four foundational changes, each named in "What this revision changes in Part 1": (A) a team across labs (multi-vendor as the reason TeamCLI exists), (B) a project may be one repository or several, (C) TeamCLI is for software projects, (D) the forge is an adapter — any forge or none. The review record is kept with the project.
Revised and accepted 2026-10-07 by TeamCLI's board, both members each with their own vote; reviewers unanimous after five rounds. Supersedes the text accepted 2026-10-06 (kept as history).
First accepted on 2026-10-06, unanimously, by the TeamCLI board. Reason: after five rounds of review, every reviewer could stand behind the text: eight reviewers from seven labs, with no decision applied wrongly, no new problem and no point reopened in the last round. Decided by: the board's three chairs: the owner, the main coordinator (called the main orchestrator since 2026-10-06), and for this RFC a third chair held by an agent from another lab.
What TeamCLI stands on, in three parts: what we believe, what a team is and how it lives, and how we decide.
TeamCLI is young. Part 1 is what we believe and hold ourselves to; Part 2 describes a team as we are building it. Most of both is not built. The last section says, belief by belief where one can be checked and step by step, what the released version does. Everything else is a direction.
install teamcli and let's do this…
This is what we are building. Say it to an AI agent you already use. It looks at your project, finds the agents you have, and proposes a team. You say yes. The team gets to work.
A team across labs — why TeamCLI exists. No agent is best at everything. Where a lab offers its own multi-agent tool, it can build a team of that lab's agents; TeamCLI is for the team that spans labs — Claude, GPT, Grok, Gemini, DeepSeek and more, from different companies, working as one team under one set of rules — the cross-lab team that is TeamCLI's reason to exist. (A single lab's own tool builds a team of that lab's agents; assembling agents from different labs under one set of rules is what TeamCLI is for.) Why it matters: a review by a different lab is independent to the degree the labs genuinely differ, where one model's review of its own kind carries the same blind spots; when one lab's limit or outage hits, the rest can carry the work where they are available and able; and each role goes to the agent that fits it, from any lab. (A single-lab team still runs under TeamCLI — it is simply not what the tool is for.)
For software teams, on any git repository. TeamCLI is a team of AI agents for your code — your repositories (the code and its supporting repositories: docs, site, infrastructure), your commits, your reviews. The model that gives it value — version-controlled code, review and merges — is code-specific, and it runs on any git repository, local or hosted. The forge is an adapter: pull requests, issues, CI, wiki and projects are what a forge adds, and TeamCLI reaches them only through an adapter for that forge (GitHub and local workflows run today; the clean forge adapter is not yet built, and GitLab, Gitea, Bitbucket are not promised universal here). A repository on a forge with no adapter yet still works at the git baseline; its hosted features are reported unavailable until the adapter exists, and a task that needs one waits or escalates — never silently half-done. With no forge at all, the team works in plain git (branches and merges) and the hosted-only features are simply absent. Other kinds of project — pure research, writing, operations — are not what this tool is for; the concept may carry further one day, in another tool.
You set the limits. Agents act and decide inside them. What you gave, you can take back.
What a team may do is written down, where you can read it.
Yours to set. How a team works is a setting you can change, with a default that works if you never do. A few things hold whatever is set, and each RFC names its own.
Evidence before a claim. A claim comes from work whose result can be shown, not from memory. A review that did not look is not a review.
Security first. We tell you what protects you, and what doesn't.
One sentence to start. That is the aim. If getting started needs a manual, we have failed.
A team is a group of AI agents working on one project — one repository or several (a repository
is a git repository: the versioned source the team works in, local or hosted on any forge). A seat
works in the repositories its role is scoped to. A change touching more than one repository is
several coordinated changes, each checked and accepted on its own; a task may name several
repositories (RFC 008) and is complete when every one of its changes is accepted — there is no single
cross-repo accept. Anything forge-specific — how a review or an issue is opened, how CI is read —
lives behind a forge adapter, so the same team model runs on a local repository with no forge, or
on any forge TeamCLI has an adapter for; this forge adapter is distinct from RFC 008's tracker
adapter (the backlog), and a no-forge project uses the file tracker. Each agent holds a seat: a
role, and what it may do. An agent comes from a lab, the company that makes it. No lab is meant for a
role: which agent holds which seat is the team's own choice.
Every team has someone who decides for the project. At first that is its owner, the person who started the team. The owner can give an agent the right to decide some things in their place; what was given is written down, and can be taken back (RFC 001). Who decides is written down. When that changes, the change is written down too; today that still takes someone doing it.
An owner who wants to share that, with other people or with agents they trust, will be able to set up a board. Who sits on it, what it takes to pass a decision, who can refuse, and whether the board may change any of that: the owner sets it. TeamCLI will propose a rule to start from. It will be written down, where you can read it. How several voices become one decision is the subject of RFC 006.
The life of a team
- Proposed. A team begins as a written proposal. That an agent draws it up from one sentence is where we are heading.
- Agreed to. Nothing starts until the proposal has its yes.
- Staffed. The seats that were agreed are filled. When one stops, it is filled again, its work goes to another seat already allowed to do it, or the work waits until someone decides. We are building towards that; today a person starts a seat that stopped.
- At work. The team takes pieces of work; each has a life of its own, described below. Much of the time a seat is waiting: for a decision, for another seat, for a person.
- Changed. When the team needs more than was agreed (a seat that was not agreed, a seat allowed to do more, a higher limit), that is a new proposal, and it needs its own yes.
- Interrupted. A seat can stop without anyone deciding it: a limit is reached, or its work is cut off in the middle. We are building towards a TeamCLI that notices, says so, and hands the work on, together with what was written down. Today that still takes someone watching.
- Paused and resumed. A team can be stopped from taking new work, and started again. What was written down is kept, and so is what the team was given to remember (RFC 003). What lived only inside a seat is not.
- Renewed. A seat can be started afresh, or go on with what it holds, as the team is set up to do. What is sure to remain is what was written down.
- Ended. The team stops. What it wrote down stays with those it worked for.
The life of a piece of work
- Asked. Someone with the right to ask says what they want.
- Proposed. The team answers with a plan: who will do it, and what it expects it to take, as far as it can tell.
- Agreed. A yes, from whoever holds the right to give it: the owner, an agent the owner gave that right, a board, or a rule already set.
- Carried out. Within what was agreed.
- Checked. In the way the team is set up to check: by another agent, by running it, by a person. A team may be set up to check less; never nothing where RFC 005 says a check always comes first. The report says what was checked and what was not, and a piece of work counts as done only when the check it requires has happened.
- Reported. The result comes back to the one who asked, with what was done and how it was checked.
- Answered. Whoever holds the right to accept it, often the one who asked, accepts it, sends it back, or drops it. Sent back, it is carried out again or proposed again. That is ordinary, not a failure.
Work can stop at any step, blocked or waiting for a decision. When it does, the one who asked should be told; that, too, is something we are building towards.
At every step, who may act and what protects you is the subject of the RFCs that follow.
Why should this exist, and what should it be for the people who use it? That is a public RFC, like this one: a numbered public proposal, open to comments. It states commitments, who decides, what belongs to whom, and what it does and does not cover. It is written in plain language, for anyone deciding whether TeamCLI is for them.
How is it built? That is an internal design record. It holds the mechanics, and it must serve a public RFC: no design record may give TeamCLI a purpose that no public RFC has argued for.
A reader should be able to understand what TeamCLI is, and hold us to it, from the public RFCs alone.
- The question, in one sentence.
- What we propose, as commitments to the person using TeamCLI: what we bind ourselves to build and to keep.
- Why, including what we tried or saw that led here.
- What it costs and what it does not cover. A commitment with a hidden limit is not one.
- What would change our mind.
- What is true today. For each commitment, what the released version does. A text says "we are building towards" for everything else.
TeamCLI, the project, has chosen to have a board. It decides for TeamCLI only: a team that uses TeamCLI answers to its own owner or its own board, never to ours.
Like any board, ours sets how it decides, and writes it down; its rule is kept beside these RFCs. Its members hold great power over what TeamCLI commits to, so we must know who each of them is, by more than a password. How is the subject of RFC 001.
- Anyone may open a discussion proposing an RFC. It becomes a numbered RFC when the board takes it up, and it is discussed in the open.
- The board accepts, changes or declines it. Once it has, the decision is written at the top with its date, its reason and who decided.
- An accepted RFC is a commitment. Changing it takes a new RFC; the old one stays, marked as replaced.
How we review and accept an RFC today. Reviewers first, then the board. At least three reviewers from three different labs, none of them the lab that wrote the text, read it in rounds; with fewer, a round does not count. In a round the text does not change; each reviewer reads it alone and says what they find; the board decides each point and writes down why. The next round starts from those decisions: a point that was decided is reopened only if the new text contradicts itself or an earlier decision. Rounds go on until every reviewer stands behind the text; when the same point comes back three times, the board decides it and the disagreement stays on record. A reviewer that does not answer is never counted as agreeing: it is asked again, then replaced. When the reviewers are unanimous the board votes, and an RFC is accepted when its members all agree, each with their own vote: a vote is not lent to whoever drafted the text. Our board has two members, the project's founder and an AI agent. All of this is our board's current setting, not a rule for anyone else's; RFC 006 says what holds for any team that decides with more than one voice.
It is a living text, dated, kept with its history; every earlier version stays readable. Part 2 and Part 3 change by an RFC like any other. Part 1, what we believe, changes by the same rule, and only by a text that says which belief it changes and why.
The 2026-10-07 revision changed two beliefs, each named by this text's own rule.
- "Agents propose. You decide. Your decisions are the team's limits." becomes "You set the limits. Agents act and decide inside them. What you gave, you can take back." Why: the first form made a person the one who decides everything, each time. What we are building is a team that works without its owner standing behind it: an agent may decide, agree or create where its owner gave it that right, and nowhere else (RFC 001). The limits stay the person's; the deciding inside them need not be.
- "Yours to set." is added. Why: every text since this one was first accepted found the same thing, that a policy we were about to fix was a default a person should be able to change. It was a habit of ours; it is now a belief, with its own limit: what holds whatever is set, each RFC says for itself.
The 2026-10-08 revision names four more foundational changes (A–D).
- (A) "Specialists, working as one team." becomes "A team across labs — why TeamCLI exists." Why: multi-vendor is not one advantage among several; it is the reason the tool exists. A single lab's own tool builds a team of that lab's agents, so assembling agents across labs under one set of rules is what TeamCLI is for. The old aside "whether they come from one lab or several" treated the point as incidental; it is central.
- (C) "For software teams, on any git repository." is added. Why: the value model — commits, review, merges — is code-specific, so the scope, and what is out of it (pure research, writing, operations), is stated rather than implied.
- (D) the forge is an adapter. Why: TeamCLI must not be tied to GitHub. Git is the floor and needs no host; GitHub, GitLab, Gitea, Bitbucket are forges reached through an adapter, and a local repository with no forge is first-class. Hosted features — pull requests, issues, CI, wiki, projects — are what a forge adds, reached only where an adapter exists.
- (B) is a Part 2 change (a project is one repository or several), named here because it is foundational: a cross-repo change is coordinated changes accepted per repository, never one atomic cross-repo accept.
- RFC 001: Security. What TeamCLI commits to and what it does not protect you from, when agents operate the tool.
- RFC 002: Communication. How a thing said reaches the one it is for.
- RFC 003: Memory. What a team knows tomorrow that it learned today, and who decided so.
- RFC 004: Analysis. Looking at a project, a team and its work, and saying what was found.
- RFC 005: Quality. What makes work done, who says so, and what a check is worth.
- RFC 006: Consensus. How several voices become one decision that can be relied on.
- RFC 007: Harness. Starting a team and keeping it running. It completes the first six, which it needs.
- RFC 008: Planning. A team reads its own backlog, pulls its work, and plans order and timing; priority, assignment and acceptance stay human, and the tracker is an adapter.
- RFC 009: Roles & Skills. A team is staffed from reusable role and skill libraries, bound per project, context and task; a role carries no skill dependency and a skill grants no authority.
Who may decide in your place, and how that trust is given, seen and taken back, is in RFC 001 for now; whether it becomes an RFC of its own is open.
"Today" is TeamCLI 0.3.1. Each row restates what the tables of RFC 001 to RFC 007 say, which were each checked against the released code; this table adds no claim of its own.
| Belief or step | Today |
|---|---|
| What a team may do is written down, where you can read it | In part, in RFC 001's words: each agreement is a signed record of the exact text; an agent outside a team may be given four commands and no others. Lists for a team's own agents and the right to agree or to grant are designed, not built; who agreed and when is not built |
| A team, proposed | No. One command writes a starting file, the same for every project. An agent drawing it up from a sentence is not built |
| Agreed to | In part, against a mistake: nothing starts through TeamCLI without a person agreeing to the team's file on this machine, recorded. It does not hold against an attempt, nor against an agent started on the side (RFC 001, RFC 007) |
| Staffed | In part. A command starts the agreed seats. A seat that stops is not filled again by the tool; a person starts it (an agent given that command can start only a declared seat that is not marked stopped and not running) |
| At work | In part. TeamCLI shows who is working, idle or stuck, and a watch tells a team's own agents when results wait (RFC 007). It holds no piece of work and does not know who waits on whom |
| Changed | In part, against a mistake: a change to what is in the file needs a new agreement; an agent that reads the key agreements are signed with could undo that (RFC 001) |
| Interrupted | In part. A watch tells a team's own agents that something waits or that a seat is stuck; handing the work on is done by hand |
| Paused and resumed | In part. Commands stop and start a team; in this version both can fail and leave something for a person to do |
| Renewed | No. Starting a seat afresh is done by hand, with a note someone writes |
| Ended | In part. A command stops a team; in this version it can fail and leave something for a person to do. What the team wrote stays in the files its agents left; handing it on is done by hand (RFC 007) |
| A piece of work, at every step | No. TeamCLI holds no item of work: a piece of work is known by the files and messages agents leave. Nothing in it is proposed, agreed, checked, reported or answered by the tool. One command checks that commits, and the request to merge them, carry a seat's signature and no forbidden pattern; it is not a check of a piece of work, and it records nothing (RFC 005) |
| Who decides, and a board | One person, the owner, per team. A pane outside the team that the owner names may run four commands (start and stop the team, start and remove an agent) and no others; it cannot agree to anything. A board is not built |
No belief and no step holds wholly today. Eight rows hold in part. Three do not: a team is not drawn up from a sentence, a seat is not renewed by the tool, and the life of a piece of work is not built at all. The last row is not a step and is not counted. The RFCs that follow each say when that changes.