Worktree isolation
Each agent owns a sandbox. Semantic search and file leases happen in separate transactions.
FLEET EVENT / TIMESTAMPED ACTIVITY
COMMITTED ROW / AUTHORITATIVE
Hackathon judge demo
Five coding agents. One shared repository.
Run eleven overlapping tickets with worktrees alone, then with CORTEX, and inspect both returned applications.
The task order, ticket set and database are identical in both arms. Only coordination changes.
Read this before you press it. No two runs of this page are the same, and that is the point. Five agents work at once against one live cluster, so which agent wins a race, which duplicate is caught first and which defect survives into the returned application are decided while you watch. Some hazards will not fire on your run. A lane that failed identically every time would be a recording, not a system.
CONNECTING
Waiting for the demo backend. The page labels simulated preview data separately.
CORTEX coordination layer
What CORTEX does during one task.
These five actions are the mechanism. The animation below uses the same actions reported by the running agents.
- Describe workThe agent submits the intended change before editing files.
- Check meaningA vector search finds semantically equivalent work, even when ticket wording differs.
- Claim filesThe duplicate check and every required file claim commit in one serializable transaction.
- Re-planA blocked agent receives the holder and intent, then chooses different work instead of polling.
- Store outcomeCompleted or abandoned work becomes repository-scoped memory for later agents.
The same workload runs through two coordination systems.
Each lane reports agent activity and committed rows separately. Nothing is marked successful before the returned file tree is inspected.
CORTEX arbitrated memory
The same semantic search and file claims succeed together or neither does.
FLEET EVENT / TIMESTAMPED ACTIVITY
COMMITTED ROW / AUTHORITATIVE
Everything above this line happened before the run stopped.
Five agents, at the same time, on one change.
Every bar below is one agent's own elapsed time on one ticket, drawn from the timestamps it streamed. Bars that overlap were running together.
Run the fleet. The figures above are computed from the run's own streamed timestamps and appear as it goes.
work committed
blocked, holder named, re-planned
refused as duplicate
spared by an earlier outcome
gave up, wrote the reason down
could not commit
time this agent never spent
two agents holding one file at once
The two arms run one after the other so that neither lane's claim latency is measured under the other's load. Each lane's clock therefore starts at zero, and the shared scale compares elapsed time inside a lane, not one common wall clock.
Watch the agents perform development work.
Each card shows the active ticket, repository file and current action. A connector moves only when that agent emits a fleet event.
CORTEX transaction
Intent search and all file claims share one serializable snapshot.
Waiting for fleet events.
Why this workload can fail.
The tickets create three different coordination hazards. Worktrees handle none of them before agents start editing.
Two duplicate pairsP2 and P6 request the same outcomes using different wording and different modules.
Three agents, one fileC1, C2 and C3 change separate behaviors inside orders/repository.js during overlapping windows.
Two decision chainsShipping and refund work must reuse choices made earlier by the money and payment tasks.
Compare what each system returned.
Both file trees come from the database and run without network access. The verdict below uses those trees and the terminal meters.
Waiting for both arms
No verdict is calculated until both terminal summaries and both file trees exist.
No result yet
Run the workload to compare duplicated work, lost writes and file collisions.
Worktree result
Waiting for the run to finish.
CORTEX result
Waiting for the run to finish.
Each row is decided by running the returned application and asking it a question, not by searching its source for a string. The evidence is what the application answered.
Run-level figures appear only after the terminal message. A measured zero is shown as 0. Not applicable is N/A. Nobody measured it is TBD.
SHOW TRANSACTIONS
Run the fleet to load the grouped transaction transcript.
What changes inside the database.
These are the mechanisms used by the CORTEX arm. The published benchmark remains separate from this demo run.
Duplicate check and claim are atomic.
The search and every requested file claim commit together, or neither does.
semantic duplicate searchONE BEGINall file claims
Meaning, not ticket wording.
Titan embeddings are compared in the cluster. The mechanism threshold is disclosed separately from the benchmark judge.
distance < 0.39 / refuse duplicate
All or nothing.
A blocked agent learns the holder and the intent. It can re-plan instead of polling.
Outcomes become memory.
Completed and abandoned work becomes a durable finding scoped to the repository.
The fleet sees commits.
The change stream delivers database rows. Activity events remain separately labelled.
Published benchmark, median of three replay runs.
Same 30 tasks, five agents and recorded reasoning in both arms. Database behavior is live. Small synthetic corpus; serialized harness; CORTEX recall is outside that harness.
0.00CORTEX duplicate work rate / naive 0.21
0CORTEX lost writes / naive 21
0CORTEX conflicting edits / naive 3
867CORTEX wasted tokens / naive 4000
source: bench/results/2026-08-12T18-35-38-014Z
Checks outside the animation.
Row-level security isolates every demo scope.
Three least-privileged database principals.
Serializable transactions with bounded retry.
A degradation ladder keeps the page readable.
Infrastructure described as code.
The suite runs against a real cluster.
What judges should verify.
The two arms receive the same tasks and patches. CORTEX changes only the coordination path. Every result shown above is tied to streamed activity, committed rows, terminal meters or the returned file trees.