Yggdrasil
I’ve been exploring Datahike lately, and one chart from their Yggdrasil work caught my eye:
| Protocol | Operations |
|---|---|
Snapshotable | snapshot-id, parent-ids, as-of, snapshot-meta |
Branchable | branches, branch!, checkout, delete-branch! |
Graphable | history, ancestors, common-ancestor, commit-graph |
Mergeable | merge!, conflicts, diff |
Overlayable | overlay, advance!, merge-down!, discard! |
Watchable | watch!, unwatch! |
GarbageCollectable | gc-roots, gc-sweep! |
Addressable (optional) | working-path |
Committable (optional) | commit! |
Yggdrasil asks a simple question: what if every storage system spoke the same branching language? Their answer is a set of -ables.
A database, vector index, filesystem, data lake, search engine, and container layer all have different internals. Yet many share the same vocabulary. The insight isn’t that these systems are the same. It’s that they expose the same capabilities.
Capabilities over identities
At first glance, the -ables look like object-oriented abstractions under a different name. But I think they point at something fundamentally different.
Objects organize around identity. Protocols organize around capability. They don’t ask what something is. They ask what it can do. A protocol is the closest noun we have to a group of verbs.
A Snapshotable system doesn’t need to reveal its nature. It only needs to define how snapshots are identified and how history is addressed. A Mergeable system doesn’t need to become Git. It only needs to support a small set of merge operations.
The protocol defines the promise. The implementation is free to vary.
The new public/private boundary
Software has always separated what can change from what must remain stable. Object-oriented systems expressed this through public and private methods. APIs separated interface from implementation.
Agents raise the value of that distinction because they make implementation itself increasingly disposable. Given a vague noun like “memory layer” or “workflow engine,” an agent can generate a plausible implementation. The difficult part is no longer producing code. The difficult part is preserving the guarantees that matter.
This shifts the center of gravity for architecture. Instead of focusing primarily on how a system is built, we spend more time defining what must remain true regardless of how many times the implementation changes.
A capability is public. An implementation is private. Branchable is public; the branching algorithm is private. Mergeable is public; the conflict-resolution strategy is private. The capability defines the promise. The implementation defines one way of keeping it.
As implementations multiply, the public surface must become smaller, clearer, and easier to test. The stabilizing force is no longer the implementation itself. It is the capability boundary.
Negotiable nouns
Waterfall tried to stabilize the plan. Agile tried to stabilize the feedback loop. Agent-native software may need to stabilize capability.
As implementation becomes fluid, architecture becomes the practice of deciding what remains invariant. The public side of a system shrinks toward a handful of capabilities, contracts, and tests. The private side expands into a growing space of implementations that can be generated, revised, replaced, and discarded.
So, specify the verbs that matter but keep the nouns negotiable.
The future may belong less to objects, services, and frameworks than to capabilities. Not because protocols are new, but because implementation is becoming disposable. Capability may be the most durable thing left.