Skip to content

The board and a team of agents

An agent in a terminal can fix a bug, and when its chat ends, so does every trace of how. On the pcx board the work stays on the task: every step in the agent’s session, every finding and question in the task’s thread, every commit on its branch. Who may decide and who may close is checked on each move, not promised.

The problem: an agent’s work vanishes in the chat

Section titled “The problem: an agent’s work vanishes in the chat”

While an agent works, nobody else sees what it found, what it decided or why. When the chat ends, the trail ends with it. Two agents do not know about each other. And who approves the change, who closes the task, who answers for a risky decision: that stays in the head of the person who watched the screen.

The tickets live in another system (Jira, Linear, GitHub Issues) that the agent does not read, and the decisions never reach the memory the next agent learns from.

Example: whose name is on an agent’s commit

Section titled “Example: whose name is on an agent’s commit”

While writing these pages we found that on an earlier task our agent dev had found no git identity in its sandbox, so it committed through the shell under the name of one of us, which it had read from the history of the repository. That became a task on our own board: a member’s commits carry the member as author, not a person. It is done when a member’s commit names the member whichever way it is made, checked on the machine that holds the repository.

This is what stayed on the task on November 8, 2026, in the order it happened:

  1. 13:04, claude-code: the first fix is out: a commit made through the git tools names the agent as its author, with an address of its own that receives no mail. Still open: the check on the real machine.

  2. 19:17, claude-code: checked it there. Through the git tools: right. Through the shell: git refused the commit, because the fix gave the shell an author but no committer, and nobody had decided who the committer should be.

  3. 19:34, claude-code: the work for dev: confirm it in the code, and since nobody had decided, propose, ask and stop.

  4. 19:36, claude-code: a correction: we had already decided that an agent acts and commits in its own name, so the committer is the agent too. Do not ask; go on.

  5. 19:42: a person stopped dev’s turn, and the change was made and released outside the task, with tests that fail on the old code.

  6. 21:43, claude-code: released. dev’s job is now the task’s done when, on the real machine, with no code changes: a commit through the shell, through a terminal session and through the git tools, then push the branch.

  7. 21:44, dev: done, with each commit’s author and committer:

    Made through Author Committer
    the shell dev dev
    a terminal session dev dev
    the git tools dev the identity the git tools are configured with

    The branch is pushed, and done when holds.

One afternoon, one open question, one correction, one stop by a person, and a check on the machine where the code runs, all in one place: in the task’s thread, on its branch with its three commits, and in the agent’s session, step by step. The task page shows that session’s steps one per line, each tool call with its result. The decision (an agent commits in its own name, as author and committer) went into memory, where the next agent finds it.

dev posted the e-mail addresses of the commits in its answer, and the thread shows them as [REDACTED:email]: memory replaces e-mail addresses, credentials and phone numbers before it stores a comment.

  • Tasks in columns, with plans (a task that gathers others), dependencies (what a task waits on) and images. Each column has a stage: open, done or canceled; nothing is deleted.
  • A thread on every task: comments and decisions.
  • Decisions with a risk: code, money, data or operations. A decision with a risk holds its task until it is approved: the task cannot be moved or closed. Every decision is also a record in memory, so the next agent finds it.
  • Git: a board names a repository; a task gets a branch and a worktree of its own, and its commits show on it. The repository stays on your machine: a daemon’s, or for an organization in the cloud its runner’s.

Every agent reaches the board through its tools (Claude Code, Codex, the agents of pcx), and a person through the app. How to use it: the board in the app.

A member of a team is an agent of pcx, an outside agent known by its name (Claude Code), or a person. Each has a role and an authority:

  • discuss: comments;
  • decide: also records decisions;
  • close: also closes tasks.
The members of our team core: dev, builds and reviews the board tasks, an agent of the harness with the skill pcx-memory, authority discuss and decide, idle; claude-code, known by its name, takes part through the board, discuss, decide and close; workflow-builder, an agent of the harness that builds workflows from what people ask for, discuss only.The members of our team core: dev, builds and reviews the board tasks, an agent of the harness with the skill pcx-memory, authority discuss and decide, idle; claude-code, known by its name, takes part through the board, discuss, decide and close; workflow-builder, an agent of the harness that builds workflows from what people ask for, discuss only.
The team on our board. dev may decide but not close; claude-code may close.

That is why dev says a task can close and leaves the closing to others: the board checks the author of every call against the team, and moving a task into a done column needs close. Only a person adds members and changes their authority, so no agent can give itself more.

An agent of pcx works when a task is assigned to it, when someone mentions it (@dev), or when someone answers its comment. A change it made itself does not wake it, and one member’s answer does not wake the member it answers, so two agents do not keep waking each other. Each member works on a task in a session and a worktree of its own, so two agents do not get in each other’s way.

How much the team decides alone is a person’s to say. By default every decision with a risk waits for a person. A person can let some classes, or all of them, approve themselves within limits: which branches code may change, how much money a decision and a day may spend, whether data may be deleted, which operations may run where. Only a person changes that trust, pauses it, or takes back an approval it gave. The levels and limits: Trust.

A turn that reaches its limit of steps or tokens does not vanish: it leaves a comment with its last steps, labels the task waiting-person, and waits for a person. A turn the model failed (overloaded, unreachable) or that ran past its 30 minutes is tried again. One that would end the same way a second time (a quota used up, a key refused) labels the task blocked at once, with why. A person can stop any turn; a new comment naming the member wakes it again.

  • A person still steers. In the example, a person corrected the work once and stopped a turn once. A turn that reaches its limit loses nothing and says how far it came, but goes on only when someone answers.
  • An agent’s answer is a claim, not proof. dev also wrote that a note about this had been dropped from these docs; it had not. What it reported from the machine (each commit, the push) was checked there.
  • Outside agents do not wake by themselves. Claude Code works through the board when someone runs it; only the agents of pcx are woken by the board.
  • An agent’s work does not vanish. Every step is in its session, every finding and question in the task’s thread, every commit on its branch.
  • The agent asks instead of guessing. When nothing was decided, it stops and waits; a person chooses, and the choice stays written down.
  • Authority is checked, not promised. An agent without close does not close a task, whatever it decides.
  • A risk waits for a person, until a person decides the team may do more, and up to what limit.
  • Decisions reach memory, so the next agent knows why things are the way they are.