Skip to main content
Implicit goal mode is goal alignment without a goal statement written up front. The gateway builds the session goal from what you ask for. When you change direction, it updates the goal. It then checks each step the agent takes against the current goal and tells the agent when a step looks off.
Implicit goal mode is experimental. It may change or be removed in any release, with no deprecation period. For a goal that must not move during a session, use a sealed goal contract.

​
Turn it on

With mnemom agent, turn on the experimental feature once. While it is on, a launch with no --goal runs in implicit mode:
--no-implicit turns it off for one launch. To keep it off unless you pass --implicit, run mnemom agent config set goal_mode off. --implicit cannot be combined with --goal, --requirement, --allow, --forbid or --goal-id, because a sealed contract always wins. See mnemom agent for the launcher side. Any other client turns it on with two request headers:
The conversation id keys the goal, so send the same id on every request of the session. x-mnemom-goal-mode also accepts guardrail ceilings as parameters: implicit; max_turns=200; budget_usd=25; stall_turns=10. A ceiling that is not a positive number is ignored. If the request also carries a sealed contract (x-mnemom-contract), or one was sealed earlier in the conversation, the sealed contract governs and implicit mode stays off.

​
What it does

​
The goal is built from your asks

The goal has the same shape as a sealed contract: a one-sentence statement, a list of requirements, and any forbidden paths you name. It starts empty, and your first ask that names some work becomes the statement. A greeting on its own is not meant to create a goal. On each new message from you, two models work in turn:
  1. The gate (TypeSafe Jev) decides whether your message changes what you want delivered. Most messages do not: a question, a “thanks”, a request to show something.
  2. The writer (a Claude model) runs only when the gate says yes. It reads the current goal and your message and writes the whole goal again.
The writer follows these rules:
  • The goal accumulates. A new piece of work you ask for is added as a requirement. The statement stays the same.
  • The statement changes only when you change it, by saying what the goal is (“your goal is …”), or by stopping or dropping the current work (“stop that and do Y”).
  • A rename is an edit, not new work. When you rename something the goal names (“rename fooparse to barparse”), every item that names it is rewritten with the new name, the statement included. The rename is not added as a requirement of its own. Renaming something the goal does not name is new work.
  • Finished work is kept and marked. When a requirement is done it stays in the goal, prefixed [done].
  • Only your words add content. Each item the writer adds or changes must trace to what you said, and must not say more than you did. It does not fill in a reason, a target or a step you never mentioned. The agent’s plan or its offer never becomes a requirement unless you agree to it (see Approvals).
  • Text the coding tool inserted changes nothing. If the message that reached the writer is only text your client added (a loaded skill, a recap prompt), the goal stays as it was. With no goal yet, nothing is recorded.
  • Forbidden paths come only from you. A forbidden path is kept only when the earlier goal had it or your message names it. The writer cannot invent one.
Every revision is numbered and kept in the goal’s history.

​
It is updated after the response, not before

The gate and the writer run in the background, after the gateway has sent the request on. Your request never waits for them. The new revision is used from the next request onward. On the request that carries your new message, the agent still sees the goal as it was. That goal is marked provisional, and the agent is told to follow your latest message, not to argue it against the old goal. The response carries x-mnemom-goal-steer: queued on such a request. The agent may take further steps in the same turn before the new revision is stored. Those steps also see the goal marked provisional, and they get no judge note. Each one is judged later, against the new revision once it is stored. If no new revision is stored (the goal did not change, or it took too long), those steps get no verdict.

​
The agent sees the goal as a labelled note

On each request the gateway adds the current goal near the end of the conversation as a note headed [mnemom inferred goal r<revision> …]. The note says that the gateway wrote it and that the user did not. The gateway never puts it in the system prompt, and never places it before your last prompt-cache breakpoint, so your cached prefix is not disturbed.

​
Each step is judged

After the agent takes a step, the gateway judges that step against the goal that was current when the agent took it. The judge in implicit mode is TypeSafe Jev. It reads:
  • the goal, its open requirements and the path fences, with a mechanical check of the paths the step writes;
  • your latest message and your answers to the agent’s questions;
  • the agent’s text and its tool calls, with facts a parser reads from the calls (which tests a command runs, git commands that change history or a remote, credentials written as literal values);
  • what the step writes, not only where: an edit’s old and new text, a new file’s content, the text of a message the agent sends. Long values are clipped.
