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

# The Millwork platform

> See how Millwork and Solver fit together, and what each name means.

Millwork is the platform for **composable intelligence, with verifiability**:
models, agent endpoints, and reusable skills can share one execution model,
while every run leaves inspectable evidence.

Solver is the first product built on that platform.

## What an AI strategy envelope does

An AI strategy should survive the next model, provider, and agent capability.
Millwork gives it a durable operating boundary. A business can decide what may
run, connect the supply it wants to use, and inspect the route, recorded usage,
verifier outcome, and terminal state.

That is the strategy envelope: capabilities can change while control and proof
stay consistent.

The strategic advantage comes from how a business uses a changing supply.
Providers, clouds, gateways, and model releases will continue to expand.
Millwork gives a business a consistent way to decide what may run, connect the
supply it wants, and inspect the route, recorded usage, verifier outcome, and
terminal state.

## One platform, one clear starting point

```text theme={null}
Millwork
└── Solver
    ├── registered capabilities
    ├── limits and checks
    ├── governed runs
    └── results and receipts
```

**Millwork** is the product family and shared foundation. It owns the concepts
that should remain consistent across AI work: who may run something, which
provider account is used, what limits apply, and what evidence remains.

**Solver** is the developer-facing product available in private preview. It
takes a task and its boundaries, selects an eligible registered capability,
runs it, checks the outcome, and records how the work happened.

<Note>
  The repository and API may use the name `SolverAPI`. The public product name
  is Solver.
</Note>

## Why the platform matters

A wrapper makes several APIs look alike. That helps with syntax, but leaves the
hard questions in application code: what was allowed, why a route was chosen,
what happened after a failed check, and what record can be trusted later.

Millwork makes those questions part of the run itself. The same boundaries and
evidence can follow the work even as the underlying capability changes.

## What sits beneath Solver

Millwork's architecture names an orchestration substrate **Harness**. It is not
a separate public integration. Customer integration begins with Solver.

An **Agent Layer** appears in future-looking product architecture and is not a
current customer capability. Today, the customer starting point is Solver and
its live API.

<CardGroup cols={2}>
  <Card title="Meet Solver" icon="route" href="/overview/solver">
    See what one governed run gives your application.
  </Card>

  <Card title="Check current scope" icon="circle-check" href="/overview/availability">
    Separate what is available now from what remains planned.
  </Card>
</CardGroup>