I have been reading Mario Zechner's posts while building Openclaw. He is the author of the Pi agent framework behind it, and his writing pushed me to rethink what I thought mattered in agent design.
The punchline is not another feature. It is the absence of them.
The real leverage in coding agents is not autonomy, it is context discipline.
This post is not a review of his tools. It is the mindset I took away, and the habits I now try to keep.
The control problem is context
A lot of coding agents feel powerful until you look closely at what they inject. Giant system prompts. Dozens of tool definitions. Invisible guardrails and side instructions that you cannot see, tune, or version. When results drift, you cannot tell if the model changed, the system prompt changed, or a hidden tool definition changed.
Zechner treats that as the core problem: context is the real interface. His Pi agent is built to keep it visible and minimal. The system prompt and tool definitions are tiny, and the only user level customization comes from an explicit AGENTS file that is appended in a predictable way. That is a subtle but important stance: the user should be able to read, edit, and own the context.
Once I started viewing context as the product, I understood why he cares about it so much. If you cannot audit the prompt, you cannot debug the behavior. If you cannot control the tool list, you cannot control the cost of reasoning.
Minimal prompts are not lazy
Pi is intentionally small. The prompt and tool definitions together are under a thousand tokens, and the toolset is basically read, write, edit, and bash. That is not a gimmick. It is a claim about where agency should live.
Zechner argues that the models already know how to be coding agents. If that is true, then the job of the harness is not to re-educate the model with 10,000 tokens of rules. The job is to provide a stable surface area and get out of the way.
I used to equate longer prompts with more control. Now I think of them as more places to leak. The minimal prompt does not make the agent dumber. It makes the system more legible.
In practice, I have not felt a capability drop relative to heavier agent shells. The consistency is better, which matters more than theoretical peak performance.
MCP vs CLI is mostly a wash, context is not
Zechner is blunt about MCP. His view is that many MCP servers ship a large, generic tool catalog with a lot of description text. That bloats the prompt, and it is a form of context pollution. In his measurements, common MCP toolsets can burn a noticeable slice of the context window just to describe themselves.
What surprised me more is that he still ran a direct evaluation. In his MCP vs CLI experiment, the success rates were the same, and the differences were small. Sometimes MCP was faster or cheaper, sometimes the CLI version was. The bigger variable was the quality of the tool itself, not the protocol around it.
That is the practical takeaway. Protocols are pipes. The core question is: does this tool help the model do the task? If the tool is good, any pipe works. If the tool is verbose and generic, no pipe saves you.
In my own stack, that pushed me toward CLI-first tools with short READMEs. The context cost is near zero, the output is easy to parse and store, and the tools compose with everything else I already use. It is also why Openclaw does not ship native MCP integration.
Prompts are programs, files are state
One of Zechner's most useful ideas is to treat prompts as programs. The prompt is not just a set of instructions; it is the program that defines input, tools, and control flow. Long before Skills became a mainstream idea, he was already working in that style.
That framing leads to a second rule: do not store state in the model's memory. Store it in files. He advocates JSON or Markdown as the ground truth and uses small scripts like jq to update state deterministically. The model becomes the slow, unreliable computer that runs the program, while the state lives on disk where you can diff, version, and restore it.
I have started to do this with TODO and PLAN files. When the plan changes, I want the diff, not a hidden shift in the model's head. It is slower up front, but it is radically more recoverable.
No plan mode, no hidden to-dos
Pi does not ship a built-in plan mode. It does not keep an internal to-do list. It does not spin up sub agents in the background. That is not a missing feature; it is a deliberate choice about visibility.
Zechner recommends external files like TODO.md and PLAN.md. If you want a plan, write it down. If you want to change it, edit the file. If you want to share it, it is already a real artifact. The same logic applies to avoiding black box sub agents. If you need parallel work, do it in a separate session and bring back a concrete artifact.
I used to love auto-generated plans. Now I see the cost: they feel helpful, but they are a hidden state machine. Pi forces you to keep the state in daylight.
Observability and cost are product features
Zechner built cchistory and claude-trace to capture the exact system prompt, tool definitions, and first message that a provider runs. He also patched Claude Code to expose /cost for Max users, because cost is part of the debugging surface.
That mindset matters. If a tool hides the system prompt, it hides the true experiment. If it hides cost, it hides the trade you are making. For high intensity users, that opacity is not a nice-to-have. It is a blocker.
I now keep lightweight traces for any agent workflow I care about. I log the prompt, the tools, and the file diffs. It is not fancy, but it makes performance and cost legible.
YOLO by default and the security reality
Pi runs in YOLO mode by default. Full filesystem access, command execution, and network access. Zechner's argument is that once you give an agent that trifecta, the security problem is already unsolved. The honest answer is not a fake gate, it is an explicit tradeoff.
He suggests running in a container or a disposable environment if you care about boundaries. That is a concrete recommendation, not a marketing line. You should assume the model will see whatever you let it see.
It is a tough stance, but I appreciate the clarity. Safety is not a button. It is a system boundary, and you have to draw it yourself.
What I changed after reading him
Here is what actually shifted in my day-to-day:
- I keep my system prompt short and put everything else in AGENTS.md.
- I prefer CLI tools with tiny README files over giant tool catalogs.
- I keep TODO.md and PLAN.md in the repo, and I treat them as state.
- I do not use hidden plan modes or background sub agents.
- I log prompts, tool lists, and file diffs on any workflow I care about.
The changes are boring. That is the point. The calmness is the leverage.
Closing thought
The lesson I took from Zechner is simple: if you want a strong agent, design for control, not magic. The rest is just engineering.