When everyone on the team has their own coding agent

Take three people building one product over a weekend. Each has a coding agent, and they don't all use the same one. Priya has Claude Code, Sam has Codex, Jo has Cursor. Every agent is good. Every agent also knows exactly one person's side of the story.

By Saturday afternoon, Priya's agent has built a token refresh flow. Sam's agent has built a different one, because Sam never said anything in a chat Priya's agent could read. Jo's agent has named the same table two ways in two migrations. Nobody was careless. Each agent did what it was told with the information it had.

The usual advice for several agents on one repo covers the git side: worktrees, branches, ownership. A team adds a harder problem on top. The agents can't talk to each other, and their people are busy.

What actually needs sharing#

Less than you would guess. Not transcripts: they are long, private, and mostly irrelevant to anyone else. Four short things carry nearly all the value:

• Decisions. What we settled on, and why. "Sessions are cookies, not JWTs."
• Ownership. Who is doing what right now.
• Blockers. What is stuck and what would unstick it.
• Handoffs. What is done, where the branch is, what is next.

These are the same four things a human teammate needs when they sit down next to you. Writing them down helps even if no agent ever reads them. It helps a lot more once one does.

A board that agents are told to use#

You don't need special software to start. A shared list works: a GitHub Project, a Linear board, a TASKS.md. The tool matters less than two rules, and the rules go in CLAUDE.md or AGENTS.md so that every agent, whichever tool it is, follows them:

## Team workflow
- Before starting work, read TASKS.md and DECISIONS.md.
- Take a task by writing your name on it first. One owner per task.
  If it already has an owner, pick something else.
- When you finish, change the task to done and add the branch name.
- If you make a choice another part of the code will depend on
  (an API shape, a library, a naming rule), append it to DECISIONS.md
  with the date and one line of why.
- Never wait silently. If you are blocked, write the question on the
  task, say what you will do in the meantime, and move to another task.

The decision log earns its keep fastest. Keep it append-only, newest at the bottom, one entry per decision:

2026-10-03 Sessions are cookies, not JWTs. Reason: we need revocation on day one. (Priya)
2026-10-03 Table names are singular: `order`, not `orders`. (Jo)

Two lines each. An agent reads the whole file at the start of every session and stops guessing about things the team has already settled.

Who asks whom#

When an agent needs an answer, there are three possible targets, and picking the wrong one costs the most.

Ask your own person first. Your agent works for you. If it is unsure about something that is in your head, such as what "done" means for this feature, ask you.

For anything about another person's area, your agent asks you, and you ask them. It is tempting to let agents message each other directly. Resist it for decisions. An agent asking another agent for a decision gets a confident answer from something that doesn't hold the authority to give one. Facts are fine to exchange agent to agent ("which branch has the login form?"). Choices belong to people.

Don't ask at all when a default will do. Most questions have an answer the agent can pick, note, and revisit. The best question format is the one that can be answered in ten seconds:

Q: Should refunded orders appear in the CSV export?
Default if no answer in 15 min: yes, with a "refunded" column.
Blocks: the export task only. I'm starting on the UI instead.

The question, a default, what it blocks, and what the agent does meanwhile. Compare that with "I have a question about the export", followed by forty minutes of an idle agent.

The cost nobody counts: an agent waiting on a person#

A parked agent costs nothing on the invoice and a lot in the schedule. The slowest part of a team of agents is almost always a person who is away from the keyboard: at lunch, in a talk, asleep. If every question needs you at a laptop, your agent's throughput is capped by your habits.

Three things help.

1. Make questions small. Yes or no, or pick one of two. If a question takes a paragraph to answer, it was a design discussion, and it should have a real conversation.
2. Make them answerable from a phone. A quick answer in a hallway is worth more than a perfect answer in an hour.
3. Always give the agent something else to do. The rule above ("move to another task") is what keeps a blocked agent useful.

Pull requests from agents#

One last thing that goes wrong at team scale: review. When three agents open pull requests, who reads them? A rule that works: the person whose agent wrote it reviews it first, then merges or asks a teammate. The author's person is the one who knows what they asked for. Put the agent and the person in the branch name, priya/claude/token-refresh, so a glance at the branch list tells you whose work it is.

Keep pull requests small, merge at least every couple of hours during a hackathon, and rebase before you open one. A weekend project doesn't survive a Sunday-night merge of three week-long branches.

Where Joxo fits#

You can run all of this with a markdown file and discipline, and for two people it's enough. It strains when the agents belong to different people on different machines. A file only changes when somebody pulls it, and two agents can claim the same task in the same minute.

Joxo is a shared project for exactly this: the board lives where every agent can see it, a task can be held by only one agent, decisions reach everyone's agent, and when an agent needs a person, the question lands on their phone with the answer a tap away. Everyone keeps their own plan, in whichever tool they already use. The routine above stays the same. Joxo takes over the part that needs a server.