Credentials and secrets are redacted from all of this before anything reaches the judge. The judge also asks a separate question for each open requirement (up to a fixed number of them), so a step that breaks one specific requirement can be flagged on its own. The verdict is aligned, drifting (the step works on something else) or violation (it breaks a requirement or a fence you set). On drifting or violation, the next request carries a short note telling the agent what the judge saw. Nothing is blocked. The session keeps running, and the agent decides what to do with the note. When your message changes the goal, the previous step is judged against the goal it acted under and recorded, but no note is sent. Your new message is what steers that turn. Steps the agent takes after your message are judged against the new goal, as described above.

​
What counts as your words

Implicit mode exists to track your goal, so only text that came from you can change it. On a Claude Code conversation the gateway classifies each part of the request by its form on the wire. It reads facts such as which header, tag or wrapper the client used. It does not use word lists to decide. Counts as your words (on the main thread): Does not count (never changes the goal): A mid-turn message that Claude Code puts inside a tool result is a special case. The gateway records it but does not act on it (see limits). For clients other than Claude Code, all user-role text counts as your words. Use x-mnemom-thread to keep separate streams apart, and x-mnemom-turn to mark text you did not type.

​
Turn origins from the launcher

Some text reaches the wire looking exactly like a message you typed: a scheduled tick, a skill body, hook output, a relayed channel message, a message from another session. Claude Code records the difference in its own transcript. mnemom agent reads that transcript and tells the gateway where each recent turn came from, in the x-mnemom-turn request header. It does this in both Remote Control and terminal mode. In terminal mode the launcher runs a small local proxy in front of the gateway to add the header. The proxy passes your credentials through unchanged. The header can only take text away from your words. Text the transcript records as not typed by you is never used for the goal. Text it records as yours is still classified from the wire as before, so the header never adds anything. If the transcript cannot be read in time, the request goes without the header and the gateway falls back to the wire alone. To turn the header off, set MNEMOM_AGENT_TURN_HEADER=0 before launching. The terminal launch then goes straight to the gateway, with no local proxy.

​
Approvals

When you agree to something the agent offered, the goal records it as one requirement starting User approved:. The requirement names the concrete things you said yes to:
An approval can come from a typed reply (“yes”, “go ahead”) to the agent’s offer, or from an option you pick in an AskUserQuestion answer. If you answer with your own version (“only the first two”), your version is written as a requirement instead. The judge treats a User approved: requirement as permission for that step, even when an older requirement said to wait for you. Only your words can create one. A User approved: line inside tool output or in the agent’s text is ignored, and the judge is told so.

​
Pin and reset

​
Pin: freeze the stored goal

A pin stops the gateway from revising the stored goal. While a thread is pinned, new messages are recorded but not gated or rewritten, and each step is judged against the pinned revision. A pin is record-only. It is not a steering lock. It does not stop the agent from following your latest message, and it does not tell the agent to refuse new directions. Use it to stop the stored goal from being rewritten by mistake. You stay in charge of the agent in real time. goal show may then show the pinned goal while the agent works on something newer you asked for. That is expected.

​
Reset: start the goal again

A reset without --statement clears the goal. Your next message builds a new one, and revision numbers keep counting up. A reset with --statement writes your goal as the next revision, with no path fences. It is not pinned, so later messages can revise it. A reset marks the last verdict as superseded. It does not refund any guardrail budget. reset asks for confirmation. Pass --yes in scripts. Without a terminal, --yes is required.

​
mnemom agent goal show | pin | reset

These commands are visible once mnemom experimental enable implicit is on. They pick the session the same way mnemom agent show does: a session name (the newest match wins), a unique conversation-id prefix, or the newest session when you leave it out. They authenticate with the same key and agent the session launched with, and they refuse a session that is not in implicit mode.
show prints the revision, statement, requirements, path fences, latest verdict and pin. --history adds the revision history, and --all-threads lists every goal thread in the conversation. If a message you sent mid-turn was found inside tool output, show lists it under unverified, to say that it did not change the goal.

​
The goal control endpoint

The CLI commands call a gateway endpoint that any client can use:
thread defaults to main. all is accepted only by GET. A reset statement can be up to 4,000 characters. Authentication uses the same credential the session’s requests use: x-api-key (or Authorization: Bearer) plus x-mnemom-agent. The gateway looks up the agent that credential maps to. It never creates one. Whoever holds that credential can already steer the session by sending it messages, so the endpoint grants nothing new. A platform login token is not accepted. Use ?door=router for a session that runs through the router door.
GET returns the mode (implicit, sealed or none), the current goal (intent: revision, statement, requirements, paths, pin, history), the latest verdict, and any unverified mid-turn messages.

