History RFC 004 Analysis

RFC 004: Analysis

Looking at a project, a team and its work, and saying what was found.

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

Accepted 2026-10-07 by TeamCLI's board. Three reviewers from three labs (Grok, GPT, Gemini) stood behind this text unanimously, and both members of the board voted for it: the founder, and an AI agent. The founder first lent his vote to the other member, which had drafted the text; the reviewers of RFC 006 then said a vote should not be lent to whoever wrote the thing decided, and the founder gave his own vote the same day. It is not yet published.

Renumbered 2026-10-07. At the founder's request the series now runs 001 Security, 002 Communication, 003 Memory, 004 Analysis, 005 Quality, 006 Consensus, 007 Harness. Only numbers changed from the draft the reviewers stood behind; no commitment changed.

Draft 4, 2026-10-07, after round 2. Three reviewers from three labs read draft 3 and all three stood behind it. This draft differs from draft 3 in two places: question 1 of section 6 now says what commitment 9 already answers (a reviewer's suggestion), and commitment 9 says "for one project" where it said only "yours to set" (the founder's request). It is the text put to the board's vote. Built from his direction of 2026-10-06: "the size and the kind of team depend on this", and "it should be able to analyse everything, projects, team performance".

1. The question

A team is sized, shaped, changed and judged by someone. On what? What does TeamCLI look at, what does it say it found, and how far can you rely on it when you decide?

Where we start from

Today a team is shaped by guess. Someone decides that a project needs a lead, two agents that build and one that reviews, because the last project had that. Nothing looked at the project.

And judged by impression. Whether a team worked well, which agent did which kind of work well, whether a lab was worth what it cost: we answered all three, for our own teams, from memory and from what the agents said about themselves.

The facts existed. How long finished work waited, how often a review sent work back, which agent was stopped by its lab's limit and when: each was in a file or on a screen at some moment. Nothing kept them, and nothing put them side by side.

2. What we propose

Nine commitments to the person whose team it is. A commitment is what we bind ourselves to build and to keep. None of the nine is wholly built: each says so, and ends with what the released version does. Section 7 gives the same row by row.

Analysis is one thing done to many subjects. We are building towards a TeamCLI that looks, and says what it found. It does not decide: what is done with a finding belongs to whoever holds the right to do it (RFC 001). Two things are kept apart throughout: the facts, each with its source and its time, and what is concluded from them. A finding rests on facts it can point at; a fact carries no opinion.

What is analysed

1. A project, before a team is proposed for it. We are building towards this: what the project is, how large, how it is tested and released, what work is open, and what in it can be done by several agents at once and what cannot. From that, with the agents you have and what each has left, a proposed team: how many, of which kinds, led or not, and the reason for each. It is a proposal to whoever may create a team (RFC 007), never a team. Today: one command writes the same starting file whatever the project is.

2. A team's work, while it runs and after. We are building towards this: what was asked and what was delivered, how long each thing took and how long it waited and on whom, how often work came back from a check, where the team stood still, and what it cost. Today: you can see who is working, idle or stuck at this moment; TeamCLI keeps a log of its own commands and the latest reading of what each lab has left, no times of work or of waiting, and it compares nothing.

3. Each agent, and each lab, on your work. We are building towards this: which agent did which kind of work well on your projects, how often each was stopped by a limit, what each cost for what it delivered. On your work, not on a public test: the answer for your project may differ from the answer for anyone else's. A comparison says what each was given to do; where the work was not alike it says "not comparable" and gives no ranking. Today: for some labs TeamCLI reads what is left of what you pay for; it knows nothing of how well an agent worked.

4. A team's shape, against its work. We are building towards this: an agent that waits most of the day, a kind of work nobody on the team takes, one agent everything waits on, a team larger than its work. Each is said with what was observed, and with what a different shape would be expected to change. Today: a team's watch says when an agent, or the whole team, has been idle for a while; nothing relates that to the team's shape.

