Meet Solver

Solver is where models, agent endpoints, and reusable skills become parts of the same system. Your application sends the outcome it wants and the boundaries that matter. Solver determines eligibility, chooses a route, runs the work, and checks the outcome. When live work completes, its output is stored as the result. The run’s separate receipt records execution evidence.

​

One run across your integrations

Adding a second model provider often means adding a second set of credentials, errors, retries, timeouts, and logs. Agent endpoints and reusable skills add more shapes again. Solver gives them a shared execution model.

​

Supply, selection, and composition

Solver brings three parts of an AI strategy into the same run:

​

Use your provider key or Millwork model access

Connect a provider account your organization owns or, when the live catalog lists one, register a model supplied through Millwork. Both paths use the same run API. The run record keeps the access path and billing owner clear.

​

Rank the options that are allowed to run

Solver keeps arms that are ready and permitted for the declared data. It then uses the run’s cost preference to deterministically rank that eligible set. The receipt carries the route rationale.

​

Compose one task across capabilities

Solver’s execution and receipt formats are ready for work made of several parts. Dynamic slicing is coming. It is intended to divide one task into bounded parts, rank eligible capabilities for each slice, and keep them under one run policy and receipt.

​

More than a model gateway

A model gateway routes a call. Solver governs a run. Before selection, it keeps options that are ready and permitted for the declared data. It ranks that eligible set. After live work produces a result, it applies the configured check and takes only an action the run allowed. That distinction matters when a system grows. Provider portability is useful; portable control and evidence are what keep the system understandable.

​

What stays in your control

• Your team decides what a good result means for the product.
• The access path and billing owner remain visible in deployment-bound model provenance.
• The basic output check confirms only that output is non-empty and within the configured bound. Your verifier can apply a stronger contract.
• An automatically proposed skill repair changes the saved skill only after explicit approval.