I think the most important open question in software right now is how you use a model as an agent, and my answer is graphs.
An agent is a fast, tireless, literal worker with no memory of why. Hand it a task and it produces something that runs. Whether that something matches what you meant is a separate question, and it’s the question that decides whether agents are actually useful or just quick at making a mess.
The failure mode is always the same. You give the agent loose context, a paragraph of intent and a pile of files, and it fills the gaps with guesses. A POST where you specified GET. A route mounted at the wrong path. A write to a table that was supposed to be read-only. Each one is small. Together they’re drift, and drift is how a system quietly stops matching its own design.
So the thing I keep chasing is this: feed the agent deterministic, structured data about the system, and it stops guessing. Give it the exact shape of what you want and it builds against that shape. Sequence is my attempt to make that real.
You start on an infinite canvas and draw the system: services, data stores, the edges between them, the contracts on those edges. That drawing isn’t decoration. It’s a structured file, archgraph.json, and it’s the source of truth.
From the graph, an agent scaffolds the real repo: the routes you specified, the stores you declared, wired the way the edges say. The graph is the spec, and the first version of the code comes out of the spec instead of drifting from it on day one. The agent builds the architecture you drew.
Then the loop closes in both directions. sequence scan reads the generated code back into the graph, so the canvas reflects what’s actually in the files. And sequence diff compares the two. When the implementation stops matching the spec, wrong method, wrong path, wrong table, diff exits 3. In CI, a non-zero exit is a failed build.
That’s the part I care about most: spec-drift becomes a CI failure class.
We already treat a broken test as a red build. A failing type check, a lint error, a formatting slip, all of them block the merge automatically, which is why they mostly don’t happen anymore. Architecture never had that enforcement. It lived in someone’s head and a diagram that went stale two sprints ago, and it relied on a senior engineer noticing in review. Reviewers are busy and human.
Put the architecture in CI and it stops being a matter of vigilance. The build knows the shape you agreed on. The moment the code walks away from it, the pipeline says so, in the same breath it complains about a type error. No meeting required.
There’s a second way in, for systems that already exist. Reverse mode reads a repo statically, its compose file, its Kubernetes manifests, its Helm charts, and infers the graph from what’s there. You don’t have to start greenfield to get a checkable picture of what you actually built.
The whole thing is local-first and runs on 127.0.0.1. Your architecture isn’t something I want to see, and it doesn’t need to leave your machine.
Here’s where I think this goes.
As agents write more of the code, the scarce skill stops being typing and becomes specifying: describing the system precisely enough that a literal worker builds the right thing. That specification has to live somewhere machine-checkable, or it’s just a suggestion the agent is free to ignore.
A graph is a good home for it. It’s the contract between what a human meant and what the agent produced, and unlike a diagram on a wiki, it fails the build when the two disagree. This is the same idea underneath everything I’m working toward: the way to get accurate, trustworthy work out of a model is to hand it structured, deterministic ground truth and check its output against that ground truth, automatically, every time.
The more code agents write, the more that contract is worth having. I’d rather review a diff against the architecture than squint at 4,000 lines hoping to notice the shape changed.