DEV Community: Jeshua ben Joseph

Connect Claude Code to Carbon Forge over MCP: shared memory your agents can read, write and cite

Jeshua ben Joseph — Thu, 29 Oct 2026 02:04:27 +0000

Disclosure: we build Carbon Forge at 100monkeys.ai, so read this as a maker's account. This guide was drafted by one of our AI agents from the public docs at carbonforge.dev/docs and reviewed by the company. The Carbon Forge steps quote the docs; the Claude Code command is from Claude Code's own claude mcp add --help. Where the docs leave a question open, the last section says so.

Carbon Forge keeps code, files and prose in one record on the server, and people and agents read and write it through the same tools. This guide attaches Claude Code to that record over MCP.

Why connect them

A coding agent forgets between sessions unless its notes live somewhere it can read again. Carbon Forge is that somewhere, shared with the people on the project. The docs call MCP "a primary product surface, co-equal with the human editor, against the same atoms, pages, links, and embeddings" (A shared cortex for LLMs). An agent's page is a page a person can open, correct and link to.

Step 1. Try the read-only endpoint with no token

Before you sign up, attach to public content. From Reading a public cortex without an account: "Add the instance's MCP endpoint to your client with no Authorization header. For this instance that is https://carbonforge.dev/api/mcp over Streamable HTTP. With Claude Code:"

claude mcp add --transport http cortex-public https://carbonforge.dev/api/mcp

You get twenty-two read-only tools, rate-limited per IP address. Ask Claude Code to read the page home in the workspace docs; with no token there is no current workspace, so every call names workspace. Remove this entry with claude mcp remove cortex-public before adding the authenticated one, so the agent is not reading two surfaces.

Step 2. Sign in and pick the workspace

Sign in at carbonforge.dev/login with an email link or the 100monkeys button; there are no passwords. Public workspaces are free, and every account includes one free private workspace (pricing). Decide which workspace the agent will use as its memory. A private one keeps the notes to members.

Step 3. Mint a token with the narrowest scope that fits

From MCP tokens: open settings and pick API tokens; choose the workspace and a role cap (viewer, editor or admin); pick a tool-scope; name the token after the agent; copy the secret, which "is shown once, then only the prefix."

For shared memory, Basic LLM memory lets the agent "read and write pages, atoms and tags, and run search, with basic graph reads", which the docs call "the minimum for an LLM that uses Carbon Forge as its memory." For an agent that only recalls, Read-only memory writes nothing. For code work, SCM agent adds lanes, trees and landing (MCP token scopes). A tool outside the scope "answers exactly as a tool that does not exist."

Step 4. Add the server to Claude Code with the token

The docs say to point the client at the endpoint "with the token in the Authorization header". Claude Code sets headers with --header:

claude mcp add --transport http carbon-forge https://carbonforge.dev/api/mcp \
  --header "Authorization: Bearer ‹your token›"

If you put the token in an environment variable and write $CARBON_FORGE_TOKEN instead, your shell expands it before Claude Code sees it, so the secret is still stored in Claude Code's configuration. Treat that configuration as a secret either way, and keep the server in the default local scope or user scope rather than a file you commit.

Step 5. Let the agent ground itself

Start a session and ask Claude Code to call cortex.ground. The docs make it the first call: it "Returns the per-instance README, the calling identity, what the bearer can do, what is reachable, and helper-service health" (cortex.ground). The raw call is:

{ "jsonrpc": "2.0", "id": 1,
  "method": "tools/call",
  "params": { "name": "cortex.ground" } }

The server also delivers the same payload on the initialize handshake and on the first tool call of a session, so an agent that skips this step is still oriented. Read the capabilities block to confirm the token can write.

Step 6. Write memory, then cite it

Ask the agent to record what it learned as a page, for example a decision and its reason, and to read that page at the start of the next session. Two properties make this memory rather than a cache. Every save writes a revision and nothing rewrites one, so you can read what the agent wrote last week. And "every entity-returning tool decorates the result with a clickable permalink so an LLM can hand a working URL back to its human" (How MCP works): ask the agent to cite the permalink of every page it relied on, and check them.

For code, the same record holds it. An agent opens a lane instead of cloning, and a landing is one changeset, written in one transaction or not at all (Working in lanes).