5. The plan, against what happened. We are building towards this: each estimate beside the real time (RFC 007), which kinds of work are always late, and by how much. Today: nothing is estimated, so nothing is compared.

What holds for every analysis

6. Every finding carries its source. We are building towards this: a finding names what was observed, when, and by what; where nothing was observed it says "not known", and an estimate says it is one and what it rests on. A finding you cannot trace is an opinion, and TeamCLI does not present one as the other. A finding that is wrong can be corrected by you, and it keeps the trace of having been corrected. Today: what TeamCLI reports is what it has just read from a screen, a file or the machine, and it says "not known" for an agent it cannot read.

7. A team is measured from what TeamCLI saw, not from what agents say of themselves. We are building towards this. An agent that is judged by its own reports learns to write reports. What an agent says about its work, and what a lab says about its own agents, is one source, named as such, never the measure. Today: nothing is measured; a team's progress is what its agents write.

8. An analysis says, and does not decide. We are building towards this. A finding goes to whoever may act on it. Proposing a team is not creating one; saying that an agent waits all day is not removing it; saying that a team keeps making one mistake is not writing it into memory (RFC 003). And what an analysis reads does not command it (RFC 001): a file in a project that says how many agents it needs, or with what rights, is something found, not something to follow. A finding starts nothing by itself unless you set it to; even then what it starts is a proposal, and a proposal is acted on only by someone who holds the right to that act. Today: TeamCLI's checks report and print the command a person can run; they change nothing by themselves.

9. You choose who does the looking, and what is kept. We are building towards this. To analyse a project is to read it, and to analyse a team is to read its work: the widest reading there is. So no analysis runs until someone who holds the right has named who looks and what it may read. Analysing is a right of its own (RFC 001): by default yours; an agent's only where you gave it by name, saying which labs may read which projects. Being asked to set up a team, being allowed to create one, a finding, or anything a project says, never gives it. That holds first of all for a project no team was ever agreed for: nothing reads it until you, or an agent you gave that right beforehand, have said who. A lab you allowed only on public material analyses only that. Where an analysis comes from is yours to set as well, for everything you do or for one project: TeamCLI's own, a tool you already trust, the figures your tracker or a lab gives; and a finding says which produced it. What an analysis keeps is facts and findings, on your machine, that you can read and remove; removing them stops TeamCLI using them, and does not take them out of what a lab already read. Today: none of this exists to be set.

As these are built, all of it is to be yours to set, for everything you do, for one team or for one agent: what is analysed and how often, who is told, what is kept and for how long, and whether a finding may start a proposal without waiting to be asked (by default it may not). Today none of these settings exists.

3. Why

• A team shaped by habit. Our own teams were given the shape of the first one. One project ended with a lead that did its operator's work while the operator waited; another with three agents reading the same change in turn. Nobody had looked at either project before deciding who would work on it.
• Three reviews that found nothing, and one run that did. A fault in stopping an agent was read five times by one lab's agent and passed. A second lab found it on its first read. The same night a real run found two more that every review and every test had passed. Which check finds what, on our own work, is a fact we had and never wrote down.
• A day of waiting nobody measured. Finished work waited fifty minutes, then two hours, for one agent that was in a conversation. We know because a person noticed. Nothing had counted it.
• Which lab for which work. We moved work from one lab's agents to another's several times in two days, each time on an impression. Some were right. We cannot say which.
• The founder's question. At the end of a day he asked what was left of each lab's allowance. The answer took an agent ten minutes and was partly a guess.

4. What it costs, and what it does not cover

These are the costs of what we are building, not of anything released.

