When Agents Converge: LLMs, Policy, and Mathematical Solvers as Peers
The breakthrough is not bigger models. It is what happens when language models, policy engines, and mathematical solvers compete inside the same Formation — and the engine finds the fixed point.
There is a pattern emerging in enterprise AI that is easy to miss because it does not look like what we have been promised.
The promise was a single model — increasingly capable, increasingly autonomous — that would handle the full complexity of organizational decision-making. Draft the plan, check the constraints, find the optimal answer, explain the tradeoffs, and send the email. One system. One interface. One point of control.
What practitioners keep rediscovering is that this is not how good decisions actually get made. Not in organizations, and not in software.
Good decisions involve different kinds of reasoning working together. Intuition and framing on one side. Formal verification on the other. Negotiation in the middle. The insight of Converge — and the stack we have been building on top of it — is that agent architectures should be designed around this pluralism, not in spite of it.
The Convergence Model
Converge is a cognitive library for Rust. It does not own a runtime, a message bus, or a deployment format. It is a set of contracts and a loop.
The contracts center on a single primitive: the Suggestor. A Suggestor reads facts from a shared context and proposes new facts, each tagged with a confidence score. It declares what it reads, what it accepts, what it costs, and what it produces. Nothing else.
The loop is the Formation. An Engine runs multiple Suggestors against the same context simultaneously. Each reads the same inputs. Each writes to a shared strategy space. The engine repeats until no Suggestor can improve on the current state — a fixed point. Whatever sits at that fixed point is the Formation's answer.
This is not a pipeline. There is no orchestration code that decides which agent runs first, passes output from one to the next, or handles failures in the middle. The Formation is declarative. You register Suggestors. The engine finds equilibrium.
The mechanism that makes this safe is confidence scoring. A greedy heuristic that finds a good-but-not-proven answer caps its confidence at 0.65. A mathematical solver that finds a provably optimal answer reports 1.0. Downstream consumers — including other Suggestors — select by confidence. The Formation naturally routes toward the most trustworthy answer available within the time budget.
What this means in practice: you can run a fast, approximate answer and a slow, exact answer in parallel. The Formation does not wait. It uses both, weights by confidence, and settles.
Organism: The Intelligence Layer
Converge handles the convergence loop. Organism handles the intelligence above it.
Where Converge is concerned with how a Formation reaches a fixed point, Organism is concerned with what the Formation is trying to accomplish — and whether that goal is well-formed.
Organism introduces an intent pipeline: structured packets that describe outcomes, not steps. An intent arrives, gets admitted through capability checks, and is decomposed into sub-problems that concrete Formations can handle. Each sub-problem gets its own Formation, runs to a fixed point, and hands its result back up.
Around this pipeline Organism adds two things that operational intelligence actually requires.
The first is adversarial review. Before a plan is committed, a set of skeptic agents — assumption breakers, constraint checkers, edge-case generators — challenge it. This is not validation in the traditional sense. It is structured disagreement, automated. A planning session that passes adversarial review has survived challenges that a human reviewer would raise. One that fails surfaces the specific assumption that broke.
The second is collaborative planning — what Organism calls a Huddle. Multiple models, potentially with different capabilities, different providers, different temperature settings, reason together on the same problem. They do not take turns. They debate. The debate loop runs until participant positions converge, or until the time budget closes. The transcript is evidence, not just output.
Together, Converge and Organism describe an architecture where language models do what they are actually good at: framing, communicating, generating candidates, explaining results. The hard structural reasoning — what is feasible, what is optimal, what is authorized — is handled by systems designed for exactly that.
Ferrox: The Solver Layer
Language models are not optimizers. This is not a criticism; it is a description.
Given a scheduling problem with forty technicians, two hundred work orders, individual certifications, time windows, and labour agreements, a language model will produce a plausible-sounding schedule. It cannot prove that schedule is optimal. It cannot tell you how far from optimal it is. It cannot guarantee that every constraint has been respected. On sufficiently complex instances, it cannot reliably find a feasible answer at all.
Ferrox is the answer to that gap. It exposes Google OR-Tools CP-SAT and HiGHS MIP — two of the strongest open-source mathematical solvers available — as first-class Converge Suggestors. They register in a Formation alongside LLM agents. They read the same context. They write confidence-scored plans to the same strategy space. The Formation handles the rest.
For every problem class, two implementations compete:
A greedy heuristic runs in microseconds. It seeds a baseline answer immediately and gives the downstream pipeline something to work with while the exact solver is running. Its confidence is capped — it cannot prove optimality.
A CP-SAT or MIP solver runs in parallel. It searches the full solution space, propagates constraints, and either proves optimality within the time budget or surfaces the best feasible solution found. Its confidence is proportional to result quality — 1.0 when proven optimal, scaled down for feasible-but-not-proven, zero on failure.
The greedy answer and the exact answer coexist in the context. Downstream Suggestors — including the LLM that will write the explanation, the email, or the report — select by confidence.
Three Problems That Matter
The benchmark numbers from Ferrox's three problem domains are worth dwelling on, not because they demonstrate solver performance in the abstract, but because each one is a real decision class with real organizational consequences.
Field Service Scheduling
A utilities company has twelve specialist technicians and sixty work orders arriving each morning. Each order requires a specific certification. Each has a committed customer time window. The horizon is six hours.
Ferrox's greedy EDF scheduler — sorting by deadline, assigning the earliest available capable agent — runs in 0.03 milliseconds and schedules 56 of 60 tasks. Respectable. On most mornings, no one would notice the four that got dropped.
CP-SAT, running in parallel for 260 milliseconds, schedules all 60. It proves this is the maximum achievable given the constraints. The difference is not four work orders in the abstract. It is four customer appointments that either happen today or get rescheduled, four SLA credits that either stay in the bank or get paid out, four technicians whose morning either has slack or runs long.
At scale — forty technicians, eight hundred work orders per week — the compounding is material. The gap between heuristic and optimal scheduling is not a technical curiosity. It is headcount.
What makes this a Formation problem rather than a pure solver problem is everything that surrounds the optimization. An LLM agent reads the raw work orders from emails and PDFs, extracts the structured data, and seeds the scheduling request into context. A Cedar policy engine checks labour agreements — no technician works more than ten hours, union jurisdiction applies by zone — before the scheduler sees the request. After the CP-SAT plan is confirmed, a second LLM agent drafts the technician briefings, the customer ETA notifications, and the manager summary. No single component does the whole job. Together, they do it correctly.
Capital Allocation
A fund manager needs to deploy fifty million euros across a shortlist of projects. Returns are estimated. Risks are scored. Regulations prohibit concentrating more than forty percent of capital in any single sector. ESG policy requires at least three sustainable investments in the portfolio.
The combinatorial space here is not exotic. With thirty candidate projects, there are roughly a billion possible portfolios. A language model navigating this intuitively will produce something that looks right — until it checks the sector cap and finds it is three points over, or counts the ESG flags and realizes it has only two.
HiGHS solves this as a binary knapsack in seconds: select projects to maximize expected return subject to total capital constraints, sector concentration limits, and ESG minimums. It returns not just the optimal portfolio but the optimality gap — how much better it would need to do before the answer could possibly improve. When the gap is zero, the answer is proven.
The Cedar policy layer runs before the solver. Any candidate that violates a hard regulatory rule — excluded geographies, minimum ticket sizes, counterparty restrictions — is removed from context before HiGHS sees it. The solver never needs to know why a candidate was excluded. It sees only the feasible space, and it optimizes within it.
After the MIP confirms the portfolio, an LLM drafts the investment committee memo. It explains the sector distribution, highlights the projects that were nearly selected, and flags any concentration that sits close to a regulatory boundary. The memo is grounded in a proven answer. The analyst who reads it is not second-guessing an opinionated language model. They are reading an explanation of a mathematically optimal allocation.
Factory Floor Planning
A precision manufacturer's job shop runs ten machines across three shifts. Each evening, a new batch arrives: fifteen to thirty jobs, each requiring a fixed sequence of machining operations. No two jobs can occupy the same machine simultaneously. Finishing the batch sooner frees capacity for the next shift. The target is to minimize makespan.
This is the canonical NP-hard scheduling problem. Greedy SPT dispatching — always running the shortest available operation first — produces a valid schedule in under a millisecond. On a fifteen-job, ten-machine instance, that schedule has a makespan of 2,038 time units.
CP-SAT, given a thirty-second budget, produces a schedule with makespan 1,044 — 48.8 percent shorter. On a three-shift operation, that is not 48.8 percent more jobs per shift. The relationship is nonlinear. A schedule that finishes the batch forty-nine percent sooner does not just start the next batch earlier. It changes what becomes possible about shift overlap, maintenance windows, and the decision about whether to add a weekend run.
The formation around this optimization does what formations do. An LLM reads the ERP export and production notes, identifies rush jobs and quality holds, and seeds a structured JobShopRequest into context. Cedar enforces maintenance windows and operator certifications. The greedy and CP-SAT Suggestors run concurrently — the floor supervisor's screen shows the baseline immediately, then updates when the proven-optimal plan is confirmed. An LLM writes the handover notes and flags any rush jobs that risk missing their committed window.
The math produces the schedule. The Formation makes it usable.
What Fixed Points Mean
The phrase "fixed point" in mathematics refers to a value that maps to itself under a given function. In the Converge model, a Formation reaches a fixed point when no registered Suggestor can improve on the current state of the context. The engine has converged. The answer is stable.
This property matters for a reason that is easy to overlook. Most agent architectures are pipelines: step one feeds step two, step two feeds step three. A pipeline's correctness depends on each step being correct, in order. An error in step two corrupts every step that follows. And when you want to add a new capability — a new solver, a new policy check, a new verification layer — you have to decide where in the sequence it goes, and whether it breaks the steps around it.
A Formation has no sequence. There is no step one. Every registered Suggestor can read any fact in context and write any proposal. The order in which they run does not matter for correctness, only for speed. Adding a new Suggestor — Ferrox's job shop solver, a new LLM provider, a domain-specific heuristic — requires no changes to anything already registered. You register it. The engine incorporates it on the next run.
This is what makes Ferrox's solver Suggestors composable with language model agents. They do not need to know about each other. They do not call each other. They both read from context and write to context, with confidence scores. The engine finds the equilibrium.
The practical consequence is that a Formation can be built incrementally. Start with greedy heuristics. Add a mathematical solver. Add an LLM explanation layer. Add a Cedar policy check. Add an adversarial reviewer. Each addition improves the Formation's answer quality or safety envelope without requiring any existing component to change. The fixed point absorbs each new voice.
The Composition That Actually Works
The architecture that emerges from Converge, Organism, and Ferrox is not a monolith with AI bolted on. It is not a pipeline with an LLM at one end and a lookup table at the other. It is a composition of specialized agents — each doing one thing well — that reaches consensus through structure rather than orchestration.
Language models handle what they are genuinely good at: understanding unstructured input, generating narrative, explaining decisions in terms a human can act on. Cedar policy handles authorization: the hard rules that cannot be softened by context or confidence. Mathematical solvers handle optimization: the problems where the combinatorial space is too large for intuition and where the cost of a suboptimal answer is measurable.
None of these technologies is a substitute for the others. Together, in a Formation, they produce decisions that are at once explainable, authorized, and proven.
That is the fixed point worth reaching.