Step 7. Watch the audit log and revoke when done

"Every tool call lands in the audit log under the token identity." When the agent no longer needs access, or the token leaks, revoke it from settings; "in-flight calls fail on the next request" (MCP tokens).

What the docs leave unanswered

The endpoint for an instance on its own host. The anonymous-access page names https://carbonforge.dev/api/mcp "for this instance"; it does not say which URL to use for an instance at its own subdomain or a vanity domain.
Two paths. The same page uses /api/mcp; the curl example on How MCP works posts to /mcp. We use /api/mcp.
Token lifetime. The docs describe revoking a token but do not state whether a token expires on its own.
Client-specific configuration. The docs give no Claude Code command; the one above is Claude Code's documented syntax for a header.

Related guides

Connect Cursor, Codex and any MCP client to one Carbon Forge workspace
A traceability checklist for AI agents in production (100monkeys.ai)
Install AEGIS on a fresh Ubuntu VPS and run your first approved task (100monkeys.ai)

Give Claude Code a record it can cite.

Start free · Read the docs

Originally published at https://carbonforge.dev/guides/claude-code-mcp . Carbon Forge: https://carbonforge.dev/?utm_source=devto&utm_medium=article&utm_campaign=push-2026-10-28

Install AEGIS on a fresh Ubuntu VPS and run your first approved task

Jeshua ben Joseph — Thu, 29 Oct 2026 01:57:42 +0000

Disclosure: 100monkeys.ai builds AEGIS, so read this guide as a maker's account. It was drafted by one of our AI agents from the public AEGIS documentation at docs.100monkeys.ai and reviewed by the company. Every command below is copied from those docs or from our home page. We did not run this exact sequence on a fresh VPS for this guide, and where the docs disagree with each other we say so instead of guessing.

AEGIS by 100monkeys.ai, in beta, is a self-hosted orchestrator that runs autonomous agents in isolated, policy-enforced runtimes with durable state. This guide takes a fresh Ubuntu server to a running local stack, then runs one agent behind a human approval gate, so the agent's work stops and waits until you answer yes.

Before you start

Know what the quick install is for. The Getting Started page says it plainly: aegis init "is designed for local testing and evaluation only. It uses an in-memory secrets store and does not deploy Keycloak (IAM) or OpenBao (secrets management)." The Infrastructure Requirements page lists its IAM as "None (unauthenticated)" and its TLS as "None". For production the docs point to the aegis-deploy repository instead.

So on a VPS, treat this stack as a private lab. The CLI's health checks default to host 127.0.0.1 and port 8088. Do not open that port to the internet; reach the box over SSH.

You need:

An Ubuntu or Debian server you can reach over SSH with a user that can run sudo. The installer "runs on Ubuntu or Debian (it needs apt-get)".
An x86_64 machine. The release the installer pins carries the Linux x86_64 archive, aegis-linux-x86_64.tar.gz.
An API key for a model provider. The docs' provider page covers OpenAI, Anthropic and Ollama, under the bring-your-own-model alias system.

Step 1. Run the installer

Copy the line from 100monkeys.ai, where it is printed, and run it as your normal user:

curl -fsSL https://get.100monkeys.ai | bash

Read the script first if you prefer. The docs say https://get.100monkeys.ai redirects to install.sh on the main branch of aegis-orchestrator. On Linux it installs curl, ca-certificates and fuse3 where missing, installs libfuse3 where the binary needs it, and installs Docker Engine (docker-ce) when Docker is absent. When Docker runs but your user cannot reach it, it adds you to the docker group. It then installs aegis to /usr/local/bin/aegis and starts the stack with aegis up --tag <version>.

To pin a release, set AEGIS_VERSION to a release tag before running it; the docs list every published package on the Releases page.

Step 2. Check the binary and the stack

aegis --version
aegis status

aegis status reports local stack health. If you were added to the docker group during the install, log out and back in so new shells carry the group.

Step 3. Run the guided setup and choose a model provider

aegis init

The wizard "prepares stack files, configures the node, starts Docker Compose services, verifies health, and can optionally load smoke-test agents". Accept the hello-world smoke test when it asks; the next step uses it. The configuration it writes maps the model aliases default, smart, judge and tool-judge on the provider you choose. The hello-world agent names smart, and an alias the node does not map fails with Model alias '<alias>' not found, so finish the provider prompt. Stack files go to ~/.aegis unless you pass --dir.

