Make the work you repeat faster and cheaper.

Find and optimize common agent workflows. Save 90%+ on tokens, cost, and wait time.

If you use Codex, Claude Code, or another AI agent for the same kinds of tasks again and again, this free prompt can turn them into faster, cheaper workflows and skills. In our tests, token use and latency fell by more than 90% while useful output quality stayed the same.

Try it on your own work: copy the prompt and drop it into Codex, Claude Code, or any agent that can read its past sessions. It will find one repeated workflow, optimize it, and show you the measured before-and-after.

See how and why it works →

COPY IT · DROP IT INTO YOUR AGENT · REVIEW THE MEASURED BEFORE-AND-AFTER

One prompt. A measurable result.

Copy the promptNo installation or account required

Paste it into your agentCodex, Claude Code, or any agent that can read its past sessions

Let it optimize one repeated taskIt builds a faster version in a separate folder

Compare before and afterTokens · cost · time · output quality

You decide what to keepNothing is installed or published without approval

01 / Proof

Typical repeated workflows. More than 90% less agent work.

Across repeatable, skill-driven agent workflows, the optimized versions used dramatically fewer tokens and finished much faster while useful output stayed the same.

Gains seen on typical repeatable agent workflows

15 historical scenarios

94–96%Fewer gross tokens

87–92%Less elapsed time

Up to 10×Fewer AI calls

SameUseful output quality

Observed across two repeated, instruction-driven workflows replayed over 15 matching historical scenarios. These are measured examples, not a universal guarantee; your result depends on how much of the workflow is predictable and repeated.

What these numbers mean.The original and optimized versions ran against matching past tasks. Token use, elapsed time, AI calls, and output usefulness were compared directly. The one-time cost of creating the optimization was reported separately.

02 / The tax

General agents are excellent at discovering a workflow. They are expensive at rediscovering it forever.

Reload the worldBroad instructions, history, memories and source trees flood the context again.

Replan the routeThe model chooses the same tools, order and stopping condition from scratch.

Rebuild stateDeduplication, lifecycle status and identity matching become another reasoning problem.

Re-argue the rulesSafety boundaries live in prose the model must remember instead of capabilities code can enforce.

Validate with more reasoningThe agent spends another turn deciding whether its own work followed the recipe.

03 / The shift

The model stops being the operating system.

A compiled harness does not remove intelligence. It relocates it. Stable procedure becomes executable; fuzzy judgment stays with the model; consequential actions stay with you.

Before · model-first skill

Instructions interpreted anew

Read the long skillUnderstand goals, sources, rules and exceptions

Plan + exploreChoose tools and navigate the filesystem

Reconstruct stateParse memory, normalize identity, deduplicate

Judge + generatePick the input and create the output

Self-validate + stopRemember safety rules and decide completion

compile into

After · specialized harness

Stable path, explicit judgment

Load + normalizeKnown adapters, typed state, exact matching

Build a bounded frontierEligibility, dedupe, evidence and ranking signals

Make the fuzzy decisionOne named purpose, small packet, typed output

Validate + renderSchema, policy, retries, artifact, terminal state

Approve consequencesPublish, send, install or override only by choice

Code owns invariantsModel owns semantic judgmentHuman owns consequences

04 / Method

Five moves from history to harness.

Treat past sessions the way a compiler treats profiling data: use observed execution to specialize the next version.

Profile

Cluster session history by the job performed—not just similar prompt wording.

Extract

Reconstruct the complete contract: inputs, tools, state, decisions, outputs and gates.

Partition

Separate stable procedure from irreducible judgment and human authority.

Compile

Emit source adapters, typed state, validators, bounded LLM calls and explicit terminal states.

Replay

Run old and new against equivalent raw inputs. Measure cost, latency, calls and quality.

05 / Ownership

Compile the routine. Preserve the judgment.

The boundary is the product. Compile too little and you keep paying the tax. Compile too much and you freeze the intelligence that made the agent useful.

Code

What is stable

Source paths and adapters
Parsing, normalization and exact identity
State transitions and retry limits

What must be enforced

Eligibility and capability gates
Schema validation and audit events
Artifact rendering and terminal states

LLM

What remains fuzzy

Semantic selection among valid choices
Interpretation of ambiguous language
Synthesis and natural-language generation

How it is bounded

One named purpose per call
Small evidence packet, no wandering
Typed output checked by code

Human

What stays consequential

Publishing and sending
Production installation
Business decisions and public voice

Why it stays here

