A harness is not an agent thingThe checks, formatters, linters, compiler errors and gates around a change are one harness, and they hold a person to the green path the same way they hold an agent. ADR 0005: deterministic answersThe v0.5.0 finishing pass, recorded in full. A stalled multi-agent change showed where agents improvise and where magus stays silent. The person drives; magus answers from the graph, the job store and typed APIs, and prints what to run. Every idea and use case raised during the pass is listed here with its state, so this page is also the plan. ADR 0006: the person drives reviewDraft. Agents write code faster than we can review it, and review has become the bottleneck that does not scale. This records what a review of agent-written pull requests found, what magus enforces on its own tree versus what it ships to anyone else, and how a local review reads in an order built from the code's own relationships, with a person driving every step. ADR 0009: cost profiles for agent sessionsThe guard keeps a long-running root session from spending its context on work a cheaper worker could do. One level, set by magus\guard.profile and defaulting to light, picks how much of that advice a workspace sees; the account's billing and model facts live in magus.yaml, detected from the host and never from an environment variable; a person may raise the level and never lower it. ADR 0013: the guard deniesADR 0006 section 2 shipped every built-in rule that guards a recoverable action as advice, said once a session. Six months of agent sessions show advice that only prints is routed around, so this record reverses it. Every built-in rule whose verdict names a remedy the caller can take now denies by default, shipped defaults included. A rule with no reachable remedy becomes a notice, which states a fact and never refuses. A workspace still lowers any deny to advise or off by name. ADR 0014: running magus is the consentRead verbs evaluate a repository's magusfile, and four passive paths ran a repository's code or rewrote its version-control metadata without a command asking. This record refuses a workspace trust store. Invoking magus in a repository is the consent to run its code, as with make or gradle, and magus never runs that code passively. The agent host gates folder open. ADR 0015: a call runs where its line saysHost shells differ in where a subagent's call starts, and the lease rules read only the directory the host reported. This record has the guard place each magus call by its own line, denies a holder's call that resolves outside its checkout, and leaves the CLI's root rules alone. ADR 0016: vcs lists; the person stagesThe guard denied git add -A and served magus vcs add, a command that classified the tree and staged it in one call. This record replaces it with magus vcs ls-files, which lists the paths a commit wants and stages nothing, so each inclusion is a flag the caller names and the staging stays a git command the person runs. AgentA model working through an agent host such as Claude Code, Codex, Cursor or OpenCode. magus treats an agent as one more caller of its CLI, MCP tools and console, held to the same checks as a person. Agent harness benchmark (2026-09-10, anthropic claude-opus-5)One published run of the agent harness benchmark, the controls first, then cost-of-pass, paired deltas and pass rates. Generated from the committed report. Agent harness benchmark (2026-09-10, anthropic claude-sonnet-5)One published run of the agent harness benchmark, the controls first, then cost-of-pass, paired deltas and pass rates. Generated from the committed report. Agent skillsEvery skill magus installs, in both curated forms, generated from the embedded bodies. AgentsHow magus equips AI agents (the installable skills, the MAGUS.md routing index, the MCP server, and the guard hook any agent host can wire), with a setup page per host. Agents propose, humans disposeAn agent integration can suggest work but never accept it; authorship comes from the transport, never the writer's claim. Any other hostThe host-neutral contract (install the guidance where your host reads it, pipe the event to magus shell, render the verdict with -o template) for an agent host magus does not document by name. Attention hooksmagus session notify turns one host event into a desktop notification, so a blocked or finished agent reaches you, and why this is a hook sink rather than an MCP tool. BenchmarksWhat magus measures about itself and publishes: the agent harness benchmark (does the agent integration make an agent cheaper or better on a real repository) and the build-tool comparison, with every run's environment stamped beside its numbers. Built for the expensive eraMove what a model would have to work out into deterministic, checked answers, so a smaller model can do the work. Claude CodeWiring magus into Claude Code (skills in .claude/skills, the two PreToolUse guard hooks, attention notifications, and the checks that prove the guard is running). CodexWiring magus into Codex (skills in .agents/skills, the AGENTS.md block you paste, MCP in the user-level config, and the hooks that carry the guard, the spawn check, the message record, the checkpoint, the opt-in reply check and the post-compaction brief). Corrective competenceThe skill this section protects is your ability to fix the thing yourself when the agent is wrong, or gone. CursorWiring magus into Cursor (AGENTS.md for guidance, one hook script for its wired events, the opt-in reply check on stop, and what Cursor's contract cannot express). Determinism at chosen pointsmagus fixes a step where it can prove the answer and leaves the rest to the model; a person chooses which steps are fixed. Enforcement, not pinky promisesA rule written only as prose in an agent's context is a pinky promise; each rule lives at the lowest layer that can enforce it, and skills teach rather than guard. Guard hook templatesThe Buzz hook templates Claude Code and Codex run for the magus guard, the checkpoint and the post-compaction brief, with the knobs that adapt them to a host, the version marker that tells you when your copy is stale, and the full source of each. HarnessThe deterministic scaffolding around the work on a change, for a person or an agent: compiler errors, formatters, linters, checks, gates, leases and hooks, placed at points a person chose. Around an agent's loop, magus supplies one and keeps it outside. How orchestration worksThe three roles a fanned-out agent session splits into (orchestrator, worker, integrator), the boundary each one holds, and the pieces of magus that hold it (the guard, the job store, the broker's machine budget and the worktree bootstrap). Human in the loopAn agent proposes and does bounded work; a person decides at named points, each explicit, reasoned and recorded. Human-first is the AI integrationNothing is designed for an agent first; an interface legible to a person is legible to anything. Jobs and leasesWhat magus gives an agent that fans work out (the working-state checkpoint, the declared job store, the lease a holder takes on a job, the console Jobs view, the recorded spawn, and verifying a result against the diff since the checkpoint). Long-running sessionsWhich host scheduler keeps an agent session going for hours (Claude Code loops and goals, desktop and cloud scheduled tasks, Codex, Cursor, GitHub Actions), the magus commands each wake runs, the cloud risk of an unguarded clone, and what magus leaves out. MCPmagus serves its tools as a Model Context Protocol server, over stdio for the agent host that launches magus mcp, or over Streamable HTTP from magus server. MGS1045: a magus\guard.spawn, command or write registration is unusableFires when magus\guard.spawn, magus\guard.command or magus\guard.write is handed something other than a function, is called twice in one load, or is called from a magusfile other than the root one. The workspace does not load. MGS3018: a directory as a job write pathFires when a job is forked with a write path that names an existing directory, a project root or the workspace root included. The fork is refused; list the files the job edits. MGS3024: a hook names no agent hostInstalled hook glue called magus without --agent-name, so magus cannot tell which agent host it is answering. The call is refused, and `magus describe harness` prints a configuration that names the host. MGS3031: a declaration claim nothing can gradeFires when a job is forked with a write or deny path that names one declaration of a file (path#declaration) and no footprint could ever check it. The fork is refused; name the whole file, or give its extension a diff driver. MGS3032: an unordered share of one claimable fileFires when a job is forked with a write path that names the same single literal file, with a diff driver, as another live job's write path in a different checkout, and neither job is ordered against the other by parent, child, or depends_on. The fork is refused; claim a declaration, add --depends-on, or fold the work into the holder. MGS3036: a project's configuration held wholeFires when a job is forked with a write path that names a project's magusfile or magus.yaml whole, with no glob and no claim, in a checkout that can place its declarations. The fork is refused; claim the keys and declarations the job changes. MGS3037: a job record field fails its shapeFires when a job record carries a field magus cannot read as declared, such as an id that is not a lease id, a relative checkout or a path outside the workspace. The record is refused; fix each field the problem names. MGS3038: a job goal no evidence could gradeFires when a job record declares a goal that could never be met or graded, such as one naming nothing to examine, a duplicate id, a dependency cycle or two signatures for one symbol. The record is refused; fix each goal the problem names. MGS3039: a job nothing would gradeFires when a job record writes files but declares no check or goal, or declares no write paths without being read-only. The record is refused; give it a check, a goal, write paths or read_only. MGS3040: a job check its worker cannot runFires when a job record's check names an unknown project or target, a command the guard denies, a check only a person may run, or a run that skips the tests of the packages the job writes. The record is refused; name a check the worker can run to a passing record. MGS3041: a job checkpoint this checkout cannot placeFires when a job record's checkpoint is neither this checkout's HEAD nor an ancestor of it, or its digest does not match the working state. The record is refused; fork it from a checkout at that checkpoint, or name this one's. MGS3042: a job fork past the workspace's limitsFires when a fork would sit deeper below its root job than jobs.max_depth allows, or leave its root's tree holding more live jobs than jobs.max_live. The fork is refused; end a live job, or fork from higher in the tree. MGS3043: a job write path that claims too muchFires when a job write path spans more projects or files than the workspace's breadth thresholds allow, or opens with a leading `**`. The record is refused unless it narrows the path or waives the problem with a reason. MGS3044: a regenerated output outside the write pathsFires when a job's write paths cover sources whose generated outputs they do not cover, so regenerating them would write outside the job. The record is refused unless it adds the output or waives the problem with a reason. MGS3045: a ci gate over the write paths nothing runsFires when a ci target reads files inside a job's write paths and neither the job's check nor any of its goals runs it. The record is refused unless it adds a goal for the target or waives the problem with a reason. MGS3046: a workspace load file held in a shared checkoutFires when a job's write paths cover a magusfile, magus.yaml or spell source while another live job is working in the same checkout. The fork is refused; give the job its own worktree, or leave the file out of its write paths. MGS3051: a job store write from an older magusFires when a magus built from an older commit than the newest build that wrote the job store, or one that carries no commit, tries to write it. Nothing is written; run the command with the newer ./magus, or rebuild this one. Manual on purposeAutomate a repetition, never a rep; each act that forms judgment stays a person's keystroke. OpenCodeWiring magus into OpenCode (skills in .opencode/skills, the TypeScript plugin that carries the shell-command, file-write, MCP and subagent rules, the idle checkpoint, and the opt-in reply check). Quick startEverything you need to be productive with magus on one page (install, first target, the output flags, the agent skills and the guard hook), each linking to the page that goes deeper. Session load adaptersPer-host adapters that turn an agent host's own session log into the magus session event contract, so an audit can ask which skills loaded, whether the guard fired, and what ran unjudged. SkillA packaged set of instructions an agent host loads when a task matches its description: a directory holding a SKILL.md. magus ships its magus-* skills in the binary and writes them with magus agent install. SkillsInstalling the magus agent skills (where each host reads them, the short primary and its always-full twin, the AGENTS.md block magus prints but never writes, and the drift check that grades what is installed). The guardWhat magus session hook denies, what it only notes, and why: the five deny grounds, how a workspace sets a built-in rule, the file-write rules, the verdict contract a host wires into, and the observations magus records. The host wiring is yoursmagus owns the guard rules and the verdict; the part that knows your agent host is a template you copy and edit. The loop keeps you able to noticeWhat reaches a person is the deviation, the batch and the absence, never a confirmation of a pattern they already trust. The orchestrator plans, workers work, the integrator landsDelegated work has three roles; the orchestrator plans and coordinates, workers read, edit and check, and the integrator builds, regenerates and commits. The outer harness stays outsidemagus judges and informs, and never transforms what reaches the model; the host owns the loop. ToolAn action a model can call through its host: a name, a description, a typed input and a result. magus serves its tools over MCP, each a read of the workspace model or a run of the CLI it already has. Verdicts are provenance-blind; disposition is notNo gate conditions on who or what wrote a change; accepting, sending and landing one carries a true name. magus agentRender agent skills, adapt a user-owned harness, or review recurring guard feedback; it never writes the AGENTS.md you own. magus jobThe POSIX child lifecycle over delegated work: fork declares a job, exec takes the lease on it in this checkout, exit returns it with its result, wait verifies that result, and run submits one of the server's own jobs. magus sessionOne family over the repository's session store: list what magus invocations ran and the host session each ran in, list the blocks agents raised, close one by hand, and take the host-hook ingest that writes it all. magus-architecture-reviewGather architecture evidence from the magus knowledge graph (package imports, layers, symbol callers, churn, ownership) instead of reading files. magus-buzz-langWrite, fix and debug Buzz, the statically typed language of magusfile.buzz, spells and `magus buzz` scripts. magus-buzz-reviewReview Buzz code - a magusfile, a spell, or a standalone .buzz script - across three lenses run in parallel: idiom/style, skeptic/correctness, and upstream-Buzz conformance. magus-change-summarySummarize what changed in a magus workspace, write it up, or answer a granular diff question. magus-commit-compositionRestructure an UNPUSHED branch so each commit is one reviewable idea, using the workspace's own boundaries (project ownership, declared outputs, blast radius) rather than guessing from paths. magus-context-auditAudit the instructions an agent was given for statements that contradict each other or no longer match the tools. magus-diagramWrite, check and view an architecture figure with magus/figure, the embedded Buzz module. magus-multi-agentLoad BEFORE your first subagent spawn in a magus workspace: an Agent or Task tool call, a background worker, parallel workers, fanning out, or delegating part of a task. magus-queryQuery the magus knowledge graph to find and relate entities (projects, targets, spells, ops, charms, modules, diagnostics, docs). magus-runRun builds, tests, lints, and codegen through magus targets. magus-sdkHelp a Go developer consume magus as a library (import "github.com/egladman/magus") instead of shelling out to the CLI, and audit whether the SDK actually serves them. magus-test-designChoose unit, integration, or end-to-end test boundaries from the magus graph and runtime behavior. magus-upstream-docsTraverse magus's own documentation to answer a "how does magus do X / what does Y mean / where is Z documented" question, instead of guessing an answer or a URL. magus-upstream-sourceLast resort: read magus's OWN source code at the exact commit of the magus binary in use, to trace behavior its docs cannot explain. magus-vcs-hygieneSafe version-control operations in a magus workspace (any repo with magusfile.buzz at the root). magus-workspace-rulesAdapt magus's installed agent integration to THIS workspace without breaking it. magus\guard.commandRegister one Buzz function the agent guard calls on every agent shell command, to add a deny or an advisory from your repository's own rules. magus ships the seam and no rules. magus\guard.spawnRegister one Buzz function the agent guard calls on every subagent spawn and continuation, to add a deny or an advisory from your own rules. magus ships the seam and no rules.