00 / CLI and MCP source control for agents.

Agent-native source control.

Gets it done.

BitterGit is Git-compatible source custody for agent runs. It keeps the repository semantics developers already trust, then attaches signed run and wake provenance, run-level review, and BitterGrid verification receipts around agent work.

Open the run, not a bot account. Accept or revert the whole blast radius with the receipts attached. Today the Bitter fleet is tenant zero; external accounts are request-only.

Request early access See first run →

Native gitRepos keep ordinary Git semantics; BitterGit adds source-custody context around agent work.

Signed trailersAgent commits carry Run-Id and Wake-Id provenance stamped at commit time.

Verified receiptRun review can include the build, test, probe, accept, and revert trail.

01 / First run contract

Try the primitive before you ask for the account.

A developer should understand BitterGit from one run: native git goes in, signed provenance comes out, and the verification receipt travels with the change.

Current status: the Bitter fleet migration and receipt shape are being proven first. Public account access is by request, not self-serve signup.

Expected receipt✓ verified

Run-Id is present and signed.
Wake-Id links the change to the request.
Verified-By points to the BitterGrid build.
Decision records accept, revert, or supersede.

Wrap the repo you already have.

$bitter git clone team/service

BitterGit does not ask developers to learn a replacement VCS. The wrapper adds provenance around normal git operations. The public marketing root is not itself the Git remote endpoint.

Let the run make the commit.

$bitter git commit -m "tighten deploy verifier"

The Bitter CLI stamps the run trailers and signs the commit with the run-scoped key before it leaves the machine.

Review the receipt, not the bot account.

$bitter git run show run_4f2a --receipts

The review surface groups every touched repo by run and shows the BitterGrid verification that cleared or rejected it.

02 / Why BitterGit exists

GitHub was built for human teams. Agent work has a different shape.

A human team produces pull requests — artifacts to discuss, review, approve, merge. An agent fleet produces commits by the hundred, grouped by the run that made them. The atomic unit shifts. BitterGit is shaped for that.

Run-linked by construction

Every agent commit should carry a signed Run-Id and Wake-Id trailer, stamped by the Bitter CLI at commit time. The chain from wake packet to diff to verification belongs with the source-custody record, not only with a dashboard that can drift.

The run is the review unit

A single run can produce one commit or forty, across one repo or three. Instead of forcing that into a pull request first, BitterGit groups commits by the run that made them. Accept, revert, or supersede at the run level.

Boring git underneath

Clone, push, pull, branch, tag, blame, log — the product boundary stays Git-compatible. The provenance is source-custody metadata around the commit, not a new version-control language.

03 / How it works

Wake the agent. Capture the change. Review the run.

The work lives between the wake packet that asked for it and the run that produced it. BitterGit's job is to keep that source-custody chain visible enough to verify, accept, revert, or repair.

Wake the agent.

Goltmund issues a wake packet. The Bitter CLI spawns the run and holds the context — Run-Id, Wake-Id, run-scoped signing key — for the lifetime of the work.

Capture the change.

`bitter git commit` writes the trailer and signs it with the run key. Receive validation gives BitterGit a concrete place to reject, audit, or repair agent-originated changes whose provenance does not match the run.

Review the run.

Open the run, not a PR. See every commit, across every repo it touched. See the BitterGrid build, the test output, the probes, the logs. Accept or revert the whole blast radius in one decision.

From the Bitter CLI

$bitter git runs
$bitter git run show run_4f2a
$bitter git diff run_4f2a
$bitter grid verify --run run_4f2a
$bitter git accept run_4f2a --if-verified
# or, to undo the whole blast radius:
$bitter git revert run_4f2a

What gets stamped

# every agent commit carries these trailers,
# signed with the run's ephemeral key.

Run-Id: run_4f2a
Wake-Id: wake_0129
Agent: factory-agent
Verified-By: bittergrid_build_8821
Signature: ed25519:…

04 / What's inside

Boring git. Sharper edges.

The primitives are the ones you already use every day. What BitterGit adds is the provenance substrate around them.

ProtocolStandard Git semantics through the BitterGit service boundary. The public site is only the marketing surface.

Client`bitter git` — a thin wrapper over native git that stamps provenance at commit time.

IdentityHumans through account authority. Agents through run-scoped signing material.

ProvenanceSigned Run-Id / Wake-Id trailers on agent commits, validated before the run is accepted.

Review unitThe run. Commits group automatically across repos; decisions operate on the run.

VerificationWired to BitterGrid. Build, tests, probes, and deploy receipts attach before accept when the runtime path is connected.

AuditSource-custody events are intended to feed BitterLog so future wake packets can query prior work.

HostingYour own substrate. Sovereign over writes. Open over reads. Own failure domain.

05 / Who it's for

For teams that ship with agents.

Solo operator

More agents than PRs you could ever review.

Your fleet produces hundreds of commits a day. You need to know which run made what, what got verified, what failed, and what to accept — without clicking through forty PR pages.

Small team

Humans and agents committing side by side.

Human commits are human commits. Agent commits carry their run. The data tells you what it is — no bot-account fiction, no after-the-fact tagging.

Engineering lead

Auditing agent work at fleet scale.

Every change links back to the wake that asked for it and the verification that cleared it. Reconstruct exactly what an agent did, when, and why — down to the signed commit trailer.

What BitterGit isn't

Not another GitHub clone. No stars, followers, trending, marketplace.
Not a project tracker. Wake packets live in Goltmund.
Not a CI system. Builds, tests, and probes live in BitterGrid.
Not a social network. Your reputation is your signed change history.
Not PR-first. The run is the review unit.

06 / Access

Request early access.

BitterGit is proving the Bitter fleet migration first — the Bitter fleet itself is tenant zero. Tell us what you'd want to host here, and which loop you'd point at it.

Invitations go out in waves. There is no self-serve signup queue or static form endpoint; access requests start in BitterDesk.

Open a BitterDesk request with the repositories you want to protect, the agent loop you want to wrap, and the receipt shape you need.

Start request in BitterDesk Every change has a run, a reason, and a receipt.