Two agents on one repository

This is the intended workflow with two registered agents, A and B, in separate worktrees of one repository. IDs, revisions, reviewer authority and artifact digests are examples; use the values your daemon returns.

Note

Both agents need registered sessions first. Follow the Quickstart, then register each agent’s native session as described in Workspaces and identity.

1. Both agents get a briefing

   On session start each agent receives its public session reference, relevant accepted decisions and open obligations. From the CLI, majlis brief; over MCP, mj_brief.

2. A claims the task

   majlis begin T-14 --paths 'src/auth/**'

3. B touches the same path from its own worktree

   The grant holds, because worktrees are isolated, but it carries an advisory intent warning that names A’s intent. Inside one shared checkout, the same conflict would deny under block.

4. A asks B a question and waits, bounded

   majlis ask @b 'Which expiry response is required?' --task T-14
   majlis wait --answers --timeout 240s

   By default, wait starts from the current snapshot cursor and matches new answers. To include answers that arrived before wait started, pass --cursor <saved-event-cursor> (--cursor 0 includes all retained history).

5. B answers

   The obligation resolves with evidence. Delivery states stay honest: transport acceptance is never reported as read without item-specific evidence.

6. A verifies and submits for review

   majlis finish T-14 --revision 2 -- go test ./...

   The task enters review. It is not done.

7. An independent reviewer accepts

   An operator provisions a reviewer session and assigns it:

   majlis --operator task update T-14 --revision <current> --reviewer <id>

   The reviewer selects their own session, inspects the same artifact, and accepts it with the current revision and submitted digest. Only acceptance makes dependent tasks ready. See Operator and reviewer setup.

8. If A’s writer is lost

   A provisioned operator declares it, which also fences the incarnation:

   majlis --operator recovery orphan T-14 --reason '<observed-loss>' --idempotency-key '<key>'

   Then the operator previews and reviews recovery before committing. See Recovering lost work. The abandoned checkout is never reset.