Authority is not an optimization target
Approval is an explicit state
Safety is capability-shaped, not aspirational

06 / What the prompt does

Establish evidenceFind history; disclose gaps.

Profile workflowsRank frequent, viable candidates.

Reconstruct the old contractDo not erase inconvenient work.

Design the boundaryAssign code, model and human owners.

Build in isolationRunner, schemas, tests and fixtures.

Benchmark fairlyEquivalent raw inputs; comparable costs.

Protect qualityPredefined rubric; honest ties.

Report compilation costSeparate from recurring runtime.

Hand over something runnableDemo, use and install paths.

Read the full prompt

# Agent Workflow Compiler

Inspect my historical agent usage, identify the most frequently repeated workflow
that can be safely optimized, and build a working specialized harness for it.

Do not stop at recommendations. Produce an isolated implementation, replay it
against historical scenarios, measure the result, and give me something I can
actually run.

## Requirements

This prompt is intended for a local coding agent—such as Codex, Claude Code, or
a similar system—with access to:

- its historical sessions or exported traces;
- a local filesystem;
- a programming environment;
- the source material used by the repeated workflows.

If you cannot access historical sessions, say so clearly and identify the exact
history directory, export, or observability data I would need to provide.

Do not claim to have inspected history you could not access.

## Configuration

Use these defaults unless the environment makes them impractical:

- History lookback: 30 days
- Candidates to analyze: 5
- Minimum historical occurrences: 3
- Benchmark scenarios: 5, or up to 10 when inexpensive and readily available
- Maximum optimization iterations: 2
- Output: isolated local implementation plus a self-contained HTML report
- Production installation: disabled
- Commit and push: disabled
- External side effects: disabled

If executing the benchmark could incur more than approximately US$5 in model
usage, or if you cannot estimate the cost, show me the proposed benchmark and
pause before incurring that cost.

## Background: what “compiling an agent workflow” means

General-purpose agents are useful for discovering how to perform unfamiliar
work.

But when an agent performs the same workflow repeatedly, it often pays a
reasoning tax on every run.

It may repeatedly:

- reload broad instructions and context;
- rediscover which sources to inspect;
- choose the same tools;
- reconstruct the same state;
- normalize and deduplicate the same kinds of records;
- replan the same sequence;
- remember the same safety rules;
- decide when the work is finished;
- validate outputs through additional model reasoning;
- perform the same local bookkeeping.

A specialized harness moves the stable parts of that workflow into an
executable, task-specific runtime.

The typical transformation looks like this:

OLD, MODEL-FIRST WORKFLOW

Long instructions
→ general agent interprets the workflow
→ agent plans the execution
→ agent explores sources
→ agent chooses tools
→ agent reconstructs state
→ agent makes every decision
→ agent writes the output
→ agent tries to validate itself
→ agent performs allowed side effects
→ agent decides when to stop

NEW, COMPILED WORKFLOW

Thin activation instruction
→ deterministic source adapters
→ typed state and intermediate representations
→ deterministic normalization, routing, and eligibility rules
→ bounded LLM call where semantic judgment is needed
→ deterministic validation and side-effect gates
→ bounded LLM call where language generation is needed
→ typed output
→ explicit terminal state

Compiling does not mean replacing every LLM call with code.

It means:

- code owns stable procedure;
- code owns state transitions;
- code owns tool eligibility and side-effect boundaries;
- code owns checks that can be stated deterministically;
- the LLM remains responsible for irreducible semantic judgment;
- every retained LLM call has a named purpose;
- every retained LLM call receives bounded inputs;
- every retained LLM call returns a typed output;
- deterministic code validates what the LLM returns;
- the LLM becomes a component of the workflow rather than the workflow engine.

This resembles compiler specialization or partial evaluation:

1. Use historical runs as profiling data.
2. Identify the stable structure.
3. Separate stable procedure from surviving judgment.
4. Emit a runtime specialized for the repeated job.
5. Replay it against historical scenarios.
6. Compare the old and new execution economics.

It is not merely:

- shortening a prompt;
- changing to a cheaper model;
- caching one answer;
- fine-tuning;
- converting everything into rigid automation;
- eliminating useful semantic judgment;
- removing functionality to make a benchmark look better.

The compiled implementation must preserve the complete functional contract of
the original workflow.

## Safety and scope

Work only with local session history and local files unless I explicitly
authorize something else.

Do not:

- publish or schedule content;
- send messages or email;
- submit forms;
- change external systems;
- make purchases;
- modify production automation;
- replace an installed skill;
- commit or push code;
- expose private session contents in the report.

