Shepherd: Multi-Agent Kernel

What inspired us

Git solved one of the hardest coordination problems for human software teams: code collisions. When two developers edit the same lines, Git tells us. But Git was never responsible for catching design collisions.

Humans handled those through communication. We discussed APIs, shared architectural decisions, challenged assumptions, and aligned on how different parts of the system were supposed to work before integration.

As we started working with multiple coding agents in parallel, we realised that this human coordination layer was disappearing. At first, failures looked like ordinary AI hallucinations. But many of the most dangerous failures were not technically wrong at all. An agent would make a perfectly reasonable decision given the context available to it. Another agent, operating with different context, would make a different reasonable decision. Both implementations could compile. Both could pass their scoped tests. Git could merge them without a single textual conflict.

And the combined system could still be wrong.

AI agents operate with bounded task context while the amount of project state, architectural history, implicit assumptions, and cross-team knowledge continually grows. The problem therefore becomes larger as agent teams become more capable and more parallel:

Local correctness does not guarantee system correctness.

That observation led us to build Shepherd.

Agent Actions enforced by Execution Contracts

We noticed another pattern in how people use coding agents.

Almost every serious prompt eventually contains some version of:

Implement this feature, stay inside these files, run these tests, make sure this behaviour works, and tell me when you are done.

We kept asking ourselves:

Why are we repeatedly asking the agent to remember the definition of success?

The agent performing the work should not also be the final authority deciding whether its own work is correct. So we moved the definition of success out of the prompt and into the infrastructure.

Shepherd turns every assignment into an Execution Contract: a durable specification of the objective, dependencies, scoped authority, expected artifacts, semantic claims, and mandatory acceptance criteria.

The agent can report what it did, but it cannot certify itself as successful. Shepherd independently verifies the resulting work using system-owned checks before the contract can become verified.

This changes agent execution from:

"Do this and tell me whether it worked."

into:

"Do this inside these boundaries. The system will decide whether it worked."

The Problem Git Cannot See

Independent verification solves local correctness, but it exposes the deeper multi-agent problem. Two contracts can both be independently verified and still disagree about a shared system assumption.

For example, one frontend agent may independently conclude:

auth.transport = bearer-jwt

while a backend agent independently concludes:

auth.transport = http-only-session-cookie

They modify different files. Their implementations are individually valid. Their tests pass. Git merges them cleanly. But the system boundary is incompatible.

Shepherd therefore allows independently verified contracts to expose evidence-backed Semantic Claims about the architecture they implemented. When those claims disagree across a shared system boundary, Shepherd detects a Semantic Collision even when Git sees nothing wrong.

This is the distinction at the heart of Shepherd:

Git detects when code cannot be merged. Shepherd detects when ideas should not be merged.

Speculate Before Escalating

Detecting every disagreement is useful, but sending every small decision back to a human would destroy the productivity benefit of autonomous agents. We therefore separated decisions by what actually requires human judgment.

Major architectural choices, ambiguous outcomes, and genuinely equivalent alternatives should remain human decisions.

But many agent disagreements are smaller implicit assumptions where the project itself already contains enough evidence to determine the answer. For those cases, Shepherd uses Speculative Resolution.

Instead of asking the human immediately, Shepherd freezes the integrated state and forks competing Resolution Planes from the same immutable commit.

Each future attempts a different reconciliation strategy. Each receives independent execution identity. Each is subjected to the same verification criteria.

The agents do not vote on the winner.

The verifier does.

If exactly one future satisfies the project's mandatory invariants, Shepherd selects it. If both fail, Shepherd promotes nothing. If both remain objectively valid, the decision is escalated to the human.

This gives us a practical division of labour:

Machines explore cheap, reversible uncertainty. Humans retain authority over consequential ambiguity.

How We Built It

Shepherd is implemented as a verification-first coordination middleware and transactional execution kernel around the existing Agent Launchpad rather than replacing it.

A Mission becomes typed Execution Contracts.

Contracts execute concurrently inside isolated Git-backed Contract Planes.

Agents never directly control protected project state. They work inside bounded execution environments, while trusted middleware derives the actual changes they produced and rejects anything outside their delegated authority. When execution finishes, Shepherd independently verifies the resulting immutable candidate using system-owned acceptance criteria.

An agent's own test results are useful evidence, but they are not authoritative. Only independent verification can move a contract into a verified state. Once individually verified contracts are integrated, Shepherd compares their corroborated semantic claims.

If a semantic collision exists, competing Resolution Planes fork from the exact same integration state and explore alternative reconciliations independently.

The winning candidate still cannot immediately modify protected state.

Shepherd performs final verification, checks the candidate's actual authority and diff, and confirms that the protected branch remains at the expected HEAD.

Only then can the trusted promotion path advance protected state.

The lifecycle becomes:

Contract → Isolate → Execute → Verify → Detect → Speculate → Verify Futures → Promote

Challenges We Faced

One of the hardest problems was defining semantic collision detection without pretending we had solved general program understanding. We deliberately avoided making an unprovable claim that an LLM could perfectly understand every semantic incompatibility between arbitrary programs. Instead, Shepherd makes important semantics explicit, typed, scoped, normalized, evidence-backed, and independently corroborated.

The deterministic collision system handles conflicts Shepherd can actually prove. Model-assisted analysis can help discover additional candidates, but it remains advisory and cannot verify, select, or promote protected state.

Isolation created another challenge. Telling an agent "do not modify this file" is not security. Shepherd therefore checks the actual resulting diff at a trusted boundary before integration and again before promotion. An agent can do almost anything inside its disposable world. What matters is that unauthorized changes cannot cross into protected state.

Promotion also had to be treated transactionally. A candidate that passed verification moments ago is not automatically safe to promote now. The repository may have changed underneath it. Shepherd therefore performs fresh verification and an expected-HEAD check immediately before promotion. If the expected protected state has changed, promotion stops rather than guessing. We also deliberately resisted trying to solve every infrastructure problem at once.

Shepherd is currently a focused proof of concept rather than a claim of production-grade multi-tenant isolation or globally distributed consensus.

We believe infrastructure is more trustworthy when its guarantees are precise.