How to Govern Agent PRs and Keep Open-Source Trust

A fast beta is a governance test

I read the queue as the number that matters, not the version. DoltLite reached Beta at version 0.50.0 five months after launch. That is a data point: DoltLite reaching Beta shows a team of agents could accomplish the work

DoltLite is built as a fork of SQLite, with the B-tree layer replaced by a Prolly Tree backed by a single-file chunk store. That architecture choice matters because it is meant to make the merge decision boring.

The Agent PR Governance Threshold

I use a four-gate threshold. A pull request from an agent is not a draft until it passes all four. If it fails one, it goes to a quarantine queue, not into a human reviewer's inbox as a normal task.

Gate one: blast-radius classification

I label every agent PR before review. The label should answer one question: if this change is wrong, what breaks? Core storage, query execution, public API, configuration, tests, and documentation are not the same risk. A patch that touches the storage format deserves more evidence than a patch that rewrites a comment. In a fork of a trusted engine, the blast radius is not just your repo; it is every downstream user who assumes the file format behaves like something they already trust.

Gate two: correctness evidence

I do not accept that the agent says it works. I require evidence that matches the risk. For a query engine, that may mean a targeted regression test, a property-based test, a diff against expected behavior, or a slice of the existing test suite. For a high-risk agent PR, I require the kind of correctness evidence that can show a query engine still behaves; DoltLite passes a test suite of complex queries.

Gate three: performance guardrails

Agent labor can compress build time, but it can also ship a slow path that no one notices until production. A nightly performance report showed in-memory DoltLite databases were slower than SQLite on both reads and writes. The point is that the regression was visible. I would not call a review threshold complete without a performance report that runs automatically. Set a threshold for latency, throughput, memory, or startup time, and make the report part of the merge decision. A patch that passes tests but makes the hot path measurably worse should not merge without an explicit trade-off note.

Gate four: maintainability review

Agents can produce code that works today and confuses the next human tomorrow. The maintainability gate should check for naming, structure, comments, dead code, hidden configuration, and ownership. A change that is correct but unexplained is a future incident. In open source, maintainability is also trust. Contributors and users need to see that the codebase is still readable, not just green.

Keep open-source trust visible

Open-source trust is not a marketing claim. It is a set of observable habits. At Beta, DoltLite's storage format is described as stable after 12 prior format changes. If you are building with agents, publish the same kind of signal. State which areas are stable, which are experimental, and what evidence is required before a change lands.

Make the governance visible in the repository. A short engineering playbook in the docs can list the gates, the quarantine process, and the performance thresholds. When a human reviewer asks why an agent patch was merged, the answer should be a checklist, not a vibe. When a user asks why a change broke their workflow, the answer should be a changelog entry, a linked issue, and a test that proves the fix.

The quarantine queue is the part most teams skip. It should be a first-class place: a label, a board, or a folder of patches that failed one or more gates. Each quarantined PR needs an owner, a reason, and a deadline. Some will be fixed. Some will be discarded. The point is to keep the merge queue clean without pretending that generated work is either all safe or all useless.

Agent labor changes the economics of building. It can compress the time from idea to beta, but it also raises the cost of a bad merge. The founder's job is to turn that cost into a threshold: classify the blast radius, require correctness evidence, guard performance, and review maintainability. DoltLite's concrete signals earn the trust claim: its storage format is described as stable after 12 prior format changes, and the nightly performance report showed in-memory DoltLite databases were slower than SQLite on both reads and writes. If a patch passes, merge it. If it does not, quarantine it. That is how you keep speed without spending the trust that open source takes a long time to build.