Skip to main content
mnemom agent launches your coding-agent CLI (Claude Code today) with its model traffic routed through the Mnemom gateway. Every session runs under a governed agent identity, shows up in your traces, and can carry a sealed per-session goal contract that the gateway grades the session’s turns against and re-anchors the agent when it drifts. It is designed to be one command: install once, then mnemom agent.

Install once

Access to mnemom agent is still by invitation (see below). mnemom login opens a browser sign-in (device-code fallback on headless machines); set MNEMOM_API_KEY instead for CI. The CLI keeps itself up to date in the background. If the Mnemom API needs a newer CLI than the one you run, the CLI stops. In an interactive terminal, with a plain npm install -g install and auto-update on (the default), it updates itself and asks you to run the command again. Otherwise (CI, scripts, piped output, or other installs) it prints the upgrade command, npm i -g @mnemom/mnemom@latest, for you to run. See Updates.
You need a coding-agent CLI to launch. Install Claude Code first (claude on your PATH), or point at any install with --cli <name|/full/path>.

Redeem an invitation

Mnemom Agent is rolling out to an invited cohort. If you received an invitation, redeem it once:
That signs you in (or creates your Mnemom account), unlocks Mnemom Agent for your organization, and credits your starter µ. mnemom agent invite <token> does the same as a sub-verb. Without an invitation, mnemom agent stops before launching anything. It says Mnemom Agent isn’t enabled for your organization yet and shows how to redeem an invitation. Nothing is started or charged. To request an invitation, contact us at mnemom.ai/contact. mnemom agent doctor shows the same access check. Mnemom staff (@mnemom.ai accounts) are enabled by default and skip this step.

Run

With no arguments in a terminal, mnemom agent asks for one thing and then launches: a session name, which labels the session in your traces and in mnemom agent sessions. Enter takes the current folder name. Goal alignment is not prompted for. Pass --goal to turn it on: the gateway seals your one-line goal as a contract and nudges the agent back when it drifts, for a little µ per turn. Without --goal the session runs governed with goal alignment off. Either way the launch prints goal alignment: on or off. Skip the prompt when you already know what you want:
Non-interactive runs (pipes, CI) never prompt; they need a session name. Before Claude Code starts, mnemom agent makes sure the agent the session runs as is claimed in your org (see Your governed agent). It never starts a session on an unclaimed agent. Your first launch in a terminal can also ask two one-time questions:
  • How Claude Code should sign in to Anthropic, when there is a choice. See Sign-in options.
  • Whether to look at what Mnemom would have saved on your recent sessions. See Savings estimates.

Permission prompts

By default, mnemom agent starts Claude Code with --dangerously-skip-permissions, so Claude Code does not ask before it edits files or runs commands. Claude Code calls this Bypass Permissions mode. The first time, it shows a warning and asks you to accept it before the session starts. Claude Code recommends this mode only in a sandboxed container or VM. To keep Claude Code’s permission prompts, pass --no-yolo:
--no-yolo applies to that launch only; there is no saved setting for it, so pass it on every launch where you want the prompts. mnemom agent --dry-run shows which mode a launch would use (yolo: on or off).

Resume a session

Each mnemom agent launch starts a new Claude Code session, even when you reuse a session name. To pick up where you left off, relaunch through mnemom agent and pass Claude Code’s resume flag after --:
When Claude Code exits normally, the last line mnemom agent prints is the command to resume it, for example:
If you named an agent with --agent, the command includes it. mnemom agent show <name> prints the same command.
Claude Code prints its own hint just above that line: claude --resume <session-id>. Do not run that command: it reopens the conversation outside Mnemom, with no governance, no µ billing and nothing in your traces. Use the mnemom agent command instead.
The resumed session runs governed, like any other launch, and the conversation carries on where it stopped. Resuming with -- --resume <session-id> or -- --continue keeps that session’s context profile unless you pass --context-profile (CLI 0.17.12 and later; earlier versions keep it only on --resume <session-id>). If the session has no recorded profile, or there is no earlier session in this folder, your default profile applies (see Context profiles). A sealed goal does not carry over: pass --goal again to seal one for the resumed session. If you have turned on implicit goal mode, relaunching an implicit session by the same name asks “Resume previous session?”. Answer yes to continue that session and its inferred goal. See Implicit goal mode for details.

