Coordination and Traceability: Not Two Problems
With the security world ablaze, it's the worst week to say this, but: agents and humans need shared infrastructure for coordination.
Steve Yegge's Gas City and Block's Buzz and CrewAI and the wonderful Hermes Kanban are better than named folders in Artifactory ("HOLD SWARM"!). But there's either a tenuous connection between cause and effect, or limited traceability.
And that's not really an accident. In 2011, Geoffrey Moore named the distinction between "systems of record" (traditional IT) and "systems of engagement" (loosely-structured, collaborative, social networking). Nowadays our work lives are dominated by the friction between these two, and agentic AI makes that friction very expensive.
When I read Google's Beyond Zero security architecture, there's clearly an urgent need for traceability and control in all the things we expect agents to do. But if an agent is tagged in Discord and goes off to update a production system with a misguided or dangerous effect, is their control loop actually strong enough?
Sean Grove, then at OpenAI, set the direction last year in "The New Code":
Once you put your code through a compiler and get a binary out, no one is happy with that binary. The binary wasn’t the purpose - it’s useful, sure, but we always regenerate binaries from scratch every time we compile. The source is the valuable artifact.
And yet with prompts, we do the opposite. We keep the generated code and delete the prompt.
This is like shredding your source code and then very carefully version-controlling the binary.
As the work-product of software development moves from "shipping is a feature" to "personal, modifiable apps", the application really does look like an ephemeral byproduct of the process of building it. "Everything is a fold over a log", as the dataflow mantra goes.
But in practice, our prompts -> traces -> spec -> results are disconnected, and the processes that wrap around this iteration are hard to integrate.
Grove started his talk with: "When I look at my calendar, the code I write is maybe 10-20% of my time. The rest? It’s all communication. Specs, docs, emails, Slack messages, meetings about what we’re building and why". But honestly, the calendar doesn't really know how much time you spend coding, and neither does Slack. Maybe they could.
It's even worse outside software development tasks. Does your public documentation ever get stale? Mine does, and often it's customers who notice before we do. Keeping the docs up-to-date is nobody's favorite job, and a prime candidate for LLM-based automation -- but traceability, identifying exactly which pieces have diverged from the spec or the implementation, is the hard part.
Every document in your organization is a cache, and nothing invalidates it.
We need a system where outputs are built on a signed history of consequential acts. Where every rendered artifact points at the log position it was projected from. If its basis moves, the document knows when it needs to be refreshed.
ActiveGraph gets the big thing right -- log as source of truth, graph as projection -- but those benefits accrue to the agents inside it. I tried something similar with woah and now prefer a more composable approach: "small pieces, loosely joined".
The applications for this are quite extensive. "Real SDLC for vibe-coded apps". "PMO in a box". "Automatic timesheets". OK, enough; I'd better get concrete before McKinsey sees this.
Introducing gitseq
The first layer of gitseq is so tiny it's almost trivial. Add a sequencer to git, giving consequential actions a durable order at the door.
Why? Suppose one agent says, "I'm changing the auth API," and another replies, "OK, I'll update the docs." The docs land first; the implementation arrives later, on another branch. Git beautifully preserves both commits and their ancestry -- but not the reason they belong together.
gitseq gives those earlier actions somewhere to live, with the same durability as commits, plus signatures. Actions can be work notes, tasks, replies -- anything. While git already tracks commits, gitseq lets the same history begin earlier, while the work is happening.
There's also a tiny realtime service, which supports fully ephemeral chat and "presence", so you can see which identities are active and what they're doing "right now". Presence and chit-chat don't need to survive in the sequenced record, but consequential actions do. The ephemeral layer is an essential part of pointing at things.
Above this, a bigger layer deals with meaning: what the things are, how they are related. Workflow, if you like, where the sequencer doesn't care about the ontology. The core vocabulary here is for tracking commitments, heavily influenced by the language-action perspective: requests, promises, conditions of satisfaction. I expect this layer to grow "sideways" into other domains, because each project needs its own process language; it's intended to be customized.
With this foundation, you have enough to deploy a swarm of coordinating agents, and people, and get real work done together in a manageable, steerable, inspectable way. Each participant has a strong identity, and the work really tracks itself, all the way to the deliverables.
Like many early-stage projects, I swing between "this is way too ambitious" and "there's nothing much here". It's only been used on itself, so far; one human, a handful of agents. There's some plumbing but not a lot of porcelain. Even the primitives are primitive. It doesn't have semantic indexing. And, I haven't yet run it in Kubernetes.
But it's ready to be seen and tasted.
gitseq doesn't add traceability to coordination: it uses the same history for both. If you're building with collections of agents and can't tell exactly what happened, in what order, on whose instruction: this is for you.