# How it works

> Workflow Compilation turns a workflow your agent already runs into a Compiled Agent Model, with your current model as the fallback.

A Compiled Agent Model comes from **Workflow Compilation**. Your agent runs a workflow today on a frontier model. Workflow Compilation builds a model for that one workflow, so the next run of the same job, with new values, doesn't need to go back through a frontier model.

![Your agent today, a Compiled Agent Model for the same job, and a fallback for anything new](/docs/figures/how-it-works.svg)

## The lifecycle of a request

1. **Today.** Your agent runs the job on the model you use now, with your prompts, tools, and checks.
2. **Built.** Workflow Compilation produces a Compiled Agent Model for that workflow from your agent's completed runs. It is specific to your job. It is not a general-purpose model.
3. **Next run.** You send the next request to `workflow/auto`. When it's the same job with new values, the Compiled Agent Model handles it, faster and for a fraction of the cost.
4. **Not a fit.** When a request isn't the job it knows, it goes to your [fallback model](/docs/fallback-models), the frontier model you already use. You get the result you would have gotten today.

Your client doesn't change between steps 3 and 4. Both use the same endpoint, model name, and response format.

## Same job, new values

This is where it differs from a cache. Tomorrow's invoice has a different vendor, different amounts, and a different date. A response cache either misses, or it sees a request that looks familiar and returns yesterday's total. A Compiled Agent Model does the job again on today's values.

![A cache returns the old total on a new invoice; a Compiled Agent Model returns the new one](/docs/figures/new-values.svg)

## What it is not

People usually compare it to one of these. Here is how each one differs.

| Approach | What you get | Where it stops |
| --- | --- | --- |
| Prompt caching | Cheaper cached input and a faster first token | Output, reasoning, and a frontier call on every step are still paid |
| Response or semantic cache | An instant stored answer | Misses, or returns the old answer, when the values change |
| A cheaper open-weight model | A lower price per token on a general model | It's a general model, so quality on your workflow is whatever you get, and you have to evaluate and maintain it yourself |
| Fine-tuning your own model | A model shaped to your data | You collect the data, train, evaluate, host, and keep it current, and there is no fallback unless you build one |
| Compiled Agent Model | A faster, cheaper run of a job your agent already does | Anything new goes to your current model |

The comparison with caching is covered in more depth in [what caching saves for AI agents](/blog/caching-for-ai-agents).

## What stays yours

- **Your quality bar.** Your current model is the fallback, so a request the Compiled Agent Model doesn't fit gets the answer you get today.
- **Your workflow.** Your prompts, tools, and checks still define the job. A Compiled Agent Model runs that job. It doesn't replace your product logic.
- **Your client code.** It's the OpenAI-compatible chat completions request you already send, with a different base URL and model name.

## What the numbers look like

Repeat runs are often 10-100x cheaper on our tests. On one measured invoice reconciliation run, a Compiled Agent Model was about 450x cheaper and 16x faster than Opus 5.5. That is one run of one task per model, not a claim about every workflow. See the [repeat-cost essay](/blog/ai-agent-repeat-costs).

## Related

- [Quickstart](/docs/quickstart)
- [Fallback models](/docs/fallback-models)
- [Cookbook](/docs/use-cases)