Repository navigation
History RFC 007 Harness
Starting a team and keeping it running.
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, one sentence of section 7 that said why this text came second, and one line in the last section pointing at RFC 005; no commitment changed.
Draft 6, 2026-10-06, after round 4. Three reviewers from three labs read draft 5 and all three stood behind it. This draft differs from draft 5 by one sentence, made plainer at a reviewer's suggestion (commitment 2, "today"). It is the text put to the board's vote. The title was shortened to "Harness" at the founder's request after the reviewers' vote.
A team is made of agents from different labs that share nothing: each is started its own way, shows its own screens, stops for its own reasons. What does TeamCLI take on itself, so that a team starts from one sentence and keeps working without a person standing behind it?
The harness we are building is the one layer every agent of a team goes through, whatever lab made it: an agent is to be started by it, known to it, told things through it, stopped and replaced by it. The released version does part of that, and section 7 says which part. What the harness does not do, a person ends up doing by hand, and a team that needs a person at a terminal to keep running is not a team that works for you.
We say this from experience. In two days of running our own teams we stopped and started them by hand, renamed an agent's place so that the tool would recognise it, wrote notes for agents that had lost their thread, and found, three times in one afternoon, finished work that had waited hours because nobody had been told. Each of those is a job the harness did not do. This RFC is the list of those jobs, as commitments.
Eleven commitments to the person whose team it is. Each says what we are building towards and, where something of it exists in the released version, what that is. Section 7 gives the same row by row. Nothing here gives the harness a power that RFC 001 does not give: where the harness acts by itself, it acts inside what was agreed, and anything else waits for someone who holds the right.
-
One sentence starts a team. We are building towards this: you say it to an agent you already use, or you type one command in your project, and an agent looks at the project, finds the agents you have and sets up a team from them, never from what it wishes you had, and only among the agents your settings let a team use. Setting up a team is the command
create; whether an agent may run it, within which ceilings, and whether creating also starts the team, are the right you gave and its settings (RFC 001). Where you gave none, you are the one who agrees and starts. Today one command writes a starting file, and a person agrees to it and starts the team. -
A team has the shape you choose, and it changes with the work. We are building towards a team of any shape: one agent or twelve, with someone who leads or without, and no part of TeamCLI requiring a role your team does not have. And towards a team that takes on an agent for a piece of work and lets it go after: only an agent of a kind you agreed to, started as agreed, within the numbers you set, and never a copy of an agent that may itself agree or grant; that copy, like an agent of a new kind or from a lab you did not agree to, waits for someone who may grant it (RFC 001). Today a team may have any number of agents and its file must name one that leads; an agent declared in the file can be started and removed by a command, by a person, or by an agent given that command; such an agent can start only an agent that is declared, not marked stopped and not running, while a person can also start one marked stopped. A person can take on copies of an agreed agent, up to a number set in the file.
-
Every agent of a team is registered. We are building towards one record per agent, written when TeamCLI starts it and kept current: its role, its lab and the model actually running, where it runs, since when, under which agreement, and what it is working on. The record is a report TeamCLI checks against the agreement and against the running agent. It gives no right: what an agent may do is what was agreed (RFC 001), and another team cannot rely on an entry for more. TeamCLI is to find its agents from this record, so that nobody has to rename the place an agent runs in for the tool to recognise it. Today where each agent runs is recorded; the rest is in several places, not joined.
-
Work goes only through a team's agents. We are building towards TeamCLI counting as work only what its registered agents do. An agent started on the side is one you never agreed to, cannot see, cannot stop with the team, and that counts against nothing. Until agents are contained, TeamCLI can refuse to count such an agent; it cannot prevent one. Today nothing knows of an agent started on the side.
-
You can ask what everyone is doing, what everyone is waiting for, and what is left. We are building towards an answer made of facts, each with its source, and "not known" where there is none: who works on what since when, what is finished and unread, who is waiting on whom, what each lab has left of what you pay for and at what pace it is going. Today you can see who is working, idle or stuck, and for some labs what is left.
-
Stopping stops, and starting starts. We are building towards this: one command, by whoever holds the right to it, ends with the team down, and one command after it ends with the team up, whatever state an agent was left in and without a second command for a person to run. Today both can fail and leave something for a person to do. It is the plainest commitment here and the one we broke most often.
-
An agent can be changed without losing the thread. We are building towards this, for an agent whose lab's limit is reached, that stopped, or that can hold no more of the task. Work is closed out while the agent still holds it. The agent that leaves hands over what is done, what is in progress, what is waiting on whom and what comes next; if it cannot be asked, TeamCLI writes that from what it recorded and says "not known" where the record is silent. The agent that arrives says back what it understood before it acts. By itself the harness only restarts an agent, or puts an exact agreed copy in the same place, and either only once it has established that the agent it replaces can no longer act, so that two never hold one place; where it cannot establish that, it does neither and says so. It never does the second for an agent that may agree or grant: a copy of that agent is a grant (RFC 001), and its place waits for someone who holds the right. An agent from another lab, started another way or holding another list, is likewise a change someone with the right must make, and the handover then serves that change. Today a change of agent is done by hand, with a note someone writes; closing out is a sentence given to agents.
-
A team never stands still in silence. We are building towards this: when work is open and nobody is working, TeamCLI notices in minutes, wakes whoever is due to act, and tells apart an agent that waits, one that reached a limit, one that failed and one that is gone; when the one who should act cannot, it says so to whoever is above, and where nobody is above, to you. Today a watch tells a team's own agents that results wait; nothing crosses from one team to another and a stall is not named.
-
What TeamCLI knows is wrong, it puts right, and only that. We are building towards repairs it makes by itself and tells you of: starting again an agent whose start was interrupted, and clearing the marks TeamCLI itself left when a stop was cut short, which it recorded as its own. A repair restores what the agreement already says. Adding an agent, changing a lab, a way of starting, a list or a limit, moving work to another agent, deleting anything an agent or a person wrote, or anything else that cannot be taken back is a decision, not a repair, and is never made as one. Today TeamCLI names the repair and prints the command for a person to run.
-
The machine is part of the team. We are building towards a harness that asks the system to stay awake while agents work, tells you when the machine will sleep anyway, pauses the team before the battery ends, and after a sleep or a restart finds out which agents are still there and brings the team back to what was agreed. Today it checks the machine before starting, and nothing more.
The harness we are building is the time master: it is to be the only part of a team that knows the real times. Nothing of that is built.
- Every piece of work is an item that one agent holds, and the harness keeps time. We are building towards this. An item is asked, taken, waiting on someone, checked, done, and says so when it happens; one agent holds it at a time, so that two do not do or overwrite the same thing, and an item whose agent is gone has someone to answer for it. The plan lives in the tracker you already use; TeamCLI writes what happened into it and reads what you changed, and with no tracker it keeps its own list. It says early when a plan will not hold, from what the agents can really do in a period; what is due at an hour happens at that hour; and each estimate is kept beside what happened. Today work is known by the files and messages agents leave, and nothing is scheduled.
As these are built, all of it is to be yours to set, for everything you do, for one team or for one agent: how long an agent may wait before it counts as stalled, whether an agent keeps what it learned between tasks or starts fresh, what the harness may repair by itself, what happens at which hour; and each setting is to have a default that works if you never open it. Today only what is built has settings.
Each commitment answers something that happened.
- Stopping and starting. On the day we shipped the release that let agents stop and start teams, stopping two teams took their owner six commands and one typed by hand, and starting them again was refused to the agent meant to do it. The causes were small: a screen read two seconds too early, a team that was down mistaken for a tool that did not answer. Small causes, at the most basic act, cost more trust than any missing feature.
- Silence. A team stood still for three hours after a lab's limit stopped its coordinator. Its other agents kept writing results into files; a file wakes nobody. The next day, finished and reviewed work waited fifty minutes, then two hours, for one agent that was in a conversation. Nothing was broken. Nothing told anyone.
- Losing the thread. A coordinator restarted with a note written for it was working again in minutes. One closed without warning came back and began doing its operator's work, because the habit "you brief, your operator runs" had lived only in the session that was gone. The difference was the note, and nobody is always there to write it.
- Agents on the side. For days our reviews were run by agents started outside the team, because that was easier than keeping a reviewer in a seat. They worked. They were also agents the owner had not agreed to and could not see, and when he saw one he said: that is not the idea.
- A team that grows for a task. For the review of this very series of texts, three reviewers from three labs were opened in the session of the agent that coordinates everything, each for one review, to be removed afterwards. It worked, and it took the founder four approvals and eight commands, one prompt from a lab's program accepted by hand, and one line typed by the tool and never sent. Every one of those is a step the harness should take.
- The registry. After a power cut, every agent of three teams came back as a different model than its label said, and the tool's own status did not notice. Who is really in a seat has to be something TeamCLI knows, not something written on a label.
- A harness reads other companies' programs. To know that an agent is waiting, stuck or finished, TeamCLI reads its screen and its exit. Each lab changes its program when it likes. When TeamCLI cannot read an agent, it says so and does less (RFC 001); it does not guess. A new version of a lab's program can make a commitment here untrue for that lab until we catch up, and we will say which.
- A handover carries facts, not judgment. The agent that arrives knows what the other knew to write down. A different lab in the same seat is strong and weak in other places. A change of agent in a demanding seat deserves watching, however clean the handover.
- Noticing is not fixing. When commitments 7 and 8 are built, TeamCLI will be able to tell you a lab's limit stopped an agent and, inside what was agreed, put an exact copy in its place. It will not make the limit go away, nor make the second agent as good as the first; and an agent from another lab, or a copy of an agent that may agree or grant, still waits for someone who may grant it.
- A lab's own questions still wait for a person. An agent's program can stop at a notice or a question of its lab's making. TeamCLI leaves that agent out and says so; it does not answer for you unless you gave that right (RFC 001).
- The machine has the last word. A closed laptop sleeps whatever a program asks. A team meant to run through the night belongs on a machine that stays on. The harness we are building is to tell you what your machine will do; today TeamCLI reports only the check it makes before starting. It does not, and will not, change your system's settings.
- More knowing means more kept. A registry and a record of who does what are files about your project on your machine. They stay there; they are also one more thing an agent can read (RFC 001 says what contains that, and when).
- Only what goes through the team. Commitment 4 is a rule the harness holds for the agents it starts. An agent with a shell can still start another program; until agents are contained (RFC 001), TeamCLI can refuse to count it, not prevent it.
- Teams whose agents are changed often and work no worse without handovers. Then commitment 7 is ceremony and should shrink to a restart.
- People who turn the stall warnings off because they fire when nothing is wrong. Then commitment 8 is noise, and it needs a better idea of when a team should be moving.
- Labs offering, themselves, what the harness does for their agents (a way to be told, to be stopped, to hand over). Then TeamCLI should use theirs and keep its own only for the labs that have none.
- A registry that people do not read and tools do not use. Then it is a file, not a commitment.
- One sentence, two entrances. A person typing one command, and an agent asked in a conversation, end in the same place. Is anything lost by making them the same, or should the agent's entrance do more?
- The first agent. The one that proposes the team with you: the agent you were already talking to, or a new one given the conversation's substance? We lean to a new one, with the same handover as commitment 7, because it works for every lab.
- What is in the registry. Is the list in commitment 3 right? What is missing; what should not be kept?
- Who signs a registry entry. An entry is a report and gives no right (commitment 3). What makes that report something another team, or you, can rely on as true?
- When is a team stalled? "Work is open and nobody is working" needs TeamCLI to know what work is open. How much must it know about the work itself to keep commitment 8?
- Repair without asking. Commitment 9 lets TeamCLI act by itself. Where does a repair end and a decision begin?
- A team without a coordinator. Who is "whoever is above" in commitment 8, who receives a handover, when nobody leads? You; a named agent; the other agents together?
"Today" is TeamCLI 0.3.1. Rows 1 to 10 restate what one agent checked against the released code on 2026-10-06 and three reviewers then tried to break, twice; row 2 was checked again after round 2, clause by clause, and tightened after round 3; row 11 has not been checked and says so.
| # | Commitment | Today |
|---|---|---|
| 1 | One sentence starts a team | No. One command writes a starting file; a person agrees to it and starts the team. It checks the programs a team's file names; finding them unasked is designed, not built |
| 2 | The shape you choose, changing with the work | In part. Any number of agents, but a team's file must name a coordinator. A command starts an agent declared in the file, and a command removes one. A person runs them; so can an agent given that command, to start a declared agent that is not marked stopped and not running, or to remove an agent. Copies of an agreed agent are taken on by a person only, up to a number set in the file (two unless changed) |
| 3 | Every agent is registered | In part. Where each agent runs is recorded; the rest is spread over three places and not joined |
| 4 | Only through a team's agents | No. Nothing knows of an agent started on the side |
| 5 | What everyone does, waits for, and what is left | In part. Who is working, idle or stuck: yes. Who waits on whom: no. What a lab has left: for some labs, per team, when set up |
| 6 | Stopping stops, starting starts | No, as section 3 tells. The repairs are the next release |
| 7 | Changing an agent without losing the thread | No. Done by hand, with a note someone writes; closing out is a sentence given to agents |
| 8 | Never still in silence | In part. A watch tells a team's own agents that results wait; nothing crosses from one team to another, and a stall is not named |
| 9 | Puts right what it knows is wrong, and only that | No. It names a repair and prints the command; it makes none |
| 10 | The machine | In part. It checks the machine before starting. Staying awake, battery and waking are not handled |
| 11 | Items held by one agent; keeping time | No, not checked row by row: work is known by the files and messages agents leave; nothing is scheduled or estimated; one check reads a tracker at a release and nothing writes to one |
Five of the eleven are partly true, six are not true at all, and none is wholly true. That is where a harness stands when it has been asked for before it has been built, and it is why this RFC comes last: it is the one that needs the other six to be true.
Who may run which command, and who may agree to more: RFC 001 and the RFC on delegation. How agents and people reach each other, and how you are told: RFC 002, on communication; this text only commits that a waiting thing reaches whoever it waits on. What a team remembers from one day to the next: RFC 003, on memory; commitment 7 uses it and does not define it. What makes an item "checked": RFC 005, on quality. How several voices become one decision about it: RFC 006, on consensus.