Build the compiled version in a new, isolated output directory.

Use replay, dry-run, read-only, temporary-directory, or fixture-backed adapters
for any workflow that normally has external side effects.

If a workflow cannot be replayed safely, reject it as the first implementation
candidate and explain why.

Do not interpret the existence of a draft as evidence that it was published,
sent, approved, or acted upon.

## Phase 1: establish evidence coverage

Find the normal session-history or trace storage used by this agent.

The history may come from:

- Codex session files;
- Claude Code project history;
- another coding agent;
- an observability system;
- exported conversations;
- structured execution traces.

Before analyzing it, report:

- which agent products are represented;
- the date range available;
- number of sessions and runs;
- whether complete prompts and outputs are available;
- whether tool calls are available;
- whether model names are available;
- whether input-token usage is available;
- whether cached-input usage is available;
- whether output-token usage is available;
- whether reasoning-token usage is available;
- whether elapsed time is available;
- whether external side effects are recorded;
- any missing or truncated evidence.

Do not include secrets, credentials, proprietary source code, private
communications, client information, or sensitive session contents in any
shareable output.

## Phase 2: profile my repeated workflows

Cluster historical runs by the underlying job, not merely by similar prompt
wording.

Two runs may represent the same workflow when they share most of the following:

- objective;
- input sources;
- tool sequence;
- state transitions;
- decision points;
- validation rules;
- output artifact;
- safety boundary;
- stopping condition.

Identify the five most frequently repeated workflows.

For every candidate, calculate or estimate:

1. Number of observed runs.
2. Average and total tokens, when available.
3. Average and total elapsed time, when available.
4. LLM invocations.
5. Model-controlled tool calls.
6. Repeated planning and context loading.
7. Structural stability.
8. Deterministic surface area.
9. Remaining semantic-judgment requirements.
10. Safety and replay feasibility.
11. Expected implementation effort.
12. Expected benefit from compilation.

Select the most frequent candidate that satisfies all of these conditions:

- it occurred at least three times;
- it has a recognizable, stable skeleton;
- it has clear inputs;
- it has a clear output or terminal state;
- meaningful repeated work can become deterministic;
- important semantic judgment can be isolated;
- it can be replayed without external harm;
- enough evidence exists for a fair comparison.

If the most frequent workflow is rejected, show exactly why and select the next
most frequent viable candidate.

Do not select a workflow that is already substantially compiled unless the
historical implementation still contains a meaningful repeated-reasoning
surface.

## Phase 3: reconstruct the complete old workflow

Select 5–10 representative historical runs of the chosen workflow.

Reconstruct everything the old agent was responsible for, including:

- activation and instruction loading;
- source discovery;
- source acquisition;
- memory and lifecycle state;
- normalization and identity matching;
- deduplication;
- eligibility decisions;
- ranking or selection;
- semantic interpretation;
- drafting or transformation;
- validation;
- retries and recovery;
- artifact generation;
- durable state updates;
- safety and approval boundaries;
- final user-facing response;
- stopping conditions.

Create a functional contract for the old workflow.

For every responsibility, record:

- the historical evidence that it existed;
- whether it is required for drop-in compatibility;
- its current owner;
- its proposed owner in the compiled version;
- why that ownership boundary is appropriate.

Do not omit difficult functionality merely to improve the benchmark.

Do not give the compiled implementation intermediate work that the historical
agent had to produce itself.

## Phase 4: design the compiled boundary

Partition the old workflow into the following categories.

### A. Deterministic runtime

Use ordinary code for work such as:

- known source locations and adapters;
- parsing known formats;
- normalization;
- exact identity matching;
- lifecycle-state reconstruction;
- deterministic eligibility rules;
- deterministic ranking signals;
- routing and phase transitions;
- retry limits;
- schema validation;
- exact source checks;
- artifact rendering;
- audit events;
- usage accounting;
- typed failures;
- capability and side-effect gates;
- durable local state updates.

### B. Bounded LLM judgment

Retain LLM calls for work such as:

- choosing among a small, evidence-rich candidate frontier;
- interpreting ambiguous natural language;
- semantic mapping;
- synthesizing information;
- producing natural-language drafts;
- evaluating genuinely fuzzy criteria.

Every retained LLM call should:

- have one named purpose;
- receive the smallest sufficient input packet;
- avoid model-controlled tools when possible;
- use a defined model and reasoning level;
- return a JSON-schema or otherwise typed result;
- be validated by the deterministic runtime;
- have bounded retries;
- preserve trace and usage data.

