Build1 publisher3 min readPublished
Cogentic lets proof agents share only lemmas that survive three adversarial checks
Cogentic, a Gemini-based multi-agent prover, produced novel results on five open problems, a dev.to write-up says, by sharing only verified lemmas. The patterns carry over to other agent work that has a cheap checker for intermediate results.
The Engineer · Build desk
Drafted by a language model from the sources cited here and checked against its claim ledger before publication. How we use AISend a correction
What happened
- An orchestrator spreads a population of independent prover agents across distinct proof directions, and an adversarial verification layer checks every attempt they produce.
- Each attempt must pass a formal checker, a counterexample generator and a domain critic before later rounds can build on it.
- Pruning deprioritizes or pauses weak branches without ever killing them, under a hard cap on the number of active provers.
Compiled by The EngineerSomething wrong?How this is made
Why it matters
- constraint Verifier capacity caps the whole system: once the check queue fills, the orchestrator throttles provers, so extra generation compute only buys a longer queue.
- exposure A flawed lemma that slips past all three gates becomes trusted shared state, and every later prover reads it and builds on it.
- decision Teams copying the design are adopting it on argument alone, because without an ablation they cannot tell whether the ledger, the gates or Gemini drove the five results.
- cost Conservative pruning keeps every branch revivable, so spend is held down mainly by the hard cap on active provers, not by abandoning dead ends.
The ledger is the piece I would copy first. Provers read it before taking a subproblem, and they write to it only after an attempt passes verification [4]. In database terms, verification is the commit. An unchecked lemma never becomes something another agent can depend on. The post says the reason is to stop one bad lemma from poisoning downstream work [6].
Claims on work use what the post calls a simple lock. A subproblem stays marked in progress until its prover succeeds or times out [5]. A lock with a timeout is a lease, and the timeout sets what a failure costs. If it is too short, a slow prover loses its claim and a second prover repeats the work. If it is too long, a stuck prover leaves the branch idle.
Scheduling has its own timeouts, counted in rounds. The orchestrator spawns agents on new conjectures when no branch has verified anything in N rounds. It adds agents to any branch that produces verified lemmas, and it goes back to exploration after M rounds without new results [7].
Verification sets the speed of the whole loop. Every attempt goes through a formal checker that validates steps against known axioms, then a counterexample generator, then a domain critic [6]. When verification falls behind, provers queue. Once queue depth passes a threshold, the orchestrator throttles new prover allocation [10]. Beyond that threshold, adding provers only lengthens the queue.
The verification layer also catches conflicts. When two agents propose lemmas that contradict each other, both are marked disputed, work that depends on either one pauses, and a dedicated agent is spawned to settle the conflict [9]. So the fix for two agents disagreeing is a third agent. The post admits this creates a temporary bottleneck [9].
Pruning is conservative. Branches with low verification rates are deprioritized. Branches that rest on unverified lemmas are paused. No branch is killed permanently [8]. A pruned branch can be revived when the others stall, and the hard limit on total active provers is the cap on spend [8].
Of everything in the post, the claim that coordination produced the five results [1] has the least evidence behind it. The post argues that single-agent workflows fail because they commit too early [2]. It reports no ablation and no single-agent baseline run at matched compute [12]. From the post alone, you cannot tell how much of the result comes from the ledger, how much from the gates and how much from Gemini.
Whether the design transfers depends on the checker. In math, Cogentic can run a counterexample generator against every lemma [6]. If the formal checker is a proof assistant, the first gate is strong. If it is another model call, the three gates amount to three model opinions. The post says the patterns apply beyond math [11]. I'd expect the write-after-verify ledger and the backpressure to carry over to any agent task with a checker that can reject a bad intermediate result cheaply.
What to watch
- Publication of the five results with the problem statements, so researchers in online learning and mechanism design can check the novelty claim.
- An ablation running the same problems with the ledger or the verification gates removed, or with a single agent at matched compute.
- Disclosure of whether the formal checker is a proof assistant or another model call.