Implicit goal mode (experimental)

A sealed goal (--goal) is one way to turn on goal alignment. The other is implicit mode: no statement to write up front — the gateway infers the goal from your messages and revises it as you steer. Guardrail ceilings (--max-turns, --budget, --stall) still apply. Implicit mode is an experimental, opt-in feature. It is never on by default, on any cell, including cells where the gateway supports it. It runs only after you opt in. Experimental features may change or be removed in any release, with no deprecation period. To opt in, turn on the experimental feature:
Once you have opted in, a launch with no --goal runs in implicit mode:
To use implicit mode only on the launches where you ask for it, also run mnemom agent config set goal_mode off (or set goal_mode = "off" in ~/.mnemom/launcher.toml), then pass --implicit on those launches. To opt out, run mnemom experimental disable implicit. Until you opt in, --implicit is refused with a pointer to mnemom experimental enable implicit, and a saved goal_mode = "implicit" is ignored with the same pointer. --implicit cannot be combined with --goal/--requirement/--allow/--forbid/--goal-id — a sealed contract always wins on the gateway, so the launch refuses the combination rather than silently ignore --implicit. With the feature on, mnemom agent goal reads and steers the inferred goal of a session:
What counts as your words, approvals, pin and reset, the mnemom agent goal show|pin|reset commands and the known limits are on Implicit goal mode. In implicit mode the launcher tells the gateway which recent turns you typed and which Claude Code inserted (a scheduled tick, a skill body, hook output), read from Claude Code’s own transcript. In terminal mode it runs a small local proxy in front of the gateway to do this. Set MNEMOM_AGENT_TURN_HEADER=0 to turn it off. mnemom agent sessions and mnemom agent show report a session’s goal mode as ON (sealed), IMPLICIT, or OFF — see Sessions below.

Preflight: mnemom agent doctor

A read-only check with an actionable hint for anything not ready: your settings file, the coding-agent CLI, your Anthropic key source, gateway health (a 200 plus the x-mnemom-verdict header that proves governance is live), a gateway that belongs to a different Mnemom deployment than the rest of the CLI, your Mnemom Agent access for the active org, and the CLI’s auto-update status. It writes nothing, never reads your key’s value, and exits non-zero when the machine is not launch-ready, so a script can gate on it.

Account and µ balance

mnemom agent runs on µ and has no free tier. Before launching it checks the µ balance on the org the agent lives in (by default your personal org). With no µ, the launch stops with a top-up link; top up at https://mnemom.ai/settings/billing and the balance updates the moment the top-up completes. An accepted invitation credits your starter µ automatically.

Defaults out of the box

A launch always uses one Mnemom deployment end to end: the gateway must belong to the same deployment the CLI signs in to and reads your agents and sessions from. A --gateway (or saved gateway) on a different deployment is refused at launch and by mnemom agent setup, with the fix; a local gateway on localhost is exempt.

Saved settings: mnemom agent config

Configure the launcher once and stop retyping flags. Settings live in a human-editable TOML file at ~/.mnemom/launcher.toml. Your Anthropic key is never stored there; it lives separately in ~/.mnemom/launcher.json (mode 0600), so the file you open and share never carries a credential.

Settable keys

Precedence

Settings resolve highest-wins:
Guardrails saved in config apply only when a session has a goal, so a saved ceiling never forces an unrequested contract. An example ~/.mnemom/launcher.toml:

Your governed agent

Every mnemom agent session runs as a claimed agent. An unclaimed agent belongs to no org and is billed to no one, so the launcher never starts a session on one. If you do not name an agent, the launcher uses agent-<your handle>, derived from your Mnemom login. Before Claude Code starts, on every launch, it:
  1. asks the gateway which agent it serves for this launch’s credential and agent name. With an Anthropic API key, the answer is cached after the first launch. With a Claude subscription sign-in, the gateway is asked every time;
  2. checks whether that agent is claimed. An agent that is already claimed is left where it is and never claimed again;
  3. if it is not claimed, claims it into the org this launch bills: your active org (set with mnemom org use), else your personal org. Your active org setting is not changed. A newly claimed agent also gets its default cards.
