RFC 000: Foundation

[floor]

Authors: the project's founder, with Claude (Opus 5.5)

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, AI agents from seven labs, with no objection left in the last round.
Decided by: the board's three chairs: the project's founder and two AI agents from different
labs.

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. Where this text says what we are building towards, and not what is true
today, it says so.

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.

Specialists, working as one team. No agent is best at everything. Each role is proposed for
the agent that fits it, from the agents, the time and the budget you have, whether they come
from one lab or several.

Agents propose. You decide. Your decisions are the team's limits.

What a team may do is written down, where you can read it.

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

A team is a group of AI agents working on one project. Each agent holds a seat: a role, and
what it may do. An agent comes from a lab, the company that makes it.

Every team has someone who decides for the project. At first that is its owner, the person who
started the team. 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.

The life of a team

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. Nothing starts until the proposal has its yes.
3. 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.
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, and it needs its own yes.
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. Today that still takes someone watching.
7. Paused and resumed. A team can be stopped from taking new work, and started again. What
   was written down is kept. 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

1. Asked. Someone with the right to ask says what they want.
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: from the owner, from a board, or from a rule already set.
4. Done. Within what was agreed.
5. 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 nothing; then the report must say so.
6. Reported. The result comes back to the one who asked, with what was done and how it was
   checked.
7. Answered. The one who asked accepts it, sends it back, or drops it. Sent back, it is done
   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.

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 a promise, who
decides, what belongs to whom, and what is and is not guaranteed. 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

1. The question, in one sentence.
2. What we propose, as a promise to the person using TeamCLI.
3. Why, including what we tried or saw that led here.
4. What it costs and what it does not guarantee. A promise with a hidden limit is not one.
5. What would change our mind.

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 promises, 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. In rounds, as many as it takes. 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. An
RFC is accepted when
the board is unanimous. Our board has three members. All of this is our board's current
setting, not a rule for anyone else's.

This foundation 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.

What comes next

• RFC 001: security. What TeamCLI guarantees and what it does not.
• RFC 002: communication. Who may talk to whom, and how a team reaches a person.
• RFC 003: delegation. Who may decide in your place, and how that trust is given, seen and
  taken back.