> ## Documentation Index
> Fetch the complete documentation index at: https://docs.getmillwork.dev/llms.txt
> Use this file to discover all available pages before exploring further.

# Meet Solver

> Learn how Solver turns AI capabilities into bounded, inspectable runs.

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.

<CardGroup cols={2}>
  <Card title="Bring capabilities" icon="blocks">
    Register models, agent endpoints, and reusable skills as options Solver may use.
  </Card>

  <Card title="Declare boundaries" icon="shield-check">
    Put allowed data, cost, time, and permitted responses beside the task.
  </Card>

  <Card title="Check the outcome" icon="badge-check">
    Use a basic output check or a verifier your organization controls.
  </Card>

  <Card title="Keep the evidence" icon="receipt-text">
    Use the result in your product and the receipt to understand the run.
  </Card>
</CardGroup>

## 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.

<Card title="Follow one run" icon="workflow" href="/overview/how-solver-works">
  See the decisions Solver makes from submission to receipt.
</Card>