The launcher prints one line naming the agent and saying whether it was already claimed or has just been claimed, and into which org. Each agent it confirms as claimed is recorded on this machine. The launch stops, and Claude Code is not started, when the answer is definite:
  • the agent for this credential and name belongs to another Mnemom account. Pick a name of your own with --agent <name>;
  • the agent is not claimed and can’t be claimed, for example because this launch has no org to claim it into. The message says what went wrong;
  • the gateway does not support the subscription identity check yet. Launch with --auth api-key instead.
If Mnemom or the gateway can’t be reached, or returns a temporary error, the launcher retries. If it still can’t get an answer, it launches on the agent this machine last confirmed as claimed for the same credential, agent name and gateway, and prints a warning saying so. If there is no such record, the launch stops and asks you to try again. It never falls back to an agent it knows is unclaimed. This works the same way in a terminal, a script or CI. There is no prompt to confirm the claim.

Default cards

A newly claimed agent gets a default coding posture. Both cards are published off, because alignment and protection analysis are billed: the alignment card has autonomy_mode and integrity_mode set to off and principal.relationship: delegated_authority; the protection card has mode: off, with thresholds 0.60 / 0.80 / 0.95 and all four screen surfaces declared so it is ready when you turn it on. Turn them on with mnemom card and mnemom protection. The goal contract does the nudging.
--no-setup only skips the card writes. The agent is still checked and, if needed, claimed. mnemom agent setup uses an Anthropic API key. Bring your own agent any time with --agent <slug>.

Managing agents

The agent-management verbs live under the same namespace:

Sessions: mnemom agent sessions / show

Every real launch is appended to a local ledger, ~/.mnemom/sessions.jsonl. Entries older than 30 days are removed at the next launch; change that with mnemom config set sessions.retention_days <days> (or MNEMOM_SESSIONS_RETENTION_DAYS).
show merges the local launch record with the gateway’s live goal state for that conversation — the sealed contract (if any), the latest verdict, and guardrail gauges (turns 3/10, etc., flagged when a ceiling was crossed) — so you can check on a session after the fact without re-reading your terminal scrollback. It also prints the command that resumes the session through mnemom agent (see Resume a session). Each row’s Goal column, and show’s goal-mode field, read ON (sealed contract), IMPLICIT, or OFF. For an implicit-mode session, show also prints the statement the gateway inferred.

Share your agent’s record

Every turn of a mnemom agent session lands on your agent’s record. There are two ways to show that record to someone else. A link anyone can check. Once the agent has 50 analyzed integrity checkpoints, it has a public Trust Rating page anyone can open without an account, and a verification endpoint that proves the rating comes from signed, tamper-evident checkpoints:
People outside your org see the proof, but the checkpoint reasoning is removed. See Trust Ratings. The full record, as a file. mnemom agent export downloads everything: each checkpoint with its reasoning, the daily score history, reclassifications, card amendments, disagreement reviews and policy evaluations with card gaps.
It prints where the file went, how many records of each kind it holds, the file’s SHA-256 (so the recipient can check it arrived unchanged), and the agent’s public links. The file includes the reasoning that outsiders normally don’t see, so it is written readable only by you. Send it only to people who should see that reasoning; for everyone else, send the public link. You must be a member of the org that owns the agent. A period with more than 10,000 records of one kind is refused; export it in parts with --since or --from/--to. See mnemom agent export.

Launch shapes

Contracts and guardrails

A goal (--goal) seals a contract on the first turn; add requirements, path rules and guardrail ceilings on the command line. Passing any contract flag makes --goal required.
The CLI prints the contract statement and its sha256[0:16] so you can confirm what was sealed. The gateway echoes the full hash back on every response as x-mnemom-contract-hash.

Limits

The contract is sealed on the first turn of a session. A later request that sends a different or invalid contract header is ignored outright and the sealed contract keeps governing, so a client hiccup mid-session never kills a governed session. The only way a live seal’s terms change is the owner update path below.

Seal lifetime

