You open your editor and ask your coding agent: "what did we deploy last week?" It starts reconstructing. It greps the repo. It opens the cloud console. It asks you. It guesses. The agent that shipped the code has no idea what's running now.
This isn't a prompting problem. It's a state problem.
Most coding-agent setups have a lot of context — the conversation, the open files, the last few tool calls — and almost no state. They can act; they can't remember what they acted on. The gap between those two things is the difference between a smart assistant and a system you can leave to operate infrastructure.
The distinction
Context is the working memory of a session: tokens in the window, the open editor, the last few tool responses. It's rich, local, and gone the moment the session ends.
State is the durable record of the system: what's deployed, where, from which commit, wired to which services, holding which secrets, with what history. It survives restarts, session ends, operator handoffs.
In Monk, state lives as a typed, queryable graph of every deployed entity — services, databases, secrets, network edges — maintained by the orchestrator and updated whenever the system changes. I'll use "the graph" below to mean exactly that.
Both matter. Context is where judgment happens; state is where reality lives. A good operator uses both. A system that leans on context for everything keeps repeating itself and getting the answer wrong.
Context without state is amnesia. State without context is useless data.
Can't the agent just take notes?
The natural workaround: have the agent keep a markdown file — CLAUDE.md, AGENTS.md, PROJECT_STATE.md — and read it at the start of each session. I use these myself. They help. They are also fuzzy by construction: hand-written, hand-maintained, not queryable, and they bitrot the moment the thing they describe changes. A markdown note is a snapshot somebody forgot to retake.
The second-order cost is tokens. Every session that starts by rediscovering the deployed system — reading the cloud console, running five tool calls to piece together what's wired to what — pays that cost from scratch, over and over, every turn. Context is expensive to refill; state is cheap to query. Rediscovery also skips the correctness guarantee: if the reconstruction missed something, the agent doesn't know it missed it, and neither do you.
The deeper problem sits underneath both of those. Without state, the system's knowledge of itself lives in whichever session or person happens to have it. Close the session, rotate the operator, hand off to a new team — the knowledge goes with them. Operational knowledge that's real but implicit, held somewhere you can't afford to lose, is a familiar failure mode. Runbooks were the old patch for it. The fix that actually holds up has to be state the system owns itself.
The rest of this post is five common situations where that difference decides whether the agent can do the job.
1. "What's deployed right now?"
The session-boundary case. Close the tab, open it tomorrow, ask the question.
A context-only agent starts poking — cloud console, kubectl, the Terraform statefile if there is one, git log. If more than one person or more than one agent has touched things, the answer is incomplete by construction. It's a reconstruction project, and it treats facts that already existed as questions to rediscover.
A state-first system has a live inventory: every service, every cloud resource, every version, every wiring edge. "What's deployed?" is a query against that inventory, not an investigation.
2. "Redeploy, but keep the same database"
The cross-session decision case.
Last week you decided, for a specific reason, to run managed Postgres instead of a container. That decision lived in the conversation. The conversation is gone. A new session — possibly a different agent — will default to whatever seems canonical from the code, which might be the container version. Sometimes you catch it in review. Sometimes you don't.
When the decision is embodied in a deployed entity, not a past sentence, it doesn't need to be remembered. The Postgres isn't a fact from last week — it's a live part of the graph. "Redeploy" means "apply changes to the graph," not "rebuild from scratch and hope the defaults are right."
3. "Rotate the database password"
The fleet-scale multi-step case.
Updating a password is one call. Updating all the consumers that read it, in the right order, without breaking live traffic, without restarting anything twice, is a small project. If the session is long enough and the token window is generous, a context-only agent might manage. One unexpected restart and the context has no way to recover — it doesn't know which services it already rotated, which are mid-roll, and which are waiting.
If the password is held as a typed secret referenced by the entities that consume it, rotation is one change at the entity level. The graph knows which services need a reload and in what order. "What's the rotation status?" is a query. Failure mid-way is resumable — the state records how far the operation got.
4. "Add an auth provider to the app"
The informed-change case.
To add OAuth, the agent needs: the framework in use, where routes are defined, which services need JWT verification, the env-var layout, the ingress configuration. Each of those is a tool call or an inference. A context-only agent spends thousands of tokens reconstructing facts that already existed somewhere before proposing the change. If it skips any reconstruction, it guesses — and guesses about the deployed system are the kind that break production quietly.
When the deployed graph already knows those things, the agent queries instead of rediscovering. The change is a diff on the graph, not a redesign from scratch.
5. "Something broke — what changed since yesterday?"
The diff-and-history case.
Yesterday's conversation is gone. git log will tell you about code changes. It won't tell you that a security group tightened, a secret rotated, a cache swap landed on the same hour, or that a capsule was destroyed and recreated with a different image tag. If the problem is infra, the code diff says nothing useful.
State has history. "What changed" is a diff between two recorded states, not a reconstruction from logs. Code, infra, secrets, config — one timeline, one query.
<figure> <!-- TODO: screenshot — state diff between two points in time --> </figure>Why this line matters
The boundary between "coding agent with tools" and "system that operates infrastructure" runs through state. A one-shot assistant can get by on context — act once, succeed once, disappear. Anything expected to operate across days, operators, branches, and incidents needs state. That isn't a feature you bolt on; it's an architectural decision about whether the system has any memory of its own work.
Monk is built around that decision. The graph is the state. Every entity knows what it created and how to tear it down. Every capsule inherits the same discipline — a capsule isn't a fresh conversation, it's a scoped slice of state with its own lifecycle. That's why "what's deployed?" isn't an exploratory question. It's a query.
