History RFC 000 Charter

RFC 000: The Charter (Tier 0)

Accepted 2026-10-11 by the project board, after unanimous review by three independent labs (none the author's lab). It supersedes RFC 000: Foundation (accepted 2026-10-08), which stays readable, marked as replaced.

Authors of RFC 000: the project's founder, with Claude (Opus 5.5). Re-laid from RFC 000 as the Tier 0 Charter of TeamCLI's RFC re-architecture.

What TeamCLI stands on, in three parts: what we believe, what a team is and how it lives, and how we decide.

This is the Charter, the first of four tiers (see "The series"). It ships no code; every other tier conforms to it. It holds beliefs and concepts. What the tool enforces — who may act, what an agent may do, what is refused — is not written here but in the Kernel, and the mechanics of a team's seats and of a piece of work are in the Runtime. Where this text names such a rule, it points to where the rule lives.

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.

Part 1. What we believe

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.

Part 2. What a team is and how it lives

This part holds concepts only. Where a step needs a rule the tool enforces, it points to the Kernel by section; where it needs the mechanics of a seat or a piece of work, it points to the Runtime.

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 may touch more than one repository; then it is coordinated changes, each checked and accepted on its own. How each change is checked and accepted — and that there is no single cross-repo accept — is the Kernel's (§3, §6, §15); whether the whole task is complete, which it is only when every one of its changes is accepted, is the Runtime's work-item lifecycle (a deliberate forward reference: the Runtime, Tier 2, is not yet written). 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 — what it may do is its capabilities, and nothing else (Kernel §3, §4). 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. An agent may act and decide only within the capabilities and leases the owner set (Kernel §3, §7); who may do each operation is set out in one table (Kernel §9). agree, grant, create and leads are never leased or copied to an agent (Kernel §3, §10). No agent holds grant unless the owner writes it, and a holder is a second owner, bounded by Kernel §8. Something an agent creates or approves is that agent's act, and never counts as an act of the owner (Kernel §10, §11). How a right is given, and taken back, is the Kernel's (§7 leases, §10 grant and agreement). Who decides is written down. When that changes, the change is written down too.

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 (Consensus).

The life of a team

How a seat is started, stopped, filled again or handed on is the Runtime's; who may start, stop, add or remove a seat is the Kernel's (§9). What each step does today is in "What is true today".

1. Proposed. A team begins as a written proposal. That an agent draws it up from one sentence is where we are heading.
2. Agreed to. The proposal gets its yes. Who may give it, and what the tool refuses until it is given, is the Kernel's (§9, §10).
3. Staffed. The seats that were agreed are filled. When one stops, it is filled again, its work goes to another seat, or the work waits until someone decides. Which seat may take the work is the Kernel's (§9); how it is handed on is the Runtime's. We are building towards that.
4. 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.
5. 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. Who may agree to it, and which changes are the owner's alone, is the Kernel's (§8, §10).
6. 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 (the Runtime).
7. 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, Memory). What lived only inside a seat is not.
8. 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.
9. Ended. The team stops. What it wrote down stays with those it worked for.

The life of a piece of work

The life of a piece of work has one home, the Runtime; its steps are below as concepts. Who may ask, agree or accept is the Kernel's.