### C. Human approval

Keep human approval for:

- publishing;
- sending messages;
- changing production configuration;
- approving externally visible content;
- making consequential business decisions;
- overriding safety or eligibility gates.

### D. Activation layer

If the agent uses skills or similar instructions, create a thin activation layer
that:

- states the capability boundary;
- invokes exactly one runner;
- does not reimplement the workflow in prose;
- reads and returns the runner’s typed result;
- does not regain control of selection, validation, or side effects.

## Phase 5: implement an isolated working harness

Create a new implementation directory containing, at minimum:

- `README.md`
- a production-style runner;
- deterministic harness or workflow code;
- schemas for typed model inputs and outputs;
- source adapters;
- validators and safety gates;
- tests covering required functionality;
- replay fixtures or point-in-time input snapshots;
- benchmark scripts;
- benchmark data;
- a self-contained HTML report.

Prefer the project’s existing language and dependency conventions.

The implementation must provide one obvious command such as:

    ./run
    uv run python runner.py
    npm run workflow
    make run

The README must explain:

- what the harness does;
- required inputs;
- the command to run it;
- expected outputs;
- retained LLM calls;
- external capabilities;
- side-effect boundaries;
- typed failure states;
- how to run the benchmark;
- how installation would work later;
- what has and has not been verified.

Do not install it automatically.

Tests must exercise real deterministic logic.

Do not write tests that merely assert mocked behavior.

For filesystem side effects, use real temporary directories and verify actual
writes.

For external systems, use captured read-only evidence or explicitly bounded
replay adapters. Never execute historical external side effects.

## Phase 6: construct a fair benchmark

Compare the complete historical workflow with the complete compiled workflow.

The comparison must begin from equivalent raw inputs.

Do not make the compiled system’s job artificially easier by supplying:

- a preselected candidate;
- pre-extracted evidence;
- an already-resolved safety classification;
- a prepared source summary;
- an intermediate manifest that the old workflow had to create;
- other hidden intermediate work.

Use one of these methods:

### Method A: historical trace versus point-in-time replay

Replay the compiled harness against point-in-time raw inputs reconstructed from
each historical run and compare it with the corresponding historical
end-to-end trace.

### Method B: isolated old-versus-new execution

If point-in-time reconstruction is impossible, execute both old and new
workflows against the same current raw inputs in an isolated environment.

Explain which method you used and its limitations.

Separate these recurring runtime costs:

1. Outer agent or skill activation.
2. Core deterministic runtime.
3. LLM selection or interpretation calls.
4. LLM generation calls.
5. Model-controlled tool calls.
6. Non-model deterministic operations.

Measure, when available:

- gross token volume;
- cached-input tokens;
- uncached-input tokens;
- output tokens;
- reasoning-output tokens;
- non-cached token volume;
- elapsed time;
- number of LLM invocations;
- number of model-controlled tool calls;
- retry count;
- failure rate;
- policy compliance;
- output variance;
- output quality.

### Token accounting

Use the provider-reported total-token value when its semantics are documented.

Otherwise calculate:

    gross token volume =
        input tokens
        + output tokens

    non-cached token volume =
        max(input tokens - cached-input tokens, 0)
        + output tokens

Do not add reasoning tokens separately when they are already included in
provider output or total tokens.

Report reasoning tokens as a separate breakdown.

For every token metric, record:

- the source event or field;
- the provider;
- whether reasoning tokens are included in output or total tokens;
- whether cached tokens are included;
- any transformation applied.

If the semantics cannot be established, label the metric approximate.

If the platform does not expose a metric, label it unavailable. Do not estimate
precise token savings from transcript length alone.

Evaluation and judge calls must be excluded from recurring workflow economics
and reported separately.

## Phase 7: protect output quality

Create the quality rubric before judging the results.

The rubric must reflect how the output is actually used, not merely what is easy
to score.

A first-draft workflow might measure:

- correct candidate or input fit;
- source fidelity;
- useful substance;
- edit distance or rewrite effort;
- compliance with required format;
- safety compliance;
- side-effect compliance.

Compare old and new outputs blind when practical.

Treat ties honestly.

Treat me as the final arbiter of output usefulness.

If the compiled version loses required functionality, violates a policy, or
produces materially worse output, it has not succeeded even if it is cheaper.

You may perform up to two bounded implementation iterations to repair:

- missing functionality;
- validation failures;
- unnecessary LLM calls;
- obvious quality regressions.

