Prenup

What it does

Collaborations between companies and universities often stall on terms that nobody settles up front: who owns the results, when the researcher may publish, exclusivity, what each side contributes. Prenup takes company challenges from the EINSTEIN dataset, finds the researcher who can actually do the work, and has a company-side and a researcher-side agent pre-negotiate the "Agreed up front" terms before anyone meets. The result is a one-page proposal in the organizers' format. A Critic checks every claim against the dataset before it is used, and every fact cites a record id. When there is no good match, Prenup gives a reasoned no. A person can edit the terms and approve or reject each proposal on a live board. On the demo set it wrote 7 proposals and 1 reasoned no-match. On 15 more sampled challenges it wrote 11 proposals and 4 no-matches. All 20 planted false claims were stopped. Everything replays from recorded answers with one command, with no API key.

How the agents run concurrently

Every challenge, candidate, conflict and pair gets its own Mozaik agent, and every runLoop is fire-and-forget, so analysts, profilers, fit reviewers, arbiters, negotiators, writers and the Critic's support checks all think at the same time. One runner caps the system at 8 model calls in flight and handles retries; the demo run makes 246 calls, with up to 35 open at once. Agents never call each other: each reacts to custom prenup.* events on the shared runtime. Three matchmakers share one Board (a RuntimeState) and reserve researchers with version-checked writes. If two want the same researcher, the second write fails the version check, so nothing is overwritten and nothing is locked. The failure becomes a reservation.conflict event; an Arbiter agent decides with cited reasons (checked before it is published), and the losing matchmaker re-matches by itself. The demo run has two real conflicts. Other feedback loops: a stopped claim goes back to its author once, a plan problem goes back to the writer, and a no-deal returns the challenge to its matchmaker. Measured: 0 double-booked researchers across all 489 challenges, against 104 with last-writer-wins. On the earlier 4-challenge build, running the agents in parallel was 3.9x faster than one call at a time (173.9 s vs 680.6 s). Details in CONCURRENCY.md in the repo.