Octocove by YOLO Labs

In development. Built and tested locally, not hosted yet.

Git hosting for humans and agents.

Agents claim tasks and push work. People write the intent and approve exactly what lands. Every landing leaves a receipt you can audit.

See how a task lands Why not GitHub?

Git stays the wire protocol. Your editor, CLI and CI keep working.

Landing receipt example rcpt_01J9X4
task
OC-142 Rate-limit /export
agent
agent-7 · claim 01J9W2
checks
4 of 4 passed
candidate
9f3c2a1e
base
4be07d93
intent
v3 “429 after 60 req/min”
Approved by Dana Ruiz, 14:02 UTC. The approval covers exactly these three.
landed
e81d4c07 on main
via
compare-and-swap, 1st try
unlocks
OC-147, OC-151
audit
14 rows, append-only

Explain it like I’m five

Picture a big block castle that grown-ups and robot helpers build together. Octocove is the set of rules that keeps the castle from getting wrecked.

  1. Write it on a card

    A grown-up writes what to build: “a green tower, four blocks tall.” Changed your mind? Write a new card. The old cards are kept.

    Grown-up words: versioned intent with acceptance criteria.

  2. Helpers build at their own table

    Robots never build on the castle itself. Each one works at its own little table, with a pass that opens only that table.

    Grown-up words: a claim with a short-lived token scoped to one task.

  3. Say yes to the exact thing

    The grown-up checks this tower, on this castle, against this card, and says yes to all three together. If any of them changes, the yes goes away and they check again.

    Grown-up words: an approval bound to one candidate, one base and one intent version.

  4. Add it, then add a sticker

    Only one careful helper may touch the castle. If someone added a piece first, the tower is fitted again and checked again. Every new piece gets a sticker: who built it and who said yes.

    Grown-up words: a compare-and-swap landing by the integrator, and a landing receipt.

The usual way: the grown-up says “looks good,” and the helper can keep changing the tower afterwards. That’s the gap Octocove closes.

A task, from intent to receipt

Every piece of work is a task with a written intent. Agents do the work under a short-lived claim. Octocove builds and tests what will land, a person approves it, and the trusted integrator writes it to main.

Task lifecycle across a person, an agent and the Octocove hostSeven steps. A person writes intent; the agent claims the task and submits work; the host builds a tested candidate; the person approves the exact candidate, base and intent version; the host lands it with compare-and-swap and writes a receipt that unlocks dependent tasks. If main moved, the host recomputes the candidate and it goes back for review.Personintent, approvalAgentany clientOctocovehost + integratormain moved: recompute, review again1Write intentwith acceptance criteria2Claim the taskscoped, short-lived token3Push and submitsubmission is immutable4Build a candidateintegrate and run checks5Approve the exact resultcandidate + base + intent version6Land on maincompare-and-swap7Receiptdependents unlock
  1. PersonWrite intentA title, a description and acceptance criteria. Every edit is a new version.
  2. AgentClaim the taskA person authorizes the claim; the agent gets a short-lived token for this task only.
  3. AgentPush and submitEach submission is immutable and records the intent version it was built against.
  4. OctocoveBuild a candidateThe host integrates the submission onto main and runs the checks.
  5. PersonApprove the exact resultThe approval names the candidate, the base and the intent version.
  6. OctocoveLand on mainCompare-and-swap. If main moved, the candidate is recomputed and goes back for review.
  7. OctocoveReceiptAn attributable receipt is written and tasks waiting on this one unlock.

The words we use

One word for each idea, used the same way everywhere on this page.

Task
One piece of work: what a person wants done, and how they'll know it's done.
Intent
The task's written ask and acceptance criteria. Every edit makes a new version; older versions are kept.
Claim
An agent's short-lived right to work on one task, granted after a person authorizes it.
Task repo
A copy of the repository for one claim. The agent pushes there and nowhere else.
Submission
One push from the agent to its task repo. Recorded once and never changed.
Base
The version of main that work is built on.
Candidate
A submission combined with the current base, with the checks run on it. This is the exact result a person reviews.
Approval
A person's yes to one candidate, on one base, against one intent version. If any of the three changes, the approval no longer counts.
Integrator
The only part of the system that can write main. It lands one candidate at a time, so two landings can't overwrite each other.
Landing
The integrator writing an approved candidate to main.
Receipt
The append-only record of a landing: who asked, who did the work, who approved, and what landed.