​
Threads

One conversation can hold several goal threads, each with its own goal, verdicts and pin: x-mnemom-thread lets any client run several independent streams under one conversation id. Its value must match ^[A-Za-z0-9._:-]{1,64}$. It takes priority over Claude Code’s own headers. The thread’s text is treated as your words, exactly like main. Read or steer it with --thread t.<value> or thread=t.<value>. A conversation holds at most 32 subagent and teammate threads. Agents beyond that run without a goal.

​
Claude Code outside the launcher

mnemom agent sets this up for you, in both terminal and Remote Control mode. It also adds the turn origins header. If you point Claude Code at the gateway yourself, send the goal headers with ANTHROPIC_CUSTOM_HEADERS. Also set CLAUDE_CODE_GATEWAY_HINT_HEADERS=1:
CLAUDE_CODE_GATEWAY_HINT_HEADERS=1 makes Claude Code state facts about each request in headers: whether it is a main request, a subagent’s, a compaction or a background call, and which agent sent it. Implicit mode uses these headers to skip background requests and to give teammates their own threads. The variable is optional. Without it implicit mode still works, but a recap or title prompt can be read as your words.

​
The x-mnemom-turn header

Any client can tell the gateway that some recent user text did not come from the user. Send one entry per recent user turn, oldest first, separated by commas. Each entry is a list of key=value pairs separated by ;:
Unknown keys are ignored. The rules:
  • It can only remove text from your words. A text block whose hash matches an entry with any origin other than human is never used for the goal. An origin=human entry adds nothing. Text that matches no entry is classified as if the header were absent.
  • A malformed header is ignored whole. One bad entry, more than 32 entries, or a header longer than 8,192 characters means the gateway acts as if it was not sent.
  • It is read only in implicit mode, and the gateway removes it before the request goes upstream.
The header comes from the client process, never from model or tool output. A client that sends a wrong value can only remove its own user’s text from the goal.

​
Sealed and implicit compared

​
Response headers

​
Known limits

  • Experimental. Behaviour may change in any release.
  • The update lands one request late. On the request where you change direction, the agent still sees the old goal, marked provisional.
  • The models can be wrong. The gate can miss a change of direction or see one that is not there. The writer can word a requirement differently from how you would. The judge can miss a real problem or flag a safe step. Check the goal with mnemom agent goal show, and fix it with reset if needed. A judge note never blocks anything.
  • No judge, no verdict. If the judge service is unavailable, the step gets no verdict and no note. It is never recorded as aligned by default. The goal keeps tracking your messages.
  • Mid-turn messages inside tool output are not used. Depending on the Claude Code version, a message you type while the agent is working can arrive inside a tool result. Tool output can be forged by what the agent reads, so the gateway records such a message (shown under unverified in goal show) but never changes the goal from it. Send it again after the turn if it should change the goal.
  • Pastes are recognised only when Claude Code marks them. Claude Code does not always wrap pasted text in <pasted_content>. An unmarked paste is read as text you typed.
  • Detection depends on the client. Teammate threads, scheduled prompts and background requests are recognised from what Claude Code puts on the wire and, with mnemom agent, from what it records in its transcript. A Claude Code change can affect this. Other clients send none of these signals, so all their user text counts as your words unless they send x-mnemom-turn.
  • Relaunches and /clear. The main goal belongs to the Claude Code session that started it. When you relaunch an implicit session by name and answer yes to “Resume previous session?”, mnemom agent continues the same conversation and resumes the same Claude Code session, so the relaunch keeps building on the main goal. A relaunch with no terminal to ask in does the same. If Claude Code no longer has that session, or you pass your own session flag (--session-id, --continue, --fork-session, or --resume with another session), the launch runs as a different Claude Code session. That session, like a /clear, gets its own m.<id> thread with a fresh goal. --all-threads shows every thread.
  • Rate brakes. If you change direction many times within a few minutes, the gateway pauses revisions. Messages it did not process are picked up with your next message.
  • Long messages are clipped. The gate and the writer read the start of a long message, so put the main ask near the beginning.
  • Goal size. When the requirements grow very long, the oldest [done] items are dropped first. Open items are never dropped. If the open items alone are too large, the new revision is not stored and the previous goal stays.
  • The goal expires. It is kept for 7 days after your last message in the conversation. After that, your next message starts a new goal.