Skip to content

Self-Modifying Agent

mario-zechner's thesis for Pi: the coding agent should be able to edit its own source in response to user requests, and this should be the default extensibility mechanism rather than plug-in protocols or MCP.

The claim

"Where we are going is software that modifies itself on behalf of the user's wishes and needs, and the agents can do that now if you give them enough rope to modify themselves. With Pi that is my first foray into this kind of self-modifiable malleable thing — just for the coding-agent sector, but this can be extended."

Concretely: Pi's TUI, compaction strategy, command surface, and behavior are all modifiable by asking Pi to modify Pi. Non-technical users have reshaped the TUI for their own workflow without writing code directly — they describe what they want, Pi edits itself, the change sticks.

Why it's more than a gimmick

  • Removes the fork/plug-in tax. Forking OpenCode to customize it felt like a design failure to Mario. Extension points + self-edit collapses "add a plug-in" and "change the core" into the same motion.
  • Matches the extension-point trajectory of openclaw. OpenClaw's plug-in architecture (Slack, Teams, memory, dreaming) is the same philosophy at the personal-assistant layer — Pi is the coding-agent version.
  • Forces minimal core surface. If the agent can always add what it needs, the shipped core should stay small. Mario keeps Pi's tools down to read, write, edit, bash.
  • Aligned with skills-over-mcp — Krentsel's finding from the OpenClaw side: the cheapest extensibility (markdown skills, self-edit) beats the most rigorous (MCP).

Limits

  • Complexity-as-enemy is the governor. Self-modification without a "say no" filter turns the codebase into a clankers-writing-clankers feedback loop. See complexity-as-enemy.
  • Requires stability in the non-self-modifying parts — agent loop, extension loading, provider abstraction are refactor-heavy zones Mario still hand-maintains.

Connects to