Sworn pre-1.0

Sworn agents. Sworn contracts. Independently verified.

Every merge has a receipt.

Each piece of work is a written contract. Planner, Implementer, Lead and Verifier each own one part of it, every handoff is recorded, and Sworn merges only on a recorded pass.

Build from main Source on GitHub

How a change moves

How work moves through the team A process diagram with three pools, top to bottom: the Principal; the Manager, whose one long task runs the width of the run; and the Sworn run, with lanes for the Planner, Implementer, Lead, Verifier and Sworn. The list that follows gives each step in words. Principal Manager an ongoing agent session, driving Sworn through its CLI or MCP server Sworn run Planner Implementer Lead Verifier Sworn commands status, questions, stops Start the release Approve the plan Approve the change Approve promotion to main Start the run Watch every step: answer, retry, pause, resume Open the promotion pull request Check and route under a written policy Propose the plan Explain the design Review the design REVISEdesign gap ESCALATE contract, authority or outside decision PROCEED Build the candidate Independent, read-only check FAIL BLOCKED cannot be verified as written Propose a revised plan PASS after the assembled release passes Merge into the release branch How work moves through the team A single column of steps, each labelled with the role that owns it. The Manager is a rail down the left beside every step, with its tasks on the rail; the Principal's approvals sit where they happen; the exception path is under the main path. The list that follows gives each step in words. Manager an ongoing agent session, driving Sworn through its CLI or MCP server Start the release Principal Watch every step: answer, retry, pause, resume Start the run Propose the plan Approve the plan Explain the design Review the design REVISEdesign gap ESCALATE contract, authority or outside decision PROCEED Build the candidate Independent, read-only check FAIL BLOCKED cannot be verified as written PASS Merge into the release branch after the assembled release passes Open the promotion pull request Approve promotion to main ESCALATEorBLOCKED Propose a revised plan Check and route undera written policy Approve the change back to Explain the design Planner Principal Implementer Lead Implementer Verifier Sworn Principal Planner Principal
  1. The Principal starts each release through the Manager.
  2. The Manager runs the release on the Principal's behalf, as an ongoing agent session that drives Sworn through its CLI or MCP server.
  3. It starts the run, watches every step, and answers, retries, pauses or resumes under a written policy.
  4. At the end it opens the promotion pull request, and the Principal decides whether the release goes to main.
  5. The Planner proposes the plan.
  6. The Principal approves the plan, directly or through a Lead delegation the Principal grants.
  7. For each design attempt, the Implementer first returns a concise design and stops.
  8. The Lead reviews the design and returns PROCEED, REVISE or ESCALATE.
  9. REVISE sends a design gap back to the Implementer for another design attempt on the same slice.
  10. PROCEED lets implementation begin, and may carry bounded corrections inside the approved contract.
  11. ESCALATE names one decision outside the Lead's remit, when behavior, contract, authority or an outside decision needs revised approval.
  12. An independent Verifier, separate from the Implementer and Lead, makes one read-only check of the exact candidate and returns at most one verdict: PASS, FAIL or BLOCKED.
  13. FAIL sends the same slice straight back for another implementation attempt.
  14. BLOCKED means a trust-critical fact cannot be established.
  15. An ESCALATE or BLOCKED hands the work to the Planner. A revised plan goes to the Manager, who checks and routes it under a written policy, and the Principal approves the change.
  16. The Manager never approves a plan revision and never merges to main.
  17. Once every slice has passed, a fresh Verifier checks the assembled release, unless the release is one slice built directly on the target branch.
  18. After the release passes, Sworn, never a model, merges the exact passed candidate into the release branch.
  19. Merging a release to main is always the Principal's decision.

A successful model response is never treated as an approval or a passing verdict.

The seat

Running fully unattended is a non-goal.

Principal
The accountable human. Under the Manager's written policy, plan approval, roster or model changes, and merging a release to main go to the Principal.
Manager
Runs the release on the Principal's behalf: an ongoing agent session that drives Sworn through its CLI or MCP server. It starts the run, watches every step, answers questions, retries, pauses and resumes, and keeps a decision journal. It decides what its written policy covers and brings everything else to the Principal. In a recorded trial, a second harness on a non-Anthropic model filled the seat read-only through the MCP server alone.

Your models

There are no model defaults or fallbacks.

A production run names the exact AI profile and model for every role. Planner, Implementer, Lead and Verifier may be model-backed.

Watch it run

The terminal board, JSON status and a local browser board show the same saved facts.

Every dispatch journals one bounded, redacted record per worker turn as it happens. Sworn saves commands and external work before execution, so a stopped process can recover from recorded facts instead of guessing.

Build from main

Sworn is pre-1.0. To try it, build the latest from main.

Sworn currently supports Linux x86_64, and you need Go 1.26.5 or newer to build it. Running model work currently needs Git, a root-owned bwrap on PATH and unprivileged user namespaces.

git clone https://github.com/swornagent/sworn
cd sworn
go build -o sworn ./cmd/sworn
./sworn version

Field notes

All field notes