ΛRC

What Arc does

Agent work doesn’t arrive one change at a time. One agent rewrites four files, a second runs the tests, a third starts on something that overlaps, and you review all of it in the same minute. Arc is built for that workload:

• Capture is continuous. A daemon snapshots every settled change, so no agent has to remember to save its work.
• Work is declared. An agent states its goal as an intent. Arc isolates the intent in a worktree and links every snapshot to it.
• Every intent ends in an outcome. Completed, merged or abandoned, with the agent’s own account of what happened. The record shows what was attempted as well as what shipped.
• Agents orient in one call. A new session asks for context and gets the active work, recent decisions and warnings back as structured data.
• MCP is the main interface. Every step is a tool call an agent makes itself.
• History answers questions. Agents and humans ask the substrate what changed, when and why, and Arc answers without anyone scraping logs.

JARVIS: “Target locked, sir. Creating branch fix/anti-missile-lock. Awaiting two peer approvals and a passing CI run before executing counter-fire.”

Stark: “We are literally falling out of the sky.”

Arc exists so your agent never files a pull request mid‑freefall.

How an agent uses Arc

Five steps, all over MCP. Each one also has a CLI equivalent.

Several agents can run this loop on one project at the same time. Each one gets its own worktree, and overlapping edits are resolved at merge with both intents’ rationale on hand. Small fixes that don’t need isolation can declare an inline intent against the base directory.

The arc-source-control skill, which arc init installs, teaches a fresh agent this loop without anyone explaining it.

Context: one call to orient

A new agent session knows nothing about your project. Without Arc, it reads back through history or waits for a human to explain. With Arc, it makes one call:

arc_context        # MCP, no arguments
arc context        # CLI

The response contains the active intent, recent changes and decisions, live worktrees, stale-state warnings, setup hints, and the next tools to call. If an intent is active, it also shows a grounds-currency verdict, which says whether the files the intent depends on have changed underneath it. Tools added in later releases show up in its hints.

Call it first in every session that will change the tree.

Intent: work as a checkable claim

An intent is more than a label for some edits. It can carry a type, the check that judges it, and the files it depends on.

Say how completion is judged.

arc intent declare "fix rate limiter" \
  --mode predicate --predicate "burst test stays under 100 req/s" \
  --grounds "src/limiter/**"

--mode is one of predicate (a stated check), judgment, absence or answer. Arc records the check with the intent; it does not run it. A claim with no check is allowed, but it never looks checked.

Declare its grounds, then check them. --grounds names the paths the claim rests on, and Arc records when they were attested. Later you can ask whether those paths still match what the claim assumed:

arc grounds-check "docs/design.md" "src/auth/**" --since 7d

Each path comes back as one of three verdicts:

• current: unchanged since the claim was made.
• drifted: changed since then, returned with the delta.
• vacuous: the pattern matches nothing Arc tracks. A check that bound nothing never reads as clean.

Exit codes: 0 current, 2 drifted, 3 vacuous, 1 error. Inside a worktree, the check judges both the worktree and base.

Replace without rewriting. --supersedes <id> records that a new intent replaces an old one. The old record stays as it was, and the link can be queried in both directions.

Close the loop. Every intent ends on the record: completed with its outcome, merged, or abandoned. Abandoned work stays inspectable and never reaches base. arc recap ranks open obligations above recent activity, so unfinished claims stay visible.

Together this works like a spec-driven loop. The claim is written before the work, its check and its grounds travel with it, and the closure is recorded. Arc keeps the record honest; your tests and reviewers still run the check.

Memory: the substrate remembers

What agents learn while working usually disappears when the session ends. In Arc it stays on record: every intent’s goal and outcome, every snapshot, every event. Later sessions read that record and don’t have to re-derive it.

• arc_context is the cold-start briefing (see above).
• arc recap answers “what happened” deterministically, straight from the substrate. No model is involved and nothing needs curating.

arc recap last-week                  # what shipped, grouped by intent
arc recap last-30d                   # a month at a glance
arc recap --path crates/arc-core     # one corner, and which functions changed

• Query surfaces (arc_query_activity, arc_query_changes, arc_query_timeline) answer “what was done, and when” as structured data.
• arc search searches the prose record: intent goals, outcomes, updates, events, and snapshot narration. It does not search file contents. An empty result tells you what it searched and what it didn’t.
• Narration (optional) adds a one-line, human-readable summary to each snapshot. Setup
• arc grounds-check catches memory rot. Point it at a design doc or note and the code it describes, and it tells you whether the world it was written in still exists.

Docs, stories, tasks and status are byproducts of intent. The usual wiki, task board, story and source become one record: the task is the intent you declared, and the story is generated from intents and snapshots. Because the narrative is read from the record on demand, it can’t drift from it.

Integrity: signed, content-addressed, append-only

A record many agents write to has to be one you can check without trusting each agent. Here is what Arc guarantees, and where the guarantee stops.

• Signed identities. Every actor, human or agent, has its own Ed25519 key. Records are signed by their author when they sync.
• Content-addressed storage. File contents are stored by BLAKE3 hash, and every snapshot records its parent. Identical content is stored once; a changed byte is a different object.
• Append-only history. Capture, merge and sync only add snapshots; none of them replaces an earlier one. Two declared operations change what history shows: purge, and masking a secret that was already captured. Neither renumbers a snapshot.
• Secrets scanned before storage. Every change is scanned before it is stored, and depending on your policy Arc blocks the snapshot or masks the matched bytes. Policy
• Verified on arrival. A receiving machine checks every record’s signature before accepting it, against the key it pinned the first time it saw that actor. After that first contact, a relay can’t forge or alter an actor’s records undetected. The first key is trusted on first use.
• No force-pushes or history rewrites. Sync only adds records; nothing overwrites history another machine already holds.
• Purge without rewriting. You declare content that should never have been captured. It disappears from history, diffs and materialize, and arc purge remote deletes it from the relay. Snapshot ids are not renumbered and stay valid, and every purge is itself an audit record. The machine you purge on keeps its local copy by design, as the backup. How purge works
• Not encrypted at the relay. Signing proves who wrote a record; it does not hide it. Whoever can read the relay’s storage can read your project, so use a relay you control or storage whose access you trust.
• Keys stay on your machine. Each signing key is a file under ~/.arc/keys/ that only your user can read (mode 0600).

What leaves your machine. Capture and history are local. Data goes out only through these paths:

• A relay you configure receives your snapshots and intents.
• Narration, which is off by default, sends each snapshot’s change context to the provider you choose.
• arc feedback posts your message to arc.daystra.com, with the Arc version, OS, architecture and a hashed machine id. Turn it off with --no-remote or arc config set feedback.remote false.
• arc update asks arc.daystra.com for the latest release when you run it.

---

Get started

C’mon, your agent will do this automatically, meatbag.

curl -fsSL https://arc.daystra.com/install.sh | sh
cd my-project
arc init        # starts capture and wires up your agent: MCP config, permissions, onboarding skill

Joining a project that already lives on a relay? arc clone /Volumes/backup/arc for a filesystem relay, or arc clone --bundle invite.json for R2.

In the docs

• Quick start — what arc init writes, first commands, joining a project.
• How capture works — snapshots, secret-safe capture, signing, the timeline.
• Many agents, one project — sessions, the daemon, host mode, launchd.
• Relay sync — off-machine copies, one-command clones, arc sync.
• Retroactive purge — remove leaked content without rewriting history.
• Narration — optional AI summaries, providers, key sources.
• Feedback, platforms and clients, and setup notes.

---

macOS (Apple Silicon) · Linux (x86_64, early) · MIT License · Built by humans and agents, tracked by Arc