Single-shot LLM generation breaks down on open research problems. You need to explore competing conjectures, overcome technical obstructions, and retain intermediate progress over long horizons. Cogentic is a multi-agent harness that solves this coordination problem for automated theorem proving. It produced novel results on five open problems in online learning, auction theory, and mechanism design using Gemini as the base model.
The architecture exposes orchestration patterns that apply beyond math: how to spawn agents across distinct proof directions, when to promote intermediate results into shared state, and how to prune the search space when competing hypotheses explode.
Research-grade tasks require more than chaining tool calls. You need:
Single-agent workflows fail because they commit too early. Multi-agent systems without coordination waste compute on redundant paths or lose intermediate progress when agents disagree on lemmas.
Cogentic runs an iterative loop with three layers:
The verified ledger is the critical piece. It acts as a shared knowledge base that later rounds build on. Agents read from the ledger to avoid re-proving known results and write to it only after passing verification.
Each prover operates independently but reads from a shared ledger before starting work. This prevents duplication:
The orchestrator tracks which subproblems are currently being attempted to avoid assigning the same work to multiple agents. This is a simple lock mechanism: when a prover claims a subproblem, it gets marked as "in progress" until the prover either succeeds or times out.
Verification is adversarial. Multiple specialized components review each proof attempt:
Only proofs that pass all three gates get written to the ledger. This prevents cascading failures where one bad lemma poisons downstream work.
The orchestrator decides when to spawn new agents and when to double down on existing branches. It uses a simple heuristic:
This is a greedy strategy with a timeout. If exploitation stalls (no new verified results after M rounds), the orchestrator switches back to exploration.
When competing hypotheses explode, the orchestrator prunes branches based on:
Pruning is conservative. The orchestrator never kills a branch permanently, it just deprioritizes it. If other branches stall, pruned branches can be revived.
When two agents propose conflicting lemmas, the verification layer catches it. The orchestrator then:
This creates a temporary bottleneck but prevents bad state from propagating.
If verification is slow, provers queue up waiting for results. The orchestrator monitors queue depth and throttles prover allocation when the queue exceeds a threshold. This is a backpressure mechanism: slow down generation when verification can't keep up.
Without pruning, the orchestrator can spawn agents indefinitely on unproductive branches. The compute budget acts as a hard stop, but it's a blunt instrument. Better heuristics would track the marginal value of each branch (verified results per agent-hour) and kill branches with declining returns.
Debugging multi-agent proof attempts requires visibility into:
Cogentic logs all of this to a structured event stream. Each event includes:
{
"timestamp": "2026-09-30T17:55:22Z",
"agent_id": "prover-42",
"event_type": "proof_attempt",
"subproblem": "lemma-3.2",
"dependencies": ["lemma-2.1", "lemma-2.5"],
"verification_result": "rejected",
"rejection_reason": "counterexample_found",
"compute_time_ms": 12400
}
This lets you replay proof attempts and understand why certain branches succeeded or failed.
Cogentic runs on a cluster of GPU instances with:
The orchestrator is the single point of failure. If it crashes, you lose in-flight state but the ledger persists. Provers and verifiers are stateless and can be scaled independently.
Research-grade proof discovery is expensive. Cogentic's five novel results required:
This is not a real-time system. Proof attempts run for hours or days. The orchestrator checkpoints the ledger periodically so you can resume after failures.
| Dimension | Cogentic Approach | Alternative | Trade-off |
|---|---|---|---|
| State management | Persistent verified ledger | Stateless agents with no memory | Ledger prevents duplicate work but adds coordination overhead |
| Verification | Adversarial multi-component | Single formal checker | Catches more errors but slows throughput |
| Exploration strategy | Greedy with timeout | Exhaustive search | Faster convergence but may miss non-obvious paths |
| Pruning | Conservative (, don't kill) | Aggressive (kill low-value branches) | Safer but wastes compute on dead ends |
| Orchestrator | Centralized stateful process | Decentralized peer-to-peer | Simpler coordination but single point of failure |
The hardest failure mode is when two branches produce conflicting verified lemmas. This shouldn't happen if verification is sound, but it can occur when:
Cogentic's solution is to escalate to human review. The orchestrator flags the conflict, s all dependent work, and waits for a human expert to resolve it. This is a manual escape hatch, not an automated recovery mechanism.
Use Cogentic's patterns when:
Avoid this architecture when:
The core insight is that research-grade tasks need a different orchestration model than typical agent workflows. You can't chain tool calls and hope for the best. You need parallel exploration, adversarial verification, and a shared knowledge base that survives agent handoffs. That's expensive infrastructure, but it's the only way to solve open problems that require exploring multiple dead ends before finding a proof.