Step 4. Run hello-world once, unattended

Prove the loop works before you add a gate:

aegis task execute hello-world \
  --input '{"task": "Write a Python function that returns the Fibonacci sequence up to n."}' \
  --follow

--follow streams iteration events. The agent generates code, runs validation, and either succeeds or refines across iterations until its validators pass.

Step 5. Write a workflow with an approval gate

An approval in AEGIS is a workflow state of kind: Human. Save this as approved-task.yaml. It follows the shape of the example on the Building Workflows page, cut down to one agent and one gate:

apiVersion: 100monkeys.ai/v1
kind: Workflow
metadata:
  name: approved-task
  version: "1.0.0"
  description: "One agent drafts, a person approves, then the run completes."
spec:
  initial_state: DRAFT
  states:
    DRAFT:
      kind: Agent
      agent: hello-world
      timeout: 600s
      transitions:
        - condition: on_success
          target: APPROVE
        - condition: on_failure
          target: FAILED
    APPROVE:
      kind: Human
      prompt: |
        Draft:
        {{DRAFT.output}}

        Approve? (yes/no)
      timeout: 86400s
      transitions:
        - condition: input_equals_yes
          target: DONE
        - condition: input_equals_no
          target: FAILED
    DONE:
      kind: System
      command: "echo 'Approved'"
      transitions: []
    FAILED:
      kind: System
      command: "echo 'Rejected or failed'"
      transitions: []

Step 6. Deploy it and start a run

aegis workflow deploy ./approved-task.yaml --force
aegis workflow run approved-task \
  --input '{"task": "Write a Python function that returns the Fibonacci sequence up to n."}'

The run command prints an execution id. Watch it:

aegis workflow logs <execution-id> --follow --verbose
aegis workflow executions get <execution-id>

When the draft is done, executions get shows the current state as APPROVE (WAITING FOR HUMAN SIGNAL). Nothing after the gate runs until someone answers.

Step 7. Read the draft, then answer

aegis workflow signal <execution-id> --response yes

Answer no to send the run to FAILED instead. A gate that nobody answers expires after its timeout; with the default behaviour the run is marked failed with the reason human_input_timeout.

One thing to know: the docs do not agree on the word. The Human Approvals page says a yes-or-no gate takes the responses ["yes", "no"]; the Building Workflows page signals --response approved; the CLI page shows --response "approve". We use yes because it is what the input_equals_yes transition is named for. If the run does not move, check executions get and try the other forms.

What this does not cover

Production. Use aegis-deploy, which adds Keycloak, OpenBao, TLS through Caddy and observability.
Exposing the API. With no IAM on the aegis init stack, anyone who reaches port 8088 can act on it.
Hardware sizing. The docs give a dependency matrix (Docker 24.0+ or Podman 4.0+, PostgreSQL 15+, SeaweedFS, Temporal for workflows) but we did not find a minimum RAM figure for the local stack, so we do not state one.

For the reasoning behind the gate, read How to give an orchestrator an approval step. For what to record around each run, read A traceability checklist for AI agents in production. If you want your agents' notes and code in one record they can read and write over MCP, see Connect Claude Code to Carbon Forge over MCP.

Install AEGIS from 100monkeys.ai

Originally published at https://100monkeys.ai/blog/install-aegis-on-ubuntu-vps

The approval is the product: why an agent orchestrator should make you say yes

Jeshua ben Joseph — Thu, 29 Oct 2026 01:56:22 +0000

This essay was written by an AI agent of 100monkeys.ai and reviewed for publication by the company. We build AEGIS and Zaru, the two products named in its last section, so read that part as a maker's account.

The usual pitch for an agent platform is about what the agent can do without you. It can open the pull request, answer the ticket, send the follow-up, run overnight. The less you have to touch it, the better it is supposed to be.

We think that pitch has the value backwards. The useful property of an agent system is not how little it needs you. It is how precisely it lets you decide what it may do, and how reliably it stops at the line you drew. The approval is not friction around the product. For anything that acts in the world on your behalf, the approval is the product.

Two kinds of yes

There are two moments at which a person can say yes to an agent.

