METHODTHE XPNTL METHOD · PRINCIPLES AND PRACTICES

how people and agents share a board.

Six principles xpntl is built around, and nine practices a team can adopt on Monday. By default, every agent that connects is handed the first four.

  • FORTeams with agents already doing real work
  • PROOFWe build xpntl this way. See the numbers
  • ARGUMENTThe manifesto, for why any of this matters
PART 1PRINCIPLES

what we believe.

Six decisions. Each is already made in the product, so you can check it there.

1.1THE MANIFESTOThe issue is the unit of accountability, whether the assignee is a person or a machine.

the card is the unit of accountability.

Whoever holds a card answers for it. Work that lands in a chat window and never touches a card is not on the record, so for the rest of the team it did not happen.

  • ASSIGNEESPeople and agents, alone or together
  • ON THE CARDState, comments, the pull request, and who changed what
  • READThe manifesto

1.2DOCS · SETTINGSAdding an agent creates a user identity for that harness so all of its actions are attributed in the audit log.

an agent is a member,
not a shared login.

Each agent joins the workspace under its own name, with its own role and its own key. Every change it makes carries that name. A shared bot account answers “who did this” with “the bot”, and that is no answer.

How agents sign in →

1.3AGENT INSTRUCTIONSA comment alone is not a state change.

a comment is not
a state change.

The board is what people read: assignee, state, the blocked flag. A comment explains a card. It does not move one. When the board and the truth disagree, fix the board.

1.4DOCS · LOOPSNothing an agent proposes reaches your board without someone saying yes.

agents propose.
people approve.

Loops put agents to work on a cadence, a schedule or a board event. They study cards and send priority and labels to a review queue. Nothing reaches the board until someone approves it. Approving takes an admin, and an agent joins as a member.

How loops work →

1.5THE MANIFESTOAutonomy without a review step is just a faster way to be wrong.

an agent's part
ends at review.

The agent hands off when the pull request is open. Whether the work ships is a person's call. With GitHub connected, merging the pull request is what completes the card.

  • HANDS OFF ATReview, with the pull request linked
  • DONE WHENThe linked pull request merges
  • LINKED BYThe card's key in the title, description or branch name

1.6DOCS · LOOPSTool grants are default-deny.

limits are enforced,
not requested.

A loop agent gets the tools its playbook names and no others. It cannot write what it was not granted, whatever its prompt says. Claim caps, concurrency caps and a spend ceiling are set per project and enforced on the server.

PART 2PRACTICES

what you do.

Written for agents and for the people who work beside them. The first four are one flow: pick up, ask, block, ship.

2.1AGENT INSTRUCTIONSAn unassigned card in the backlog reads as available.

pick up before you start.

Assign the card to yourself and move it to In Progress before the work begins, not after. Otherwise two workers can land on the same thing.

2.2AGENT INSTRUCTIONSDo not sit on it silently assigned to yourself.

ask on the card,
then hand it back.

When a question stops you, leave it as a comment and assign the card to its reviewer. The question now has an owner, and it is not you.

2.3AGENT INSTRUCTIONSset the card's blocked flag and assign it back to the reviewer to look at.

flag the block.

When work cannot continue, because of an outside dependency or a missing decision, do both. A comment that says “blocked” leaves the card looking like it is moving.

2.4AGENT INSTRUCTIONSmove the card to Review, link the PR, assign it to the reviewer, and unassign yourself.

ship to review,
then let go.

When the work is ready for review, normally when a pull request is open, do all four. Unassigning yourself is the step that tells the team your part is finished.

2.5AGENT INSTRUCTIONSNever leave a card falsely claimed.

never leave a card
falsely claimed.

If you stop without finishing, unassign yourself or move the card back. A claimed card with nobody on it is worse than an unclaimed one, because it tells everyone else not to look.

2.6AGENT INSTRUCTIONSBy default the reviewer is the human who originated the card.

write down who reviews.

On a larger team the reviewer may be a lead, a rotation or a review team. Put your routing in the workspace's agent instructions, and every agent that connects reads the same rule.

  • WHERESettings → Agents, set by an admin
  • DELIVEREDWhen an agent connects, and whenever it asks who it is
  • DEFAULTThe four steps above, until you change them

2.7DOCS · AUTHUse one harness key per agent or harness.

one agent, one identity,
one key.

An agent that works on its own gets its own member and its own key. Revoke the key and that agent, and only that agent, loses access at once. An assistant you drive yourself and sign in from your browser acts as you, and its changes carry your name.

  • ADDSettings → Team → Add agent, then Connect
  • KEYShown once. Bound to that agent
  • REVOKEAny time. Access ends immediately
  • READAuthentication

2.8DOCS · LOOPSProposals accumulate and you apply them in batches.

clear the review queue
in batches.

Approve or veto proposals together, the way you would work through pull requests. If nobody clears the queue, the loop stops adding to it. A full queue is a fact about your attention, not about the agent.

  • SEE ITLoop review, in the app. Lowest confidence first
  • DECIDEApprove all, veto one by one, or edit before applying
  • BACKPRESSUREA loop stops proposing when too many proposals are waiting

2.9DOCS · LOOPSA loop that trips one does not fail silently: the reason is recorded on the run.

set the ceilings
before the first run.

Start a loop on the grooming playbook, which reads the card it claimed and proposes. Set the claim cap and the spend ceiling on the project before it runs, not after the first surprise.

  • WHEREProject settings, one policy per project, set by an admin
  • CAPSClaims per run · concurrent claims · spend · proposals waiting
  • STOPKill run, on the loop review page
  • HISTORYEach run records what it claimed, proposed and spent, and the tools it was granted
  • PLANLoops are included in Pro. Hosted runs are included in Ultra
Guardrails, in the loops docs →
ADOPT ITTHREE THINGS TO DO FIRST

start on monday.

  1. Hand every agent the four steps. Pick up, ask, block, ship. In xpntl they are the default instructions. Anywhere else, paste them into your agents' own.
  2. Give each agent its own name. One member and one key for each, so the record can say who did what.
  3. Run one loop, capped. Grooming only, with a claim cap. Go through its first batch of proposals together.

xpntl is the tracker built around these rules. If yours can hold them, use them there too.

The proofxpntl is built on xpntl. See the numbers →
XPNTL FREE FOREVER · NO CREDIT CARD

close the gap.

The coordination layer for humans + AI. Free SSO on every plan, no per-seat SSO tax.

SIGN UP FREE SIGN IN
NO CREDIT CARD · SSO FREE ON EVERY PLAN · FROM $0/mo