Do not tune directly against all benchmark outputs in a way that invalidates
the comparison. Keep some scenarios as holdouts when enough data exists.

## Phase 8: measure one-time compilation cost

Measure and report the one-time cost of analyzing history and creating the
compiled harness.

Report, when available:

- agent/model tokens used to inspect and cluster history;
- agent/model tokens used to design and implement the harness;
- cached and non-cached token volume;
- compilation wall-clock time;
- benchmark replay usage;
- evaluation or judge usage;
- failed or unmetered attempts;
- human decisions required;
- files created or changed.

Keep these components distinct where the trace data permits.

Compilation cost must be reported separately from recurring runtime economics.

Do not:

- amortize compilation cost across future runs;
- allocate compilation cost into compiled per-run metrics;
- add compilation cost to the new runtime side of the benchmark;
- calculate a break-even run count unless I explicitly request one.

The report should have a clearly labeled section:

    ONE-TIME COMPILATION COST

The old-versus-new benchmark must continue to compare recurring execution costs
only.

If compilation usage cannot be measured completely, report the known measured
minimum and name the missing components.

## Phase 9: produce immediately usable outputs

The final deliverable must lead with the practical result, not the methodology.

Create a polished, self-contained HTML report with this structure.

### 1. Verdict

Show in the first screen:

- workflow compiled;
- observed historical frequency;
- old versus new gross token volume;
- token reduction percentage;
- old versus new elapsed time;
- latency reduction percentage;
- old versus new LLM invocations;
- old versus new model-controlled tool calls;
- old versus new quality score;
- whether replay functional parity passed;
- whether policy parity passed;
- evidence level.

Use one of these benchmark labels:

- `PROVEN`: at least five fair end-to-end scenarios with reliable usage data;
- `DIRECTIONAL`: useful replay evidence but limited scenarios or missing metrics;
- `UNMEASURED`: implementation exists but no trustworthy efficiency comparison.

Do not use a strong evidence label when required inputs or usage data are
materially incomplete.

### 2. What the workflow does

Explain the selected workflow in plain language:

- inputs;
- job performed;
- output;
- safety boundary;
- why it was frequently repeated.

### 3. Before and after

Include visual flowcharts for:

- the old model-first workflow;
- the compiled workflow.

Use distinct visual treatment for:

- deterministic code;
- LLM calls;
- tools;
- human approval;
- side effects.

### 4. Source-to-runtime crosswalk

For every old responsibility, show:

    OLD RESPONSIBILITY
    → NEW COMPONENT OR FUNCTION
    → OWNER: CODE, LLM, OR HUMAN
    → WHY

### 5. What was compiled

Explicitly list:

- work moved into deterministic code;
- work that still calls an LLM;
- work retained for human approval;
- functionality deliberately unchanged.

### 6. Benchmark

Show per-scenario and aggregate results.

Do not hide:

- outliers;
- failures;
- retries;
- wrapper overhead;
- degraded evidence;
- missing metrics;
- quality regressions.

Include the exact token-accounting method.

### 7. One-time compilation cost

Show:

- compilation wall-clock time;
- total measured compilation tokens;
- non-cached compilation volume;
- benchmark and evaluation costs as separate components;
- failed or unmetered attempts;
- human decisions required;
- measurement limitations.

State explicitly:

    Compilation cost is not amortized, allocated, or included in compiled
    per-run runtime metrics.

### 8. Use it now

Provide three distinct readiness levels.

#### DEMO IT

Provide a zero-side-effect replay command.

Label it as verified or unverified.

Explain its expected terminal state and outputs.

#### USE IT

Provide a live-equivalent isolated command that:

- uses ordinary current inputs;
- exercises normal output generation;
- writes only to the isolated implementation directory or a temporary directory;
- does not change installed production configuration;
- does not perform external side effects.

Label it as:

- `VERIFIED`, or
- `NOT LIVE-VERIFIED`.

Do not present a historical replay command as though it were the normal-use
command.

#### INSTALL IT

Describe the exact proposed activation or replacement steps.

State clearly that:

- installation requires explicit approval;
- the steps were not executed;
- no production skill or automation was changed.

### 9. Revised success standard

Evaluate the result against every condition below.

A compilation is successful only when:

1. The complete historical responsibility contract is represented.
2. Deterministic and model-owned stages have explicit boundaries.
3. Replay-mode functional and policy parity pass.
4. Live-mode responsibilities are tested or clearly labeled untested.
5. Quality is retained within a predefined practical tolerance.
6. Efficiency improvements use comparable, provenance-backed metrics.
7. Replay fidelity is disclosed.
8. One-time compilation cost is reported separately and is not amortized into
   compiled runs.