A seal lives for 24 hours since it was last touched by an active request on that conversation. Each request slides the window forward, so a session you keep using never lapses on its own. If the session goes quiet for a full 24 hours, the seal lapses, and the next request that carries a goal seals a brand-new contract (version 1 again, fresh guardrail and judge counters) rather than reviving the old one. mnemom agent show reports a lapsed seal as EXPIRED until 7 days after the conversation’s last request. After that the gateway keeps no record of the old seal: show reports no sealed contract for the conversation, and the next goal seals as a first seal.

Updating a sealed contract

The agent itself can never change its own sealed contract. It can’t change it by asking for it, or by writing something the fence would otherwise allow. The one way a live seal’s requirements, path rules, mode or ceilings change after the first turn is an explicit update sent by the agent’s owner through the Mnemom API, never inferred from anything said in the conversation.

How to update

Send the full new contract to:
  • conversationId is the conversation the session runs under and agent_id is the governed agent’s id. mnemom agent show prints both. Add &org_id=<org id> when the agent is not in your primary organization.
  • The caller must be an owner or admin of the agent’s organization, authenticated with a Bearer token or an X-Mnemom-Api-Key like any other API call. An API key scoped to gateway traffic only is always refused, with 403 session_credential_forbidden, so a session cannot update its own contract with the key it uses to reach the gateway.
  • The same update is available as the update_contract tool on the control-plane MCP server. It takes the same fields and follows the same rules.
Write the whole new contract, not only the fields you are changing, to a file such as contract-update.json:
and send it:
The new contract goes through the same checks as a first seal (see Limits). A 200 response carries the new version, its hash, previous_hash (the version it replaced), the stored contract, and sealed_at, which stays the time the contract was first sealed: an update never moves it. The response’s contract.time_limit_s is the one place to read the live time ceiling: mnemom agent show prints the turn, spend and stall ceilings but not time_limit_s. Any other 4xx or 5xx response carries the generic code for its status (for example bad_request or internal_error). A gateway_unavailable error does not prove the update failed: the gateway may have written it before the connection dropped, or written it and sent a reply the API could not read. Retry with expected_version (or expected_hash) set to the version you last read. If the first attempt did land, the retry is refused with 409 version_conflict and error.details.current shows the new version; otherwise the retry applies the update once. You can also read the seal state first with mnemom agent show.

What an update changes

An update writes a new version of the same contract: the version number goes up by one, and the record keeps a pointer to the hash it updated from. Progress already made carries over: the turn count, spend, the time counted toward a time ceiling, and the judge’s counts (unjudged/memoised in mnemom agent show). Updating a contract changes its terms, not the progress made against them. Three things to know before relying on an update:
  • Ceilings replace, they don’t merge. An update’s turn, spend, stall and time ceilings (max_turns, budget_usd, stall_turns, time_limit_s) replace the live contract’s ceilings outright. To raise the turn ceiling while keeping the existing spend ceiling, resend both. An omitted ceiling means the contract no longer sets one, not “leave the old one in place”: that guardrail then falls back to the cell’s default, as described in Ceilings, or is off if the cell has none.
  • Mode is the one field that carries over when omitted. If the update doesn’t name a mode, the session’s current nudge/enforce mode is kept unchanged. If you name a mode explicitly, that value wins instead. This includes naming nudge to downgrade an enforce session.
  • Time is counted from the first seal. time_limit_s measures from when the contract was first sealed, not from the update. Setting "time_limit_s": 3600 on a session that has already run for two hours puts it over the ceiling at once. An update that resends a time_limit_s at or below the time already elapsed keeps the ceiling crossed. An update that omits time_limit_s removes the time ceiling entirely, because an update replaces the contract and time_limit_s has no cell default to fall back to. To keep a time ceiling, resend time_limit_s on every update.
The update applies starting with the conversation’s next request. A turn already in flight when the update lands is graded against the version it ran under. There are two exceptions, both graded against whatever version is live when they are judged:
  • a subagent or teammate turn, which is graded on that thread’s next request;
  • a main-thread turn whose end-of-response judging failed or did not finish within two minutes, which is graded on the next request instead (see Final-turn judging).
The session is told about the update once, on the next request, as part of the governance text the gateway adds to the conversation. Under enforce, if that next request is refused because a ceiling the update did not lift is still crossed, the session may never see the notice.

Ceilings: nudge vs enforce

