Models are fungible.
Coordination is not.

01 / Proof

The thesis, working in the wild

A few weeks ago I set up a small experimental rig at home. Claude Code as the developer agent. Claude AI as the adjudicator. Codex as the QA agent. Three roles, three agents, one task. I expected to spend the evening tuning prompts.

That was the thesis arriving uninvited. When the coordination layer is real, agents stop behaving like tools and start behaving like a team. They notice gaps a human architect missed. They argue about who should hold which responsibility. They reorganize themselves around the work rather than around the prompt. That is not a parlor trick. That is the shape of the next computing primitive.

02 / Practice

Practice, not theory

This is not a description of a system we plan to build. It is a description of a system we already use on ourselves. The agent coordination workflow we are productizing in wterm Collaborative is the workflow we already run to make and review DVC's own company surface, including the process behind this prospectus.

The setup pairs a builder agent and a reviewer agent from different model families and gives the reviewer real authority to push back. It surfaces a class of correction a same-family review tends to miss. A builder will commit to something confidently, and a reviewer from a different lineage will name a structural problem the first agent could not see, the way a fresh pair of eyes catches a flawed argument the author has stopped questioning. The architecture, not the prompt, is what produces the correction.

This is local proof, not a packaged claim. We are still building the product around the workflow. The claims in this document are not theory. They are observations from a system we already run.

03 / Build

What we are building

The flagship is wterm Collaborative. A sandbox where a user drops in a problem and three agents, a developer, an adjudicator, and a QA, self-organize, communicate, and deliver an output the user can actually use. No orchestration script the user has to author. No graph the user has to draw. The agents figure it out, the same way a small team of humans would.

Underneath wterm Collaborative is the part that matters more than the surface. Persistent memory built as a context graph rather than a SQL table or a retrieval pipeline glued onto a vector store. A coordination layer that treats vector indexes and knowledge graphs as one substrate rather than two boxes wired together at runtime. The reason this combination matters is not technical novelty. Durable agent collaboration requires durable shared state, and durable shared state requires a representation that handles meaning and structure at the same time. We have that working.

The roadmap moves in three steps. First, the three agent sandbox users touch on day one. Second, interconnected clusters that pass work between sandboxes without losing context. Third, hierarchies of thirty or more agents that manage themselves with no human orchestrator in the middle.

04 / Method

A different design philosophy

Most agent platforms shipping today are structured consistency frameworks. They constrain what each agent can say, in what order, with which tools, on which step. Lovable and Rapport both fall in this bucket. The result is predictable behavior on the happy path and brittle behavior outside it. The platform is doing the thinking. The agents are doing the typing.

DVC is built on a different principle. Call it emergent determinism. Tight constraints at the edges, defined outcomes at the end, and the path between left to the agents to negotiate. We do not script the conversation. We script the boundary. The agents fill in the middle, and the constraints stop them from going off the rails.

This requires a discipline most agent companies do not have. Operational decomposition. Knowing how to take a hairy problem and chunk it into pieces an autonomous system can execute without scope creep. That skill comes from years of doing this work with people before applying it to agents. You cannot read it in a paper. You build it by running real systems and watching them fail in instructive ways.

05 / Route

Distribution

We are launching on the GCP Marketplace. The reason is simple. It puts paying users on day one and it tells us within weeks whether the thesis works in someone else's hands, not just ours. Marketplace placement is a validation engine, not just a sales channel. If enterprises buy it and renew, the thesis is real.

It also sets up a clean exit path. The natural buyer for a coordination layer that runs cleanly on a hyperscaler is the hyperscaler. Google buys the stack, integrates it into GKE, and every enterprise on the platform spins up agent hierarchies as a utility, the same way they spin up Kubernetes clusters today, without ever having to learn what is happening underneath.

06 / Seed

The raise

We are raising one to two million as a seed round. The capital splits cleanly. A material portion goes into hardware infrastructure, which is collateral and does not evaporate. The rest funds runway to ship the marketplace MVP and put it in front of paying users.

The thesis is already proven locally. The architecture works on hardware we own, with agents we run, on real tasks. We are not raising money to discover whether this can be built. We are raising money to scale what is already working.

07 / Infinite game

The infinite game

Coordination, not raw capability, is the next frontier. The teams racing to own the model layer are competing for an asset that is becoming a commodity faster than anyone wants to admit. We are not playing that game. We are playing the longer one, the one that does not end when a single model wins or loses, the one where the abstraction layer keeps mattering after individual models stop being interesting. The team that gets the coordination layer right early is the team the next decade of software gets written on top of. We intend to be that team.