Date: 2026-09-08
pi-sych grew out of a period when I was trying to understand what coding agents were actually doing around me.
I did not start from minimalism. Quite the opposite. My early setup was OpenCode with CortexKit, AFT, Magic Context, and a growing collection of agents, skills, instructions, and model choices. It was useful, and I learned a lot from it. It also became increasingly hard for me to keep a good mental model of the whole thing.
pi-sych is partly an attempt to try the opposite: ordinary files for durable project state, small explicit contexts, disposable workers, and as little hidden machinery as I can get away with.
I am not claiming that this is better. The original point was more modest: remove some confounding variables and see what strong models can do when I can more easily understand what they were given.
When I first began using coding agents seriously, the batteries-included approach made sense to me. I wanted to understand what these systems could do, so I used OpenCode and added more things around it.
CortexKit’s Magic Context was particularly interesting because it tackled context and memory directly. I also used AFT, Agent File Tools, and wrote quite a few agents and skills of my own.
None of this was a disaster. That is important. I did not flee a burning architecture.
The problem was closer to epistemic housekeeping. As the setup grew, it became harder for me to answer simple questions such as: what exactly is in the model’s context, where did this instruction come from, and which part of the system is responsible for this behaviour?
Around the same time I started reading criticism of more elaborate coding-agent setups and watching Mario Zechner talk about Pi. Pi’s deliberately small core interested me not because I knew it would perform better, but because it looked easier to reason about.
So I tried it.
The attraction was not “small software is morally superior.” It was that fewer moving parts might let me build a better mental model of what was happening.
This also coincided with getting access to stronger models through Codex. I was curious about how much they could already do without me teaching them quite so much.
That changed how I thought about agents too. In OpenCode I had accumulated several named agents, often because I wanted slightly different instructions, skills, or models. Sometimes the distinction between two agents was barely more than the model I wanted to use.
pi-sych moved toward something more disposable. A supervisor can choose the model, instructions, skills, and files for a bounded worker, launch it for one job, and then throw that context away. I do not need to pretend each combination is a permanent little employee with an identity and a tiny desk of its own.
That is a simplification I arrived at after using a more agent-heavy setup. It was not a principle I started with.
I also became more cautious about memory, although again this happened after I had already used fairly sophisticated memory tooling.
A project has information with different useful lifetimes. Some things matter only for the next few turns. Some need to survive a long task. Some should become durable project knowledge. And quite a lot of conversational history probably does not need to survive at all.
pi-sych therefore treats ordinary files as the durable state of the project. Accepted decisions, current arguments, evidence, plans, and other things worth handing to another person or model should eventually become inspectable files.
But saving absolutely everything to files just recreates the original problem in another form: enormous files full of process history.
So I started experimenting with a much smaller kind of working memory and custom compaction. The goal is not to preserve the whole conversation. It is to keep the model oriented long enough to continue the work while the things that truly matter are distilled into the project itself.
Negative information is a good example. If an approach failed in a way another model is very likely to repeat, that can be worth carrying forward. If an idea was mentioned once, rejected for reasons specific to that conversation, and is unlikely to recur, preserving it forever may do more harm than good.
Not every discarded thought needs a pension plan.
I had already noticed another version of this problem in writing before pi-sych existed.
I might tell a model that I would not phrase an argument as X and that I wanted Y instead. The next draft would then say something like “Y, rather than X.”
That makes sense as a conversational reply. The model is responding to what I just said. It is much stranger in a paper whose reader has never seen X and has no reason to know that an earlier draft contained it.
The discarded deliberation has leaked into the artifact.
That experience is one reason fresh contexts became interesting to me. A review or planning conversation can be rich and messy. The implementation context does not always need the whole argument. Sometimes it needs the current decision and the files that embody it.
This is also why I am wary of durable instructions that say things like “do not do X” merely because X happened to come up once. If a fresh model had no particular reason to do X in the first place, I may have just planted the idea I was trying to suppress.
The same experiment has affected how I write the extensions themselves.
Coding models have a habit of treating a tiny hobby project as if they were preparing it for a large production organisation. I started giving them source code budgets and asking them to stay within a small number of lines when possible.
This can obviously go wrong. Short code is not automatically good code, and an arbitrary line budget can encourage terrible compression.
But as a constraint it has sometimes been useful. It forces the model to justify new machinery and leaves me with TypeScript that I can usually follow despite not being a TypeScript specialist. For someone familiar with C-like languages and general programming, I find much of it readable enough to inspect.
Again, the point is less optimisation than intelligibility.
pi-sych is available on GitLab, with separate documentation. It is still an experiment and I expect parts of it to change or disappear.
The present design is much cleaner than the route that produced it. That route was not a straight line. It involved adding machinery, removing it, discussing ideas with models, trying different agent setups, changing my mind, and occasionally rediscovering the same problem in different clothes.
I have also ended up making several smaller Pi extensions and wrappers along the way, including pi-pew-pew, pi-lease, and pi-auch. I would not pretend that I planned them as an ecosystem. I simply started enjoying the process of vibe-coding small Pi tools and seeing how narrowly I could define each problem.
For now, pi-sych is my attempt to make longer AI-assisted work easier for me to inspect and reason about.
Whether that also makes it better is a separate question. I am still trying to find out.
Thank you so much for reading!
If you would like to give some feedback please open an issue on this blog’s GitLab.