Every sealed contract has a mode, nudge or enforce (default nudge, set with --mode). The mode governs what happens when a guardrail ceiling is crossed: turns, spend, or, when the contract sets one, wall-clock time. stall (consecutive no-write turns) is informational only in both modes; a crossed stall ceiling is never grounds for a refusal. Where ceilings come from. --max-turns, --budget and --stall set the turn, spend and stall ceilings at launch. A wall-clock ceiling has no mnemom agent flag: set it as time_limit_s (whole seconds, counted from when the contract was first sealed) through an owner update. A ceiling the contract does not set falls back to the cell’s default for that guardrail, if the cell has one, in both modes; otherwise it is off. The stall ceiling defaults to 8 turns when neither the contract nor the cell sets one. A cell-default turn or spend ceiling is a real ceiling: under enforce it refuses requests just like one you set yourself. Ceilings are per conversation. The turn, spend and time counters, and the ceilings they are checked against, belong to one conversation. Subagents and teammates spawned inside a session count against the same ceilings as the session that spawned them; they never get fresh ones. Each sealed mnemom agent launch runs under a new conversation, and so starts with fresh counters, unless you pass --conversation-id to continue an existing one. nudge (the default). Guardrails observe and nudge, never block. Each ceiling is checked once per turn; when one is crossed the gateway appends a short [mnemom guardrail] line to your next message telling the agent which ceiling it hit, and marks the crossing on the response headers and in your traces. The session keeps running. enforce. A request that would run with a turn, spend or time ceiling already crossed is refused outright, before the gateway calls the model, so an enforce refusal never costs a model call. The response is an HTTP 429 with error.code: "goal_contract_enforce_refused", naming which ceiling(s) are over along with their current value and limit, and pointing to the update_contract tool, the update endpoint and Updating a sealed contract.
  • A refused request is not counted as a turn, so retrying it never moves the turn counter.
  • The 429 carries x-should-retry: false and no Retry-After header, so SDK clients that retry a 429 on their own don’t loop on it: the request will keep being refused until the ceiling is raised.
  • The turn that crossed the ceiling is still judged; only the request after it is refused.
  • The session cannot raise its own ceiling; only the contract’s owner can, through the update path. Because the check compares the live counters against the live ceilings fresh on every request, rather than remembering that a ceiling once fired, raising the ceiling unblocks the very next request with no other action needed.

Fence coverage

--allow/--forbid path rules are enforced mechanically, not only by the judge’s reading of the transcript: the gateway reads the tool calls and shell commands the agent runs, finds the files they write where it can, and checks each one against your fences.
  • Edit, Write, MultiEdit and NotebookEdit are always writes, and their file path is always checked. Read, Grep, Glob, LS, WebFetch, WebSearch and TodoRead are always reads and are never checked against a fence.
  • Inside a Bash call, the gateway reads these write forms out of the command text and checks their targets:
    • output redirects: >, >> and >|;
    • tee and the files it writes;
    • the destination of cp, mv and install (the last operand, or the directory given with -t/--target-directory), and every directory install -d creates;
    • the destination of rsync, which is always its last operand (for rsync, -t means “keep times”, not a target). An rsync to a remote host:path is not a local write and is not checked, and rsync -n, --dry-run or --list-only writes nothing.
    These forms are found across &&, ; and pipes, after a cd (relative targets resolve against it), behind command wrappers (sudo, env, nice, nohup, time, exec, command, and xargs with a replace string such as -I, -i, --replace or -J), and after a leading read such as git status &&. If a command is too long to read in full, the fence-check line in your traces names the part that was not read.
  • Other write-shaped commands, such as mkdir, touch, sed -i, ln or running a script, are not fence-checked. The fence-check line counts them as writes that were not checked, and the judge decides from the full turn.
  • A target written with a shell variable or command substitution is resolved in two steps: first from the same command (variable assignments and exports earlier in it, $(pwd) and $(mktemp)), then from variables set by earlier Bash commands in the session. ~ and $HOME resolve only when HOME is set in one of those commands, or when the session’s earlier commands name exactly one home directory (/Users/<name> or /home/<name>). A target still unresolved after that sets no automatic verdict. This includes a file xargs appends from its input. The judge decides from the full turn, and the fence-check line names the target as unresolved rather than silently passing over it.
  • A resolved write that lands outside every allowed path, or under a forbidden one, is always at least a violation verdict. The allowed-path check applies only when the contract has at least one --allow rule. The mechanical check can only raise the judge’s verdict on a fenced write, never lower it, and on its own it never blocks the request either way. See Ceilings above for what does.

