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: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
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:
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
Eachmnemom 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 --:
mnemom agent prints is the command to resume
it, for example:
--agent, the command includes it.
mnemom agent show <name> prints the same command.
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:
--goal runs in implicit mode:
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:
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
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:~/.mnemom/launcher.toml:
Your governed agent
Everymnemom 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:
- 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;
- checks whether that agent is claimed. An agent that is already claimed is left where it is and never claimed again;
- 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 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-keyinstead.
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 hasautonomy_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 amnemom 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:
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.
--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.
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:conversationIdis the conversation the session runs under andagent_idis the governed agent’s id.mnemom agent showprints both. Add&org_id=<org id>when the agent is not in your primary organization.- The caller must be an
owneroradminof the agent’s organization, authenticated with a Bearer token or anX-Mnemom-Api-Keylike any other API call. An API key scoped to gateway traffic only is always refused, with403session_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_contracttool on the control-plane MCP server. It takes the same fields and follows the same rules.
contract-update.json:
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/enforcemode is kept unchanged. If you name a mode explicitly, that value wins instead. This includes namingnudgeto downgrade anenforcesession. - Time is counted from the first seal.
time_limit_smeasures from when the contract was first sealed, not from the update. Setting"time_limit_s": 3600on a session that has already run for two hours puts it over the ceiling at once. An update that resends atime_limit_sat or below the time already elapsed keeps the ceiling crossed. An update that omitstime_limit_sremoves the time ceiling entirely, because an update replaces the contract andtime_limit_shas no cell default to fall back to. To keep a time ceiling, resendtime_limit_son every update.
- 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).
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
429carriesx-should-retry: falseand noRetry-Afterheader, so SDK clients that retry a429on 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,MultiEditandNotebookEditare always writes, and their file path is always checked.Read,Grep,Glob,LS,WebFetch,WebSearchandTodoReadare always reads and are never checked against a fence. -
Inside a
Bashcall, the gateway reads these write forms out of the command text and checks their targets:- output redirects:
>,>>and>|; teeand the files it writes;- the destination of
cp,mvandinstall(the last operand, or the directory given with-t/--target-directory), and every directoryinstall -dcreates; - the destination of
rsync, which is always its last operand (forrsync,-tmeans “keep times”, not a target). Anrsyncto a remotehost:pathis not a local write and is not checked, andrsync -n,--dry-runor--list-onlywrites nothing.
&&,;and pipes, after acd(relative targets resolve against it), behind command wrappers (sudo,env,nice,nohup,time,exec,command, andxargswith a replace string such as-I,-i,--replaceor-J), and after a leading read such asgit 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. - output redirects:
-
Other write-shaped commands, such as
mkdir,touch,sed -i,lnor 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 earlierBashcommands in the session.~and$HOMEresolve only whenHOMEis 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 filexargsappends 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
violationverdict. The allowed-path check applies only when the contract has at least one--allowrule. 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.
- 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.
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.--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.
--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 undermnemom 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.
Related
- Sign-in options — subscription, API key or Anthropic Console
- Savings estimates — the first-run savings screen and the in-session counter
- CLI reference — the full
mnemomcommand surface - Agent claim flow
- Conscience values and org card templates