TFKS & Forgejo Knitting Software
Leveraging Forgejo to build a system that knits specs, code, tests, releases, and memory into a useful sweater.
I was experimenting with long-term memory for my software projects since it was the AI topic-of-the-week on how to more effectively & efficiently use agents. I wanted something transparent that travelled light, not something opaque like a database. I thought that a project-local ./wiki/ directory coupled with my source control's wiki for org-wide notes would be a good fit.
Forgejo is a Github-like platform that I was already using to host my software projects. The more I looked at the primitives that a system like Forgejo has - issues, labels, pull requests, wikis - the further I tripped down the rabbit of hole of building my own an agent harness. These are primitives that anyone who's worked in or around software development in the last couple of decades already understands.
I didn't want to build something that required learning a new mental model. I wanted to assist & accelerate the model I was already operating in. Labels become a state machine. An issue moves through states — triage, in-progress, review, done — the same way work always has, just with explicit labels driving the transitions. The wiki becomes long-term memory, split into local project-scoped notes in a ./wiki directory and organizational memory in the Forgejo wiki proper. An agent updating context after completing work writes a markdown file, not a vector embedding. It's slower. It's also readable by a human without a query interface.
I added exactly two new concepts. A brief is a comment that the Project Manager agent (PM) — or me, while I'm still serving that role — writes in an issue to orient the working agent. Efficient, task-specific, scoped. A ledger is a comment where the agent records what it actually did. Together, they mean the history of any piece of work is a comment thread you can scroll through without special tooling. The agents themselves have roles you'd recognize: PM, Developer, Tester (QA), Builder. Nothing exotic.
Agent Optional
Here's the design constraint I kept returning to: if the API goes down, if I hit a budget wall, if I just don't feel like paying for tokens — the workflow doesn't break. I still create issues, label them, and submit PRs. I move through the same states in the same order. If an agent becomes available before an issue is complete, I can hand off mid-stream. The agent is an accelerant, not the engine.
This matters more than it sounds. Fifteen years ago I worked at a consultancy that built a genuinely excellent development workflow on top of GitHub bots. No AI, just automation wired into primitives you already had. It worked wonderfully, and it's part of why I reached for this shape when I started thinking about how to give my coding agents more autonomy. The workflow was the thing. The bots were workers. Most current agent frameworks are designed the other way around. The agent is the thing. The workflow exists to support it. That's fine for interactive sessions, for exploratory work, for getting something done in an afternoon. It's less fine when you're building something that needs to survive a model swap, a token budget crunch, or a human deciding to just handle it themselves.
When to drop the workflow entirely
None of this is to say the formal workflow is always the right shape. There's a separate mode that's worth naming: sitting down with an agent and just working together, with no issues, no labels, no briefs or ledgers. Pair programming. The feedback loop is tight, you can see what it's doing in real time, you redirect immediately when it drifts.
I think about it the way I think about teaching. If you give a drum student a set of rudiments and tell them to go practice for a week and report back, that's the workflow model — async, structured, with artifacts that survive the session. If you sit on the bench next to them and correct their grip in real time, that's pair programming. Both are useful. They're useful for different things.
The async workflow is what you reach for when the work is well-defined enough to hand off, when you want a record of what happened, when you might not be available to babysit, or when you're running several streams of work in parallel. The pair programming mode is what you reach for when you're exploring, when the problem is fuzzy, when the vibes are right and you just want to move.
The mistake would be insisting on the formal workflow for every interaction. The issues and labels and ledgers exist to give structure where structure helps. Sometimes it doesn't.
Pedaling, Not Driving
A metaphor that might be apt: pedaling vs driving. You can get on a tandem bicycle with it — the agent pedaling & steering while you take in the sights. If it crashes, it's only some scrapes & bruises. You're not in a hospital. That's the thing I'd encourage anyone who's been watching this space with a raised eyebrow to consider. You don't have to adopt a whole new vocabulary. You don't have to build something that falls apart when the API changes. You can start with the primitives you already trust, layer in agents where they help, and stay close enough to the work that you always know what's actually happening.
The agents are here. They do useful things. But they work for the workflow — not the other way around.