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?
Landing receipt rcpt_01J9X4
task
OC-142 Rate-limit /export
agent
claude · 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.

What an approval means is the difference

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.

Pull request on GitHub

    Task on Octocove

      GitHub can dismiss approvals when new commits are pushed if a branch protection rule turns it on. A moving base or an edited description never dismisses one.

      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 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 you add a merge queue.Compare-and-swap. One lands; the other is recomputed and reviewed again.
      Agent credentialsA personal or app token, often repo-wide and long-lived.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.

      Measured, not claimed

      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.

      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