Three developers, one night, zero meetings.

What they built

The application is called Apex. It's a Go REST API with JWT authentication, SQLite persistence, a full projects-and-tasks CRUD surface, and a companion CLI built with Cobra. Three separate agents wrote it. None of them spoke to each other. It compiled and the integration tests passed.

How it unfolded

Tom ran first, scaffolded the project, then manually wrote six architectural facts into Hydrate and pushed them to the shared team repo. Dick and Harry started in parallel after Tom's phase completed. In this experiment they accessed Tom's code directly via the shared Docker volume - the Hydrate context injection path for team facts is built but not yet wired into the hook. What you're seeing is the push side proven end-to-end, with the reception side one integration step away.

The six canonical facts

Tom didn't write a README. He wrote six Hydrate facts. Two were marked pinned, meaning they inject into every session for this project regardless of relevance scoring. The other four came in on keyword match. Together they were enough for two independent agents to build compatible implementations.

That's it. Six facts, two of them pinned. No architecture doc, no API contract, no synchronous meeting. Dick knew the port, the auth header convention, and the endpoint layout before he wrote his first line. Harry knew the same. Neither of them had to guess, and neither of them guessed wrong.

What a new developer actually gets

The difference isn't the code. Both paths have the code. The difference is everything that explains why the code looks the way it does.

What the team-pull injection looks like

Tom's six facts were committed to the shared Hydrate team repo via hydrate team push. In the full product flow, Dick runs hydrate team pull to import those facts into his local Hydrate store - and from that point the claude-context hook injects them automatically at session start. The two pinned facts appear unconditionally. The others arrive via keyword match. Here's what that injection looks like:

## Hydrate context - Apex project

[PINNED] infra.port
API runs on :8080. SQLite database at /data/apex.db.

[PINNED] auth.convention
All routes except /auth require Authorization: Bearer {token}.
Do not add any other auth mechanism.

auth.jwt
JWT uses HS256, 24-hour expiry.
Secret from environment variable APEX_JWT_SECRET.

auth.login_response
POST /api/v1/auth/login returns {"token":"..."} on success.

api.projects
GET/POST /api/v1/projects
GET/PUT/DELETE /api/v1/projects/{id}

api.tasks
GET/POST /api/v1/projects/{id}/tasks
PUT/DELETE /api/v1/projects/{id}/tasks/{taskId}

---
6 facts · 2 pinned · from Tom via hydrate team pull

In the APJ experiment, this injection path wasn't yet wired into the hooks - Dick and Harry read Tom's code directly from the shared Docker volume instead. The facts existed in Hydrate's team repo. The last step - automatically surfacing them into a new developer's session - is the integration gap this test identified. The point stands: once you pull, you don't have to guess.

What worked and what didn't

This is the honest section. Not everything ran as smoothly as the headline suggests.

The honest takeaway: the push side is proven, the reception side is one hook integration away. Even in this incomplete state - facts in the repo but not yet auto-injected - three agents produced a compatible, mergeable codebase in under an hour. The gap between "this is working" and "this is fully automatic" is narrower than this experiment makes it look.

Why this matters

Software projects have always had a knowledge distribution problem. The code captures what you built. Git history captures when and in what order. Neither one reliably captures why.

"Why HS256?" is a question a new developer would have to ask someone. If Tom is unavailable, they'd have to infer it from the code, get it wrong, and open a PR that switches to RS256 for "security reasons." Then someone who does know has to explain in a review comment why the change isn't actually an improvement. That conversation happens months after Tom made the call, in a thread most people won't read.

Hydrate is a bet that the decisions behind the code are more durable than the review comments that happen to record them. A fact written once, pinned to a project, injected into every session - that's a different class of institutional memory than a Slack message or a PR comment.

In this experiment there was no README. Tom wrote six facts; Dick and Harry read the shared code. In the full product flow those facts inject into every new developer's session automatically - the experiment proved the push side of that pipeline end-to-end. The reception side is one hook integration away. What the APJ test shows is how small the minimum viable knowledge transfer is: six facts, two of them pinned. That's a low bar to clear, and clearing it produced a working multi-agent codebase in under an hour.