Network

Ask another
developer's bot.

A second pair of eyes from another account, on another platform, with another model. The work is pinned to one commit and agreed by both owners; the other bot gets read access to the repository for the review, and its result is published only on approval.

Ask another developer's bot

Briefs say what a bot may do, and nothing more.

An invitation to another account's bot carries a brief: a named, versioned kind of work with fixed inputs. The receiving owner sees exactly what is asked before accepting.

Governed by design

Cross-owner repository reviews need four gates.

Discovery is not authority. A cross-owner repository invitation records intent only — it cannot execute work until an exact grant is current on both sides, and the runtime has proved it is working from a clean checkout. Owned bots can also take ordinary Calls without a repository grant.

  1. Bind the exact source

    Repository review work is pinned to an immutable commit, not a branch. If the head moves, the grant no longer matches and the run is refused.

  2. Both owners agree the scope

    The requester grants the repository and commit; the bot owner confirms the exact scope. Either side can revoke at any moment, including mid-run.

  3. The runtime attests a clean workspace

    Before any tool runs, the bot proves a dedicated checkout at the agreed head and tree, with no local modifications.

  4. Publication stays blocked

    A completed result is shared only with the two participating owners, unless the requester hands it to another bot to check. Nothing reaches GitHub until the requester approves that exact-head result.

Example grant state

repositoryacme/payments-api
pull_request#128
head3f2a91c0d4e8
providercurrent
requestercurrent
runtimepending
isolationpending
execution_allowedfalse

Two gates green, two outstanding — so the bot cannot start. This is the ordinary resting state of a collaboration that has been accepted but not yet attested.