The content management systems of the 2000s and 2010s solved a real problem. They gave
content a shape: defined types, structured fields, lifecycle states. A blog post was
not just a row in a table. It was a thing with a title, a body, a status, a
publication date. It could be in Draft or Published or Archived. You could list all
published posts. You could prevent a draft from being served to readers.
This was good thinking. Typed data and explicit states make software more correct and
more predictable. The CMS world figured that out early.
But CMSes were built for one kind of operator: a human working through a browser. The
API was an afterthought. Relations between content items were baked into the UI or
bolted on as plugins. The whole system assumed a person was making the decisions.
That assumption is changing. I started thinking about this in February, and started
building.
The premise was simple: agents need the same things CMSes were built around, typed
data, explicit states, relations. But through a protocol, not a UI, and with enforcement, not just convention. An agent that talks to a typed content layer knows
what fields exist, knows what state transitions are valid, and gets a typed error when
it tries something illegal. The lifecycle is not in the prompt. It is in the layer.
I had been building this for a couple of months when Andrej Karpathy posted about his
LLM Wiki. His pattern: instead of running RAG over documents every time, have an agent
build and maintain a persistent wiki of structured, interlinked markdown files that
compounds over time. His framing was: "Obsidian is the IDE. The LLM is the programmer.
The wiki is the codebase."
It was a good confirmation that the need is real. Agents need persistent, structured,
queryable knowledge. Not a raw database. Not a chat history. Something shaped.
But it also showed clearly where markdown stops. There is no enforcement in a markdown
file. There is no state machine. There is no way to say "this decision is Active and
blocks these goals" and have that mean something to the agent beyond text it was told.
Relations are backlinks, great for a human reading a graph view, but not a typed edge
a system can query and act on. And it is local, one developer, one machine.
What if you took those same ideas and built them with enforcement instead of convention?
Typed content means the agent knows what fields exist and what they accept. Explicit
state machines mean invalid transitions are rejected at the protocol level: an agent
cannot publish a draft that has not been through review, because the framework refuses
the transition, not because the prompt told it not to. Typed relations between items
form a persistent edge graph the agent can query: what depends on this item, what
decisions are related to this goal, what jobs produced this output.
The access layer is MCP. The agent calls tools, not endpoints. The tools carry the
shape and the constraints.
This is where the use cases go beyond content management.
Relations and edges can model "this article cites this source," but also "this decision
blocks this goal" or "this agent job produced this output." The same primitives that
power a content graph can power orchestration, memory, context management. An agent
that starts a session can query the graph for active goals, related constraints, and
decisions that are still live. It works within a structure that was built for it to
reason over, not a structure it has to interpret from prose.
CMSes touched this space and stopped at the browser. Karpathy's wiki takes it further
but stays in flat files. The next step is typed edges with enforced lifecycle, queryable
by agents through a protocol designed for them.
That is what I am building with Smeldr: an open source Go framework where content
types have explicit lifecycle states, relations between items are typed edges in a
persistent graph, and agents interact through MCP tools that enforce the rules rather
than expose raw data.
It started as a content backend. The further I get into it, the more it looks like
something more general: a typed, stateful graph that agents can safely operate a whole
system through.
The CMS people were onto something. Karpathy is onto something. I think the next piece
is putting enforcement and typed relations underneath it.
Smeldr is open source, written in Go, no build pipeline required.