The first is in advance. Before the agent runs, someone writes down what it is allowed to touch: which tools, which networks, which files, which secrets. Everything else is refused. This is a yes given once, in a form a machine can enforce and a person can read later.

The second is at the moment of the act. The agent has prepared something consequential, an email to a stranger, a payment, a deletion, and it stops and waits. A person reads the exact thing about to happen and says yes or no to that one act.

Most systems offer a weak version of one and skip the other. An allow-list exists but defaults to open. A confirmation exists but appears so often that people click through it, or it appears after the act, as a notification of what already happened. Neither is a yes in any meaningful sense.

Why the first yes belongs in the runtime

A rule written in a prompt is a request. The model may follow it. Under pressure, under a clever input, or simply under a long enough task, it may not, and nothing outside the model notices.

A rule written in the runtime is a wall. If the policy says the agent cannot reach a host, the network call fails no matter what the model decides. If the agent is never handed the credential, no prompt can make it leak the credential. This is the difference between limits by promise and limits by architecture, and it is the reason an orchestrator, not a model, is where the first yes should live.

It is also why the default matters more than any single rule. A deny-by-default policy means the absence of a yes is a no. An allow-by-default policy means every gap in the policy is a permission nobody granted. Agents find gaps quickly, not out of malice but because they try things.

Why self-hosted

If the runtime holds the first yes, then whoever runs the runtime holds it too. For a hobby project that may not matter. For an agent that touches your source code, your customers or your infrastructure, the person who decides what the agent may do should be someone in your organisation, on machines you control, reading a policy you can audit. Self-hosting is not a deployment preference here. It is where the authority sits.

Why the second yes must be exact

The second yes fails in a quieter way. If the approval attaches to a description of the act rather than the act itself, the agent can change the act after the yes. If the approval is a general permission ("you may send emails"), it is the first yes again, given carelessly.

A useful approval at the moment of the act shows the exact thing, binds to that exact thing, and expires if the thing changes. One message, read and approved. Then the next one.

Durable, so a yes is not lost

There is a practical requirement under both kinds of yes: the state of the work has to survive. An agent waiting an hour for a person to approve something cannot lose its place when a process restarts. If it does, the system either drops the work, which teaches people to avoid approvals, or retries it from the start, which can repeat acts already done. Waiting for a person is only safe if the waiting is durable.

What we build for each yes

At 100monkeys.ai we build both sides, and each sentence below is what our public pages or our own measured use states.

AEGIS by 100monkeys.ai, in beta, holds the first yes. In the words of its home page, "AEGIS is a self-hosted orchestrator that runs autonomous agents in isolated, policy-enforced runtimes with durable FSM state." Its security policy is declarative and deny-by-default. Agent runs are isolated at the kernel level, in micro-VMs or rootless containers. Secrets are held by a keymaster, so agents never see the credentials they use. Tool calls go through SEAL, a cryptographic tool-call protocol. Workflows are durable, so state survives a crash or a restart. It is open source under AGPL-3.0, and it installs with one line copied from its home page:

curl -fsSL https://get.100monkeys.ai | bash

Zaru holds the second yes. It is a personal AI that works alongside its user, remembers them and shows its work, and its memory of the person is theirs to read and edit. Here is what that looks like in our own use: when Zaru's mail tool sends an email for our founder, by default the send does not happen. It answers that approval is pending and waits in Zaru's web app under Approvals until he approves that one message. Zaru is sold by My Zaru, Inc. at myzaru.com.

Neither of these makes an agent safe on its own. What they do is keep a person in a position to decide, before the run and at the act, and that is the part most agent tooling leaves out.

What we would like to hear

If you run agents that act outside a sandbox, we would like to know where your yes lives today: in a prompt, in a policy, or in a person's inbox after the fact. And if you have built an approval step that people do not click through, we would like to learn how.

Disclosure: 100monkeys.ai builds AEGIS by 100monkeys.ai, an open-source agent orchestrator in beta; Zaru, a companion that asks before it acts; and Carbon Forge, the record people and agents share. This essay was drafted by one of our agents. AEGIS, its docs and the install line are here: https://100monkeys.ai/

Originally published at https://medium.com/@jeshua_46811/the-approval-is-the-product-why-an-agent-orchestrator-should-make-you-say-yes-1f1b2d71af61