Cycle Conductor pairs your members, and never repeats.
A recurring-engagement engine that generates no-repeat member pairings, drafts brand-voice outreach, and renders on-brand connection pages, re-theming live across any number of tenants from a single config file. The matching is fully deterministic; the AI only writes the emails.
Not a mockup: the same matching primitive runs in production in a real member network. See the case study →
The live engine, in your browser.
This runs the same matching discipline as production: every possible pairing for the cohort is evaluated and the lowest-cost set is chosen (provably optimal) with a seeded shuffle for reproducible tie-breaks, odd counts and mid-cycle dropouts handled. The optimum this returns is checked against an independently written exact solver across thousands of generated cohorts. The second tab extends the same engine across a whole season and adds a fairness ledger.
Season schedule
Fairness ledger: who carries the load
The same inputs, the same answer. Every time.
You just watched it reproduce a cycle exactly. That's what “deterministic” means: a word you'll see across this site, and all it stands for is the same inputs giving the same answer, every single time. It isn't a model trained to behave; it's a machine with nowhere to wander. Here's the wiring, in plain terms.
Rolls dice
Every answer is sampled fresh from a model. Ask it the same thing twice and you get two different answers, wonderful for a first draft, unnerving for a decision you have to stand behind.
Follows a recipe
Every run follows the same fixed rules. Same ingredients, same dish, every time. The AI is kept off to the side, writing the emails, and it never touches who gets matched.
Sometimes two arrangements are equally good: a real tie. Most tools flip a coin to choose, and that's exactly where drift creeps in. Cycle Conductor uses a fixed number as the coin, so it lands the same way every time. The only “randomness” in the whole system is frozen, which is why you can re-run a cycle a year later and reproduce it down to the last pair.
Don't take my word for it. Scroll up, leave the inputs alone, and press Run cycle as many times as you like: it won't move. That isn't a promise; it's arithmetic. Back to the engine ↑
For the curious: the actual mechanics
The matching itself is a classic minimum-cost problem, and there's more on that in how the model measures up below. What makes it reproducible is narrower: the only genuine choice point is a tie between equally-good arrangements, and it's settled by a seeded shuffle: a pseudo-random ordering computed from one fixed number. Freeze the number and you freeze the shuffle, so same inputs + same seed → the same optimum, every run, by construction rather than by training. It's arithmetic you could check by hand: no model, no learning, no luck. Run the live engine ↑
The matching can't drift. The words wait for you, and the bad day is planned for.
Determinism keeps the matching honest. Two more things keep the whole system trustworthy: nothing the AI writes goes out until you've approved it, and when something does go wrong, it fails loudly and safely instead of quietly.
Every AI-written message stops here
And on the bad day
It fails loudly
A match it can't make with confidence is flagged with an error note for you, never silently skipped or guessed at.
It's safe to re-run
Every run is idempotent: re-running a cycle reproduces the same result instead of duplicating work or double-sending.
It leaves a trail
Every decision is logged input-to-result, so when you need to know why, the answer is a record, not a reconstruction.
You can roll back
Because the state is explicit and the run reproducible, an undo is re-running with the input corrected, not a forensic cleanup.
Optimal each cycle, and fair across the season.
One cycle finds the provably optimal pairing. A season asks a harder question: over many cycles, does everyone get a fair share of fresh matches, and of the unavoidable compromises? The Full season · fairness tab above runs the same engine across a whole horizon and keeps a ledger so the load stays even.
It plans the whole horizon, not just the next cycle. Across a season the engine rotates pairings so members meet as many distinct people as possible: for an unconstrained group, the exact round-robin where everyone meets everyone once. And it keeps a fairness ledger: the odd-one-out (the group of three) and the unavoidable same-org / same-region compromises rotate by who has carried them least, never at the cost of a cycle's optimum.
Where it earns its keep is when someone is disadvantaged. Drop a brand-new member into an established group and a cost-only matcher sits them in the group of three nearly every cycle; the ledger holds that to once. On a long-settled, symmetric roster the two barely differ, and fairness is the guarantee that holds when the roster isn't. Flip the Newcomer / Steady state scenarios and the fairness toggle on the tab to see both.
Shown as a working prototype of where the method goes next: the rotation and fairness ledger are designed to be validated against an exact solver, and kept distinct from the single-cycle engine that runs in production today.
Seven steps, every cycle.
Read the roster
Pull the current participant list and each member's pairing history from the system of record.
Score every pairing
Build a cost matrix: a repeat pairing is penalized so heavily it only happens when nothing else is left; same-org and same-region clashes carry smaller penalties.
Seed the randomness
A seeded shuffle makes tie-breaks deterministic: the same roster and history always produce the same result, so the output is reproducible.
Solve for the optimal set
For a cohort this size, every possible pairing is enumerated and the lowest-total-cost set is chosen, provably optimal. At larger scale, a seeded simulated-annealing solver takes over to stay fast without giving up quality.
Handle odd counts
If the count is odd, one member is doubled into a group of three rather than left out, chosen by the same rules, so nobody is dropped.
Repair dropouts
If someone leaves mid-cycle, only the affected pair is re-matched; every unaffected pair is frozen, so a late change doesn't reshuffle the whole cohort.
Draft & render
The AI layer drafts each intro email in the tenant's brand voice and renders the on-brand connection page, but every message is held as a draft, and the system refuses to send anything you haven't approved. The matching never touched the AI, and nothing AI-written reaches a member unreviewed.
One engine, every brand.
The same matching engine re-themes across any number of tenants from a single config file. Each tenant defines its own voice, palette, and connection-page theme, and the logic underneath never changes.
Warm & editorial
Forest tones, serif voice, a calm members-first connection page.
Cool & precise
Glacial slate, technical voice, a directory-style connection layout.
Bold & brass
High-contrast accents, confident voice, a spotlight-style page.
A minimum-cost matching, by the book.
Matching here is a minimum-cost assignment problem. Each constraint is a weighted penalty — a repeat dominates everything, then a same-organization or same-region clash, then a small nudge against pairing two brand-new members. The engine searches for the lowest total cost, and a repeat only ever survives when no cheaper arrangement exists.
For a cohort this size it enumerates every possible pairing and returns the provable global optimum — the live engine above shows the exact count it evaluated. The same objective is the classic minimum-weight matching problem, which scales to large pools; determinism, odd-pool handling, and surfaced forced-repeats are first-class, so the engine never hides a compromise.
Cycle Conductor matches members, but the discipline is the point. A deterministic core, AI kept to the edges, every run reproducible and audited: that's how every Ousios system is built, whatever the workflow, and it's the line that decides what I'll automate and what I won't.
What people ask about the engine.
How does it guarantee no repeat pairings?
Every possible pairing is scored, and a previously-seen pairing is penalized so heavily that the engine only repeats a pair when there is genuinely no alternative. For a cohort, the solver evaluates the full space of pairings and returns the lowest-cost set, provably optimal, so a repeat appears only when no repeat-free arrangement exists at all. And because the same inputs always produce the same pairings, the behavior is verifiable, not random.
Will the AI send anything to my members on its own?
No, and not just as a matter of policy. The AI drafts the wording (intro emails, connection pages) in your brand voice, but the system is built to refuse to send any of it until you've approved the draft. The AI never makes a decision, and nothing it writes can reach a member unreviewed. You're always the last set of eyes.
What happens with an odd number of members?
One member is deterministically doubled into a group of three rather than left out, so nobody is dropped from a cycle. Who doubles follows the same scoring rules, so it's consistent and explainable.
What if someone drops out mid-cycle?
Only the affected pair is re-matched. Every unaffected pair is frozen, so a late dropout never reshuffles the whole cohort: the repair is surgical, not a full re-run.
Can it serve multiple brands?
Yes, it's multi-tenant from a single config file. Each tenant defines its own brand voice, colors, and connection-page theme, and the same engine re-themes live across all of them without changing the matching logic.
Does it stay fair over many cycles?
That's the season layer in the demo's second tab. Across many cycles the same engine can plan the whole horizon as a rotation, so members meet as many distinct people as possible, and keep a fairness ledger so the odd-one-out and the unavoidable same-org or same-region compromises rotate by who has carried them least, never at the cost of a cycle's optimum. It matters most when someone is disadvantaged: a brand-new member, whom a cost-only matcher would otherwise bench in the group of three nearly every cycle. It's a working prototype of where the engine goes next, kept distinct from the single-cycle matching that runs in production today.
Want an engine like this for your recurring work?
Cycle Conductor is one shape this takes. Any recurring workflow you run by hand each cycle (pairing, routing, triaging, drafting, reconciling) can run on the same deterministic discipline: your logic, your voice, your cadence, audited every run. Scope and price are fixed before any work begins.
or email kira@ousios.dev