ACME: A Content Management Experiement

After deciding the biggest area for improvement was context management during coding, I decided to build a context management tool. Even just a basic ticketing system with a CLI will be enough to try out ideas for enriching the development process.

What exactly the tool should do I am not sure, so I’m going to call it “ACME”, a gloriously bad acronym for “A Context Management Experiment”. I was trying to think of a “context management” reference or pun, and a trailer for “Coyote vs. ACME” made me realise that ACME is the perfect name! What better brand for an experimental personal project where no doubt many of my decisions will slam me, metaphorically, into a brick wall?

Fast experimentation with coding agents

Since I had some old code kicking around for a knowledge graph with a Supabase database and a Retool front end, I got an initial version working in a day just by porting across that code in to a new stack of backend server, Postgres database, and web frontend. Nothing fancy at all, but I recall the queries in Postgres did take some time to write originally.

One of the ongoing joys of agentic coding is how quickly it lets you try out an idea. Here’s a few things that were trivial in terms of time required, all done over three days, where each would likely have been a day or more’s work previously:

Building a Golang backend based on a Retool application’s query library
Building five app screens in a new framework (SolidJS 2.0 RC) based on screencaps
Migrating from Golang to Mojo 1.0 (which has just gone open source and I wanted to try)
Migrating from PL/pgSQL to a query builder for SQL/PGQ graph queries (new in Postgres 19)
Writing a basic PostgreSQL driver for Mojo, since it doesn’t have one
Migrating from Python’s FastAPI (which I’m familiar) to Mojo’s Flare HTTP (which I’m not)

On the flip side, pure exploratory work always leads to cleanup work! In a work context, I’d just have selected a stack of boring choices and restricted the new ideas to product ideas rather than architectural choices. Even so, I was pleased that coding in Mojo worked so well, given how new it is and how little material the LLMs could have trained on (if any!).

Mojo could prove to be a big deal: write in Python-like syntax, but with consistency of a strong type system, and reliability of binaries for distributing a CLI tool. So far it is giving me a good user experience at the command line.

MVP Linear replacement done

The most important thing is priority number one has been implemented: a basic Linear replacement. I can now manage work from the command line with commands that the agents have had no problems working with given a few examples in AGENTS.md.

acme list Milestone --query '{"q":"ACME"}'

acme add Ticket \
--parent "$milestone_ref" \
--slug "ACME" \
--name 'Add agent ticket workflow' \
--properties '{"status":"open","priority":"high"}' \
--doc "<ticket description>"

The hypothesis at the heart of ACME is that a context manager needs to be flexible and accept most anything as an data point or document, but with the ability to apply consistent structure to your core concepts. Therefore, the nodes and edges of the graph have defined types, and each type has its own property schema.

Very simple conceptually, but also the foundations of an ontology system. Since the “vocabulary” of the tool is easy to adjust, I’m hopeful that I can build some useful workflows out of a few simple concepts.

In the examples above, you can see Milestone and Ticket nodes have been configured, and that Tickets have status and priority fields. The doc field allows you to store free text such as some Markdown content.

The MVP has a few other concepts like Projects and PRDs. As a nod to a past life working with Project Portfolio Management systems, I’ve chosen “Programme” in place of what Linear would call an Initiative. Altogether its a small vocabulary that will handle pretty much any scale of work - certainly enough for me. Fundamentally all systems like this boil down to a graph of to-dos.

It’s good having the experience to know the core design is already enough. I’ll refine the interface design, but can focus now on the broader question of context management for an entire programme of work.

Challenges of file versus graph

Even in just a couple of months of building an MVP there is a lot, and I mean a lot, of types of context that I use to get stuff done. As quick list of documents I might feed to an agent:

PRD
Related ticket descriptions
Architecture docs
Design mockups
Capability map
Runbooks
Documentation
Skills

That’s a lot! I’ve tried keeping all of this in the project repo itself, based on the philosophy that agents are good at finding what they need in a folder system. That’s different to what I’m more used to, which is a mix of documents stored in, for example, Google Drive, Slack, and Notion.

It seems obvious to give agents easy access to all the information it might need. To date, however, I’ve found that the naive approach of putting it all in the project workspace generates a lot of friction. Taking design mockups as an example, if I pull together a dozen mockups and then choose elements from just three to use in the application, a coding agent will inevitably be influenced by the nine rejected designs as well. There doesn’t seem to be any amount of guidance that will prevent this.

The challenge then is where to put all these “context items” if not simply including them in the repo. Perhaps it all goes into the knowledge graph, accessed via acme commands. I’m a huge fan of Obsidian and markdown, perhaps I just use a simple folder system and include references to the relevant sections via AGENTS.md. Maybe try something wiki or Notion like, although I find Notion’s interface too slow to really enjoy working with.

A basic knowledge graph I can use for ticketing and extend to ontologies was the must-have. Since I’ve no time pressures on “solving” context management I’ll keep just use a folder system to experiment with at first.