DocsCore conceptsWhere Memnox stands

Where Memnox stands

Memnox does not have to sit in the middle of every request to be useful. It can stand in three positions relative to an agent, and each one is a complete, honest way to run it.

An agent can ask Memnox what it should know. It can ask Memnox whether something may happen. Or Memnox can sit in the execution path and apply the answer itself. The three compose, and most organizations use all of them at once, on different agents, in different places.

Position

Context

The agent asks what governs the work before starting it. Memnox answers with the constraints that apply and who owns them. Nothing is recorded, nothing is blocked. The agent stays in charge of itself.

Governance

The agent asks whether a specific action may happen. Memnox evaluates it and answers: allow, deny, ask, escalate, delegate or clarify. Execution stays with the agent, and the question and answer are on the record.

Enforcement

Memnox sits between the agent and its tools, through editor hooks, the MCP firewall, or the SDK wrapped around the tool loop. An action that is blocked does not run. There is nothing for the agent to ignore.

Context: the agent asks first

The cheapest failure is the one that never happens. Before an agent commits an hour of work, it can ask what governs this, through memnox context, the MCP server's memnox_check_rules, or memnox.context() in the SDK.

This position records nothing and forbids nothing. It exists because a refusal after the work is done costs the work, and a briefing before it starts costs a question.

An agent platform you did not build can stand here on day one. It keeps its own tools, its own loop and its own product. It gains the one thing it could never work out alone: how this company does things.

Governance: the organization decides

The second position is the evaluate call. The agent declares what it wants to do, at what size, for whom, and the answer comes back from three layers that do not speak for each other: whether a rule forbids it, who could authorize it, and how much of the answer this asker is entitled to see.

Memnox is not in the execution path here. The agent, or the platform that runs it, chooses to ask and chooses to honor the answer. What this position adds over context is authority and the record: the question was asked, the organization answered, and both are in the ledger.

This is the position built for companies whose agents live inside somebody else's product. The platform does the work. Memnox holds the authority.

Enforcement: the gate applies the verdict

The third position puts the runtime where the action happens. Editor hooks, the MCP firewall, or governTools put the same evaluation in front of every tool call, and a block is a call that never executes.

Enforcement is what makes the guarantee unconditional. In the first two positions the agent could fail to ask. Here there is no version of the action that skips the question.

Starting shallow is the design

The order is not an accident. Context costs nothing and offends nobody. Governance adds authority where the questions have consequences. Enforcement goes where the consequences are real: production, payments, customer data.

Nothing forces the march. An organization can run an agent at context depth forever and Memnox is still doing its job. The depth is chosen per agent and per environment, which is why a fleet of twelve agents is usually standing in all three positions at once.

Console → Agents, showing agents at different depths: one with ask access only, one governed, one behind the firewall

Console → Agents, showing agents at different depths: one with ask access only, one governed, one behind the firewall

screenshot slot, save as public/screens/…png and set  src

Depth is a property of each agent, not of the account. The fleet does not move in lockstep.