• An analysis can be wrong, and will be believed. A proposal with reasons and numbers looks more certain than a guess, and may be no better. The first analysis of a project rests on little; it will say so, and the default when little is known is a small team that grows.
• Measuring changes what is measured. Agents told they are compared on how fast work is delivered will deliver fast. Counting how often work comes back from a check invites the one who checks to let it pass. Counting what was delivered invites an agent to take the easy work and leave the hard. Comparing labs on work that was not alike produces a ranking that means nothing and will be believed. What TeamCLI counts, a team will tend to produce. The text commits to measuring from what it saw; it cannot commit that what it saw is what mattered.
• Looking costs. Reading a whole project, or a team's whole day, uses what you pay a lab for, sometimes more than the work it is meant to size. An analysis says what it cost, and a small one comes first.
• It reads everything. An analysis of a project sends that project to a lab, like any agent reading it. An analysis of a team reads what every agent did. It is the largest reader in a team and is subject to every limit RFC 001 sets, with no exception.
• A project can try to steer its own analysis, and so can an agent that knows it is being measured. The first is material and is treated as such. The second is why commitment 7 exists, and it holds against a mistake more surely than against an attempt.
• More is kept, and not only by you. Findings about your projects and about how each agent worked are files on your machine: one more thing that exists and can be read (RFC 001). And the lab whose agent did the looking has read what it looked at; removing a finding does not reach there.
• Numbers about agents are not numbers about people, and TeamCLI does not measure the people who work with a team.
• It does not replace looking. A finding tells you where to look. It does not tell you that the work is good.

5. What would change our mind

• Teams proposed from an analysis that work no better than teams shaped by habit. Then the first commitment is ceremony, and a few good starting shapes are worth more.
• Findings nobody reads. Then the analysis must become three lines at the moment a decision is taken, or go.
• Teams that get worse at the work while getting better at what is counted. Then commitment 2 is doing harm, and less should be measured.
• Labs or trackers that already give these facts. Then TeamCLI should read theirs and keep only what it adds: the same facts for every lab, side by side.

6. Open, for reviewers

1. Who analyses a project before any team exists? Commitment 9 answers: none until you, or an agent you gave that right beforehand, have said who. What is left open is how you are asked, the first time, in a way that is neither a formality nor a wall.
2. What is "well"? Commitment 3 says which agent did which work well. Delivered and accepted; not sent back; not found faulty later? Who says?
3. How much must TeamCLI record to keep commitment 7, and is that record itself too much to keep (commitment 9)?
4. A finding that starts a proposal by itself. Useful, or the first step of a team that reshapes itself?
5. Comparing labs. Is "on your work" enough to make the comparison fair, when the work each was given was not the same?
6. A team of one, or with nobody leading. Who receives a finding about the team?
7. Is this one RFC? Analysing a project and analysing a team's performance share a method. Do they share enough to be read as one text?

7. What is true today

"Today" is TeamCLI 0.3.1. Each row restates what one agent checked against the released code on 2026-10-07, clause by clause; every row held, and row 2 was made more exact.

#	Commitment	Today
1	A project, before a team is proposed	No. One command writes the same starting file whatever the project is
2	A team's work, while it runs and after	No. Who is working, idle or stuck at this moment is shown. A log of TeamCLI's own commands and the latest reading of what each lab has left are kept; no times of work or of waiting; nothing is compared
3	Each agent and each lab, on your work	No. For some labs, what is left of what you pay for is read; nothing about how well an agent worked
4	A team's shape against its work	No. A watch says when an agent or the whole team has been idle for a while; nothing relates it to the team's shape
5	The plan against what happened	No. Nothing is estimated
6	Every finding carries its source	In part. What is reported is what was just read from a screen, a file or the machine, and an agent that cannot be read is reported as not known
7	Measured from what TeamCLI saw	No. Nothing is measured
8	Says, and does not decide	In part. The checks that exist report and print a command for a person to run; they change nothing by themselves
9	You choose who looks and what is kept	No

Two of nine are partly true, and both are habits of the tool, not an analysis: it reports what it reads and leaves the decision to someone. Nothing that analyses is built.

What this RFC leaves to others

Who may create or change a team on the strength of a finding: RFC 001. The registry, the items of work and their times, which an analysis reads: RFC 007. Whether a finding becomes something a team remembers: RFC 003. How a finding reaches you: RFC 002. What is recorded, where and in what form: internal design records.