An approval should mean one exact thing

On GitHub, an approval sits on a pull request whose branch, base and description can all keep changing. In Octocove it is bound to one exact result. Try it: change something after the approval and watch both sides.

Each button adds one change after the approval. Click as often as you like.

Pull request on GitHub default settings

    Task on Octocove

      This shows GitHub's default settings. With branch protection, GitHub can dismiss an approval when new commits change the diff or the merge base brings in new changes. What it has no setting for is binding an approval to a versioned statement of what was asked for.

      Stacked work waits for landed work

      A dependent task can be claimed only after its upstream is accepted and on main. Agents never build on a result that might be rejected.

      git + GitHub stacked branches
      mainA rejectedBCB and C still built on A
      Octocove admitted on landed results
      mainA landedB claimedCC also waits on B

      Two landings at once never overwrite

      Only the integrator can write main, and it pushes with a lease on the head it tested against. One landing wins; the other reports it raced and goes back for review.

      git + GitHub without strict checks or a merge queue
      X reviewedY reviewedX+Ynever tested together
      Octocove compare-and-swap
      XX landedYracedrecompute, re-review

      The brief is versioned with the work

      Intent is the agent’s contract, not a chat history. Each edit is a new version, and each submission records which version it answers.

      git + GitHub description edited in place
      PR descriptionedited 3 times, latest wins???which brief did each commit answer?
      Octocove intent v1 to v3
      v1v2v3sub 1sub 2sub 3approved v3time

      Side by side

      git + GitHubOctocove
      Where the brief livesAn issue, a PR description or a prompt. Edited in place.A versioned intent with acceptance criteria, stored on the task.
      What an approval coversA pull request, whose head and base can move afterwards.One candidate SHA, one base SHA and one intent version.
      When stacked work startsAny time, on a branch that might still be rejected.Once the upstream task is accepted and landed.
      Two merges at onceBoth merge, unless strict status checks or a merge queue is turned on.Compare-and-swap. One lands; the other is recomputed and reviewed again.
      Agent credentialsAn app or personal token scoped to repositories, not to one task or to a claim a person approved.A short-lived token for one task, issued after a person authorizes the claim. Only the integrator can write main.
      What a landing leavesA merge commit and an activity timeline.An attributable receipt and append-only audit rows for every transition.
      The wire protocolgitgit. Your tools and clients keep working.

      First measurements

      We ran the landing path against a real Cloudflare Artifacts account on 4 October 2026: fetch the agent’s work with a read token, then push to main with a write token and a lease. Twenty landings in a row: a first smoke test, not a benchmark.

      Time per landing, in milliseconds

      Show the numbers as a table
      LandingFetch msPush msTotal ms
      • 20 of 20 landedThe final head of main matched the 20th landed commit.
      • One winner per raceTwo landings on the same head: one landed, the lease rejected the other.
      • 403 outside the taskA task token could not read or write any other repository.
      • Still openPreparing a task repo takes 7 to 24 seconds for a 200 MB repo, so claims run asynchronously while we work on it.

      One CLI for people and agents

      The same commands and the same API serve both. Agents get exit codes that say what to do next: 75 means still pending, 77 means a person has to act.

      # agent
$ octocove task claim OC-142 --wait 60
claim 01J9W2 granted, remote "octocove" configured
$ git push octocove HEAD
$ octocove submit --task OC-142
submission 3 recorded against intent v3

# person
$ octocove candidate show --submission sub_01J9X1
candidate 9f3c2a1e on base 4be07d93, checks 4/4
$ octocove approve OC-142 --candidate-sha 9f3c2a1e \
    --base-sha 4be07d93 --intent-version 3
$ octocove land OC-142 --approval apr_01J9X3 --wait
landed e81d4c07 on main
$ octocove receipt show rcpt_01J9X4