Skip to content

Anthropic built Scion for itself. Carbon Forge is yours →

Carbon Forge
Menu

Carbon Forge + AEGIS

Agents propose. The record decides.

Carbon is the record a change is written to. AEGIS is the open-source orchestrator that runs the agents, tests and approvals around it. Together they cover the lifecycle from a request to a pushed release.

End to end

Seven steps, one record.

  1. 1

    Open a lane

    A task is opened as a lane; AEGIS agents write the work to it through Carbon’s MCP endpoint, so the record of the task outlives any run.

    Carbon Forge docs
  2. 2

    Agents write through MCP

    An execution token is a short-lived child token minted for a single AEGIS run: its writes are held to one lane and one tree path, and it lives at most one day.

    Carbon Forge docs
  3. 3

    Tests run on the lane’s tree

    A container step fetches the lane’s composed tree with trees.materialize, each entry by a signed URL, and runs the suite.

    Carbon Forge docs
  4. 4

    A person approves

    The approver reads lanes.diff and records lanes.approve with their own token, bound to the lane’s exact state.

    Carbon Forge docs
  5. 5

    The lane lands

    On approval a step calls lanes.land: every patch lands as one sealed changeset, or nothing lands and the conflicts are named.

    Carbon Forge docs
  6. 6

    The record tells the world

    The landing emits lane.landed to every signed webhook that names it, which can start the next AEGIS workflow.

    Carbon Forge docs
  7. 7

    Cut and publish to GitHub

    snapshots.cut names the state, cuts.notes lists what landed, and archives.push publishes the history and the tag to GitHub.

    Carbon Forge docs

Reach is declared

Every step holds only what its job needs.

Each step takes its own preset: scm_agent for the agents that write, scm_reader for the test step, scm_release for the release step.

Carbon Forge docs

An execution token is a short-lived child token minted for a single AEGIS run: its writes are held to one lane and one tree path, and it lives at most one day.

Carbon Forge docs

Why: an agent that is fooled or wrong can do no more than its step.

Carbon Forge docs
How AEGIS and Carbon line up
In AEGISIn Carbon
A human approval state holds the run until a person decidesA protected trunk holds every change on a lane until a caller lands it
The Forge lands fast-forward, never a merge, a rebase or a squashA landing replays exact patches and never merges text; the archive pushes fast-forward only
Agents are stateless; the orchestrator keeps the stateEvery write is on the server; lanes and history are the record of the work
A run’s log records each stepEvery landing carries its intent, sealed, and shows in blame, history and cut notes

Carbon Forge docs

What AEGIS brings

An orchestrator that treats agents as untrusted compute.

AEGIS is an open-source orchestrator for running autonomous AI agents in isolated, policy-enforced runtimes.

AEGIS docs

Agents run in a supervised loop: generate, validate, inject feedback, retry, with gradient-scored validation.

AEGIS docs

Workflows are durable state machines whose states are agent executions, system commands or human approval gates.

AEGIS docs

Container steps run any Docker image as a deterministic, isolated step inside a workflow.

AEGIS docs

A human approval state pauses the run until someone approves or rejects.

AEGIS docs

Agents never hold credentials: the orchestrator resolves secrets and enforces policy rules on every tool call, proxied through Ed25519-signed envelopes.

AEGIS docs

The SEAL Gateway puts policy, credentials and audit between automated clients and arbitrary upstream tools, with a signed envelope around every call.

AEGIS docs

Working with git workflows too

The Forge, AEGIS’s built-in git workflow, meets Carbon through the git archive and the GitHub import. Its change comes back into Carbon as a GitHub import onto a lane, or as a diff stored on a lane, and lands like any other.

Carbon Forge docs

How they connect

Every connection is one of Carbon’s general surfaces: the MCP endpoint, signed webhooks, the git archive and imports. A signed lane.landed webhook starts the next AEGIS workflow.

Carbon Forge docs

Pipelines from the record

By design, AEGIS pipelines, workflows and tasks run builds and tests from the Carbon record, through the SEAL gateway and its git tools: clone, commit, push, and a landing that waits for approval.

AEGIS docsAEGIS docs

Start with the record.