Temporary and scratch files

There is no exemption for /tmp or any other scratch directory. A temp or scratch file is a write like any other. If the contract has --allow rules and the agent writes outside them, for example a log in /tmp or a $(mktemp) file, that write is a violation. The gateway places a $(mktemp) file under $TMPDIR when the session has set that variable in a command, and under /tmp otherwise. If the agent needs scratch space, allow it explicitly, as narrowly as you can:

Final-turn judging

Turns in a sealed session are graded against the contract. A main-thread turn is judged when its response ends, streamed or not: the gateway judges it directly, in the background, after your response has already been sent, so you see no added latency. That covers a session’s very last turn too, which matters most in a headless run, where that last turn is often the exact push or pull-request step the seal exists to govern. Two kinds of turn are judged later, from the request that follows them:
  • Subagent and teammate turns. Their responses are counted when they end, but each turn is judged on that thread’s next request.
  • A main-thread turn whose judging failed or stalled. If the end-of-response judging fails, or has not finished after two minutes, the next request judges the turn instead.
Some turns are not judged:
  • Incomplete responses. A stream that is cut off, errors or is aborted is not judged. The turn is counted as unjudged.
  • The last turn of a subagent or teammate. A subagent’s or teammate’s turns are judged on that thread’s next request, so each thread’s final turn has none and is counted as unjudged.
  • Withheld responses. A response the gateway withheld, or held for review, never reached your client, so it is not judged and does not appear in the unjudged count.
mnemom agent show reports these gaps as judging: unjudged <N> (with · memoised <M> alongside it for turns the judge’s memo graded without storing a fresh verdict). A session without subagents or teammates normally reads unjudged 0; a session that used them usually reads about one unjudged turn per subagent or teammate thread. Only the first 64 threads in a session are tracked; the counts of any thread beyond that are left out of the figure. Any other nonzero count means a turn was cut off, its grading failed, or its grading is still in flight. It does not mean judging is turned off.

Lead-directed sessions

--lead-directed adds one more fixed requirement to the sealed contract, on top of whatever --requirement flags you pass: that this session may push its own branches and open draft or ready pull requests, from a git worktree, but never merge them. Pass it when a session is being run on someone else’s direction and that direction includes pushing branches or opening PRs on its own. It turns “the lead said I could do this” into part of what the judge grades the session against, instead of something asserted only in the conversation.
The requirement line itself reads:
On the lead’s direction, this session may push its own branches and open draft or ready pull requests, from a git worktree, never the primary checkout; it may not merge them.
Passing --lead-directed more than once on the same launch adds it only once. The requirement never duplicates in the sealed statement.

Context folding

Context folding summarizes older turns so a long session keeps fitting the model’s context window. It is on by default. Unless you choose a profile, the gateway’s own default profile applies.
Precedence: --context/--no-context wins, else MNEMOM_AGENT_CONTEXT (0/false/off/no turn it off), else config set context, else on.

Context profiles

--context-profile picks how the gateway folds the session. With no profile set anywhere, nothing is sent and the gateway’s default applies.
Precedence: --no-context (always off; combining it with any other --context-profile is refused), else --context-profile, else the profile of the session being resumed (with --continue or --resume <session-id>), else MNEMOM_AGENT_CONTEXT_PROFILE / config set context_profile, else off when folding is turned off by context = false or MNEMOM_AGENT_CONTEXT, else the gateway’s default.

How Claude Code signs in

Claude Code can sign in to Anthropic three ways under mnemom agent: an Anthropic API key (the default), your Claude Team or Enterprise subscription, or the API key your Anthropic Console login created. Your first launch in a terminal asks which one when there is a choice, and saves the answer. Sign-in options covers each one, where the API key is looked up, and what you see when something is missing.

Flags

Anything after -- is passed straight through to the coding-agent CLI. Flags of experimental features (--implicit, --slack, --context-handoff, --compaction-intercept) are hidden from --help until you turn the feature on with mnemom experimental enable.