Learning by Archiving Projects
A post-mortem on frctls, anna, and synthia, and what old repos reveal when you treat archiving as a learning practice.
What three retired systems-thinking projects taught me about AI agents, publishing loops, and the difference between scaffolding and learning.
I have a habit of building small systems to think with.
Some become products. Some become infrastructure. Some become a pile of useful mistakes with a README attached. The important thing is not whether every repository survives. It is whether the work leaves behind better judgment than it started with.
I have been preparing to archive three old projects: frctls, anna, and synthia. They all circled the same territory: systems thinking, organisational learning, autonomous research, and AI-assisted publishing. Each tried to turn a learning loop into software. Each failed in a slightly different way. Together, they are a useful record of what I was actually learning.
The temptation with old repos is to call them dead and move on. That wastes the useful part. A repo is not only source code. It is a fossil record of decisions: what seemed important, what was overbuilt, what never got used, where the energy went, and which assumptions survived contact with reality.
So before archiving them, I wrote the post-mortems.
frctls: the system became more interesting than the product
frctls started as Fractals of Change: a product and content experiment about small managed changes inside large organisations. The target user was clear enough: enterprise directors trying to shift culture and productivity without falling into the theatre of transformation.
The best part of the project was the framing. It had a mission document. It had non-goals. It had a clear first phase: thought leadership before product tooling. It shipped a real Astro blog with a body of posts around cultural tokens, change patterns, compliance, remote work, and organisational transformation.
That was valuable. Writing is a forcing function. If you cannot explain the market, the user, the pain, and the mechanism, building a UI will not save you.
But frctls also revealed one of my recurring traps: the scaffolding became more compelling than the thing being scaffolded.
The repo accumulated .pip, Nx fragments, agent roles, activity logs, branch rules, security scans, autonomous roadmap agents, PR monitoring, workflow hardening, and CI repair work. Some of that was useful. A lot of it became its own gravitational field.
Eventually the recent history of the repo was no longer about a product for organisational change. It was about pausing automations, fixing GitHub Actions, closing generated PRs, managing dependency baselines, and keeping the machine from making more work.
That is a specific kind of failure. Not useless failure. Informative failure.
The lesson was not "do not build systems." The lesson was: a system is only leverage when it keeps pressure on the product loop. If it creates a second loop that must be maintained independently, it is probably infrastructure cosplay.
frctls taught me that agent governance, activity logs, and repeatable project scaffolding matter. It also taught me that they should be extracted into tools only when they have more than one consumer. Otherwise they can hide the absence of a product.
anna: simplicity is not a feature unless you protect it
anna had a sharper product shape.
The brief was deliberately constrained: a systems-thinking blog that publishes every Thursday. One topic list. One state file. One cron route. One workflow: research, synthesize, write the article, produce workshop material. File-based storage. No database. No agent framework. Stay under 500 lines.
That was a good idea because it named the real job. Not "build an autonomous content platform." Publish one useful article every week.
The initial design had the right instincts:
- a small Next.js app,
- Vercel Cron for scheduling,
- markdown for generated content,
- a topic queue,
- a sequential workflow rather than orchestration theatre.
The interesting part is what happened next. The project started collecting the very machinery it was designed to avoid: provider switches, Blob storage, Council, Builder and Developer agents, submodules, CI fixes, workflow runtime changes, and shared skill infrastructure.
Again, some of that was useful. Production has opinions. Vercel storage behaves differently from local file storage. Scheduled jobs need observability. Generated content needs persistence. Build-time and runtime paths are not the same thing.
But the original constraint collapsed. The project stopped being a publishing loop and became another agent-system experiment. The clearest evidence is simple: the repo had a content/published directory, but no durable published archive in it.
That is the post-mortem in one line. The system for publishing existed. The publishing did not.
anna taught me that minimalism is not achieved by starting small. It is achieved by refusing almost everything after you start. A small architecture is a living boundary. If every production concern becomes an excuse to add another subsystem, the original product disappears.
If I were rebuilding anna, I would keep one rule above all others: the weekly article is the product. Every task either helps the next article ship or waits.
synthia: a clean pipeline still needs a destination
synthia was the cleanest technical implementation of the three.
It was a Python package with a straightforward pipeline:
Scheduler -> Topic Selection -> Research -> Reflection -> Writing -> Publishing
Each component had a sensible responsibility. Config loaded YAML and environment variables. State tracked explored topics. Topic selection avoided repetition. Research gathered sources. Reflection used Claude to find patterns. Writing generated long-form material. Publishing wrote markdown.
It was portable. It was testable. It avoided databases and queues. It had a CLI. It could run once or run on a schedule. As a piece of software architecture, it was probably the most coherent of the three.
It also exposed a different limitation: a pipeline is not a learning loop until its output meets the world.
synthia could produce markdown files, but it did not own a publishing surface, an audience, an editorial review step, or a feedback mechanism. It had a process for generating writing, but not a process for learning whether the writing mattered.
This is easy to miss with AI systems because generation feels like progress. A model returns 2,000 words and the terminal says success. But writing is not complete when text exists. Writing is complete when it changes a reader, a decision, a conversation, or the author's understanding.
Without that loop, the system mostly proves that automation can move tokens from one place to another.
synthia taught me to distinguish pipeline quality from product quality. The architecture was clean. The destination was underdefined.
The common mistake
All three projects were attempts to automate learning.
That is still a good ambition. But the post-mortems make the mistake obvious: I treated learning as something that could be generated by a system, when the system only creates the conditions for learning.
Learning requires friction:
- a real reader,
- a real user,
- a real deadline,
- a real deployment,
- a real failure,
- a real change in behaviour after the failure.
Automation can help with research, synthesis, drafting, checking, publishing, monitoring, and recall. It cannot remove the need for contact with reality. In fact, the best automation should increase contact with reality by making the loop cheaper and more frequent.
The failure mode is when automation creates a believable simulation of progress. A workflow runs. A PR opens. A markdown file appears. A dashboard updates. The system is busy, but the underlying question is untouched.
Did anyone read it?
Did anyone use it?
Did it make the next decision better?
Did it change what I believe?
What I would keep
I would not revive these repos directly, but I would keep several patterns.
From frctls, I would keep the discipline of mission documents, activity logs, and explicit non-goals. They made the project legible after the fact, which is the only reason the post-mortem is useful now.
From anna, I would keep the product constraint: one schedule, one output, one publishing loop. The original brief was good. The drift was the problem.
From synthia, I would keep the simple linear pipeline. It was the right technical shape for the job. It just needed a stronger editorial and distribution layer around it.
The combined version would be much smaller than any of the three:
- Pick one theme.
- Keep one topic queue.
- Draft with AI.
- Review by hand.
- Publish to one place.
- Measure one signal.
- Write down what changed.
That is enough system. Anything more has to earn its place.
Archiving as a learning practice
Archiving a project is usually treated as housekeeping. I think it is closer to research.
The archive decision asks: what did this project teach, and is that lesson still alive somewhere? If yes, the repo can close. The learning has moved on.
That is what is happening here.
frctls lives on in my stronger suspicion of overbuilt scaffolding. anna lives on in my insistence that automation must protect the product loop, not replace it. synthia lives on in the preference for small, linear, inspectable agents.
None of those repos need to remain active for the learning to remain active.
That is the point of archiving well. You are not burying the work. You are extracting the part that can still compound.