9. The user receives both a runnable replay demonstration and a live-equivalent
   isolated-use command.
10. Nothing is installed, committed, pushed, or activated without approval.

For every condition, show:

- `PASS`
- `FAIL`
- `UNTESTED`
- `DISCLOSED`, where appropriate

If any condition fails, identify it explicitly.

A compiled prototype may still be useful, but it must not be described as a
production-ready replacement unless the relevant production responsibilities
have been exercised and approved.

### 10. Installation decision

Explain:

- whether replacing the original workflow is recommended;
- maintenance cost;
- known limitations;
- what remains unverified;
- what approval would be required to install it.

Save the report locally and give me its exact path.

## Final chat response

Return a concise summary using this exact format:

COMPILED
[workflow name]

WHY THIS ONE
[frequency and reason it was selected]

RUNTIME RESULT
Gross tokens: [old] → [new] ([percentage])
Non-cached volume: [old] → [new] ([percentage])
Latency: [old] → [new] ([percentage])
LLM calls: [old] → [new]
Model-controlled tool calls: [old] → [new]
Quality: [old] → [new]
Replay functional parity: [pass/fail]
Policy parity: [pass/fail]
Evidence level: [PROVEN/DIRECTIONAL/UNMEASURED]

COMPILATION COST
One-time gross tokens: [value or unavailable]
One-time non-cached volume: [value or unavailable]
Compilation wall time: [value or unavailable]
Benchmark/evaluation usage: [separate values]
Unmetered components: [list or none]
This cost is reported separately and is not amortized into compiled runtime.

DEMO IT
[zero-side-effect replay command]
Status: [VERIFIED/UNVERIFIED]

USE IT
[live-equivalent isolated command]
Status: [VERIFIED/NOT LIVE-VERIFIED]

INSTALL IT
[proposed installation steps]
Status: NOT EXECUTED — REQUIRES APPROVAL

REPORT
[exact HTML path]

SUCCESS STANDARD
1. Responsibility contract: [status]
2. Model/code boundary: [status]
3. Replay functional and policy parity: [status]
4. Live-mode responsibilities: [status]
5. Quality tolerance: [status]
6. Comparable metrics: [status]
7. Replay fidelity: [status]
8. Separate compilation cost: [status]
9. Demo and isolated-use commands: [status]
10. No unauthorized activation: [status]

OVERALL VERDICT
[isolated prototype / production candidate / production-ready replacement]

CAVEAT
[most important limitation]

NOT INSTALLED
The original workflow has not been replaced, committed, pushed, or activated.

If no workflow can be compiled fairly, do not fabricate a success. Return:

- the candidate analysis;
- the blocker;
- the evidence that is missing;
- the smallest next step needed to obtain a measurable result.

Complete promptv2 · compilation cost separate · safe by default

02 / FAQ

Questions you may have.

Is this just advice for writing a better prompt?

No. It asks your agent to inspect real past work, build a working optimized version of one repeated task, and compare the old and new versions using measured results.

Why not just cache the context?

Caching can reduce input cost, but it does not eliminate model-controlled planning, tool routing, state reconstruction, retries or policy interpretation. A harness makes stable procedure explicit, testable and enforceable.

Does the optimized version stop using AI?

No. It keeps AI for the parts that need judgment or writing. Ordinary code handles predictable steps such as loading files, keeping track of progress, checking rules, and producing the final artifact.

What workflows are good candidates?

Frequent workflows with stable inputs, repeatable skeletons, clear terminal states, deterministic checks and safely replayable scenarios. One-off creative investigations and rapidly changing processes usually are not.

Will I definitely save 90%?

No. The headline numbers come from measured examples. Your savings depend on how much of the existing workflow is repeated coordination versus useful judgment. The prompt measures your actual result and requires honest evidence labels.

What if my agent cannot see its history?

The audit cannot proceed honestly without traces. Export the sessions or point the agent to its local history directory. Token and latency comparisons remain unavailable unless trustworthy usage fields exist.

Is it safe to run?

The prompt defaults to local files, isolated output, replay adapters and no external side effects. It forbids commits, pushes, installation and public actions. Still inspect your environment: session history itself may contain sensitive information.

Make repeated AI work faster and cheaper.

Optimize your agent.

Copy the prompt and drop it into Codex, Claude Code, or your agent of choice. It will find one repeated workflow, optimize it, and show you the before-and-after.

See how it works