Skip to main content

The Algorithm Library

Ask a model to sort ten million records and it will write you a sort. It may be a good one. You will not know why it chose that one, whether a better one was available, or whether it will choose the same one tomorrow.

The Algorithm Library replaces that with identify, select, execute: a governed decision over a catalog of real, executable algorithms.

The three phases​

Figure AL1: the solve loop. The feedback edge is what separates this from a lookup table. Selection breaks ties on observed latency, success rate and usage, so the library's choices improve as it runs, without anyone retraining anything.

Identify measures the problem rather than asking about it: data shape, the inferred goal, and the constraints that apply.

Select is a pure, deterministic decision table. Candidates are hard-filtered against the constraints, the survivors are soft-scored on measurable shape, and ties are broken on observed performance. Given the same problem and the same history it selects the same algorithm, and it can say why.

That is the differentiator worth stating plainly: selection is governed, explainable and improves with use, rather than a model picking from a tool list on instinct.

Execute runs the chosen algorithm, metered and gated like any other consequential work.

Algorithms are catalog assets, not code registrations​

An algorithm is published as a skill in the catalog, carrying a structured description of its own properties: its goal, its family, its time complexity at best, average and worst, its space complexity, and the input/output model it assumes, in memory, external, or distributed.

The router scores against exactly those declared properties. So:

A new algorithm becomes eligible the moment it is published with a matching goal. Nothing is recompiled and no routing code changes.

The router holds only the mapping from goal to rules. Per-candidate facts live in data. A genuinely new kind of problem needs a new rule set; a new way to solve an existing one needs only a publish.

A malformed properties block fails closed at validation rather than producing an algorithm the router might select and then be unable to reason about.

Execution: sandboxed, and never faked​

An algorithm body is untrusted code, and it is treated that way. Execution leases a warm sandbox, writes the run envelope into the writable overlay, executes the body inside the jail, and releases the sandbox in a way that discards the overlay regardless of outcome.

There is no in-process evaluation of algorithm source anywhere on this path.

The failure behaviour is the part to hold onto:

A non-zero exit, a timeout, a crash or a malformed result surfaces as an explicit error. It is never returned as a plausible answer.

A fabricated success would do two kinds of damage at once: it would forge the audit record, and it would tell the model the work happened when it did not. Both are worse than a failure.

Distributed execution​

For data larger than one shard, execution distributes: the algorithm runs per shard and results are merged. That is the same scale-out substrate the database uses, so an algorithm inherits the estate's shard count rather than being bounded by one machine.

How it is reached​

CallerSurface
An agentA small tool family: solve, list, describe
A chat turnThe same tools, through the shared tool surface
A personA catalog browser and a solve console
A programAn administrative HTTP surface

An agent sees essentially one verb. The complexity of choosing well is the library's job, not the model's.

A host that cannot provide the sandbox answers with an explicit error at call time rather than being absent from the tool list, so the failure is diagnosable instead of mysterious.

A refusal is a refusal, not an error​

When the net-potential-gain gate declines a solve, the surfaces render it as a governed refusal with its reasoning, not a generic failure. The distinction matters: "this was declined, here is the verdict" is actionable, and "something went wrong" is not.

At the edge​

A disconnected device keeps solving with a compiled-in solver over a smaller set of bodies. A connected device can borrow the cell's larger catalog and its distributed execution. Losing the link narrows the library rather than removing the capability.