1. Asked. Someone says what they want. Whose word a seat takes as an instruction is the Kernel's (§11).
2. Proposed. The team answers with a plan: who will do it, and what it expects it to take, as far as it can tell.
3. Agreed. A yes. Who may give it is the Kernel's (§9, §10); how a board's several voices become one yes is RFC 006 (Consensus).
4. Carried out. Within what was agreed, and within the seat's capabilities and leases (Kernel §3, §7).
5. Checked. In the way the team is set up to check: by another agent, by running it, by a person. The report says what was checked and what was not. Which checks are required, and when work counts as done, is the Kernel's (§3, §5, §15) and RFC 005's (Quality).
6. Reported. The result comes back to the one who asked, with what was done and how it was checked.
7. Answered. It is accepted, sent back, or dropped, by whoever may accept it (often the one who asked; who may is the Kernel's). 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 Kernel's; how the step is carried is the Runtime's; the seven modules add what each is for.

Part 3. How we decide

Two kinds of question

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.

What a public RFC contains

At least these six parts. They are a minimum: a longer document may add sections of its own — for example the limits of what it can enforce, what it costs, its modular boundary (what it deliberately leaves to other documents), where it sits among the tiers, and its review record — as the Kernel's seventeen sections do.

1. The question, in one sentence.
2. What we propose, as commitments to the person using TeamCLI: what we bind ourselves to build and to keep.
3. Why, including what we tried or saw that led here.
4. What it costs and what it does not cover. A commitment with a hidden limit is not one.
5. What would change our mind.
6. What is true today. For each commitment, what the released version does. A text says "we are building towards" for everything else.

Who decides, and how

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 the Kernel (§11: a key on the holder's own device).

• 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, the main orchestrator. (For RFC 000's first acceptance, on 2026-10-06, a third chair held by an agent from another lab sat for that RFC only; that is history, not the standing board.) 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.

This Charter changes too

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.

This re-lay changes no belief in Part 1. It moves rules out of Part 2 into the Kernel and the Runtime, and changes Part 3 where listed at the end.

What the revisions change in Part 1, 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.

  Note (2026-10-10): the Kernel narrows this. The text above is kept as it was accepted. Read now, "inside them" means: an agent acts and decides only within the capabilities and leases its owner set (Kernel §3, §7). agree, grant, create and leads are never leased or copied to an agent (Kernel §3, §10). No agent holds grant unless the owner writes it, and a holder is a second owner, bounded by Kernel §8. Some limits are the owner's alone, and no agent may change them (Kernel §8). And something an agent creates or approves is recorded as that agent's act; it never counts as an act of the owner (Kernel §10, §11). RFC 001, cited above, is absorbed by the Kernel.

• "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, each accepted per repository, never one atomic cross-repo accept (the Kernel's, §3, §6, §15); the whole task is complete only when every one of those changes is accepted (the Runtime's work-item lifecycle, pending).

The series

The series is laid in four tiers. Each tier rests only on the tiers below it; each of the seven modules rests on the Kernel and the Runtime, never on another module. Ten documents in all.

• Tier 0 — the Charter. This text, re-laid from RFC 000. What we believe, what a team is and how it lives, and how we decide. It ships no code; every tier conforms to it.
• Tier 1 — the Kernel: Authority, Capabilities & Trust (accepted 2026-10-09). The one fixed, enforced layer: everything the tool refuses, and why each refusal means something. Read it alone and you have read all of TeamCLI's power. It absorbs RFC 001 (Security) and the enforced half of Roles & Skills. RFC 010 (Delegation), which was proposed and never accepted, is retired into it.
• Tier 2 — the Runtime: Harness, Work Items & Records. Starting a team and keeping it running (RFC 007, Harness); the life of a piece of work, in one home; and the record store and delivery that every module uses. It keeps the Kernel's ledger and sets no authority of its own.
• Tier 3 — seven modules. Each enforces nothing new:
  • 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 008: Planning, narrowed. A team reads its own backlog, pulls its work, and plans order and timing; the tracker is an adapter. Priority, assignment and acceptance stay human, as RFC 008 was accepted; who may do each is now the Kernel's, and the life of a piece of work the Runtime's.
  • RFC 009: Roles & Skills, in two halves. Roles, configurable: a team is staffed from reusable role libraries, bound per project, context and task. Skills, advisory: a skill grants no authority, and a role carries no skill dependency. What a role is allowed to do is enforced in the Kernel.

Who may decide in your place, and how that trust is given, seen and taken back, is settled: it is in the Kernel. Delegation is a bounded, recorded lease (Kernel §7), and it is not an RFC of its own.

What is true today

What the released version (TeamCLI 0.3.5) does, belief by belief and step by step. Each row carries what RFC 000's table said, each checked against the version it named; where the Kernel's own table (§14) covers the same ground, the row follows it. Anything not yet re-checked against 0.3.5 is marked to re-check against 0.3.5. This table adds no claim of its own.

Tier	Belief or step	Today
Charter	This text	No code. The Charter ships none; this row is a pointer, not a claim about the release
Kernel	What a team may do is written down, where you can read it	In part (§14): each agreement is a signed record of the exact text; an agent outside a team may be given four commands — start, stop, add, remove — and no others. Since 0.3.4 a delegate named in the team file may approve ordinary roster changes, and is refused everything else. 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. Nothing of the capability model is built
Kernel	Agreed to	In part, against a mistake: nothing starts through TeamCLI without a person agreeing to the team's file on this machine, recorded (§14: the first agreement needs a person at the machine). It does not hold against an attempt — no row of the Kernel's table does — nor against an agent started on the side (to re-check against 0.3.5)
Kernel	Changed	In part, against a mistake: a change to what is in the file needs a new agreement; since 0.3.4 an ordinary roster change may instead be approved by the delegate, re-checked against the live file and the approved copy (§14). The key agreements are signed with is readable by an agent, which could undo that
Kernel	Who decides, and a board	One person, the owner, per team. A delegate outside the team that the owner names may run four commands (start and stop the team, start and remove an agent) and no others. RFC 000 said it cannot agree to anything; since 0.3.4 a delegate named in the team file may approve ordinary roster changes (§14) — whether that is the same delegate is to re-check against 0.3.5. leads and the Kernel's table of who may do what are not built. A board is not built
Runtime	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 (to re-check against 0.3.5)
Runtime	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) (to re-check against 0.3.5)
Runtime	At work	In part. TeamCLI shows who is working, idle or stuck, and a watch tells a team's own agents when results wait. It holds no piece of work and does not know who waits on whom (to re-check against 0.3.5)
Runtime	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 (to re-check against 0.3.5)
Runtime	Paused and resumed	In part. Commands stop and start a team; both can fail and leave something for a person to do. The stop is one command per team, and unreliable (§14); the start is to re-check against 0.3.5
Runtime	Renewed	No. Starting a seat afresh is done by hand, with a note someone writes (to re-check against 0.3.5)
Runtime	Ended	In part. A command stops a team; it is one command per team, and unreliable (§14). What the team wrote stays in the files its agents left; handing it on is done by hand (to re-check against 0.3.5)
Runtime, with Quality (005)	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 (to re-check against 0.3.5). The Kernel's record ledger is not built (§14)
Communication (002)	How a thing said reaches the one it is for	No code in this table. The module's own text says what is true today
Memory (003)	What a team knows tomorrow that it learned today	No code in this table. The module's own text says what is true today
Analysis (004)	Looking at a project, a team and its work	No code in this table. The module's own text says what is true today
Quality (005)	What makes work done, and what a check is worth	No code in this table. The module's own text says what is true today
Consensus (006)	How several voices become one decision	No code in this table. The module's own text says what is true today
Planning (008)	A team reads its backlog and plans order	No code in this table. The module's own text says what is true today
Roles & Skills (009)	Roles, configurable; skills, advisory	No code in this table. The module's own text says what is true today

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 row on who decides is not a step and is not counted. These counts are RFC 000's; the rows marked to re-check may change them. The Charter row and the seven module rows are pointers. They are not in those counts, and they claim no release status. The RFCs that follow each say when that changes.

What changed from RFC 000

The Charter re-lays RFC 000 as Tier 0 of the four-tier RFC series. Part 1 (what we believe) is unchanged. Part 2 is made concepts only: the rules the tool enforces move to the Kernel and the mechanics of a team and of a piece of work move to the Runtime, each cited where it now lives. Part 3 clarifies the standing board (the founder and the main orchestrator), makes the six-part public-RFC template a minimum, and records that this Charter changes by an RFC like any other. The "what is true today" table is kept, now grouped by tier. RFC 000 (Foundation) stays readable, marked as replaced.