# AI Agent Workflow Checker

**A paid, callable workflow planner for solo founders and AI agents.**  Give it a topic and constraints; it returns a short, execution-ready orchestration plan, the exact tool roles to use, a spend ceiling, and safety gates. Suggested list price: **$0.15 per `best-workflow` call** (range: $0.05–$0.50 by depth).

**Product question answered:** “What is the best autonomous-agent workflow for this topic?”

**As of:** 2026-10-21. This is a product and API specification, not a claim that a live endpoint or payment recipient already exists.

## What a buyer receives

A successful call returns JSON that an agent can act on without translating prose into a plan:

```json
{
  "goal": "Validate demand for a niche B2B SaaS idea",
  "workflow": [
    {"step": 1, "agent": "orchestrator", "action": "freeze scope and success metric", "exit": "one-sentence decision"},
    {"step": 2, "agent": "researcher", "action": "collect 3–5 primary sources", "exit": "claim ledger"},
    {"step": 3, "agent": "operator", "action": "run approved, reversible work", "exit": "draft result"},
    {"step": 4, "agent": "critic", "action": "check evidence, cost, and unsafe actions", "exit": "pass/fail findings"},
    {"step": 5, "agent": "orchestrator", "action": "repair or publish with provenance", "exit": "decision + artifacts"}
  ],
  "tool_plan": ["web/search", "IMD worker", "x402 client"],
  "budget": {"call_price_usd": 0.15, "suggested_external_spend_cap_usd": 1.00},
  "facts": [],
  "inferences": [],
  "uncertainties": [],
  "unanswered_questions": [],
  "common_mistakes": []
}
```

The valuable part is the **choice of sequence and gates**, not generic advice: the call turns a topic into a bounded job with an owner, inputs, tool permissions, spend limits, explicit stop conditions, and evidence requirements.

## Buy/use it today

### Tool catalog

| Tool | Route | Price | Use it when | Output |
|---|---|---:|---|---|
| Best autonomous-agent workflow | `POST /v1/workflows/best` | $0.15 | An agent has a goal but no reliable plan | ordered roles, tool plan, gates, evidence plan |
| IMD + x402 quick starter | `POST /v1/checklists/imd-x402` | $0.05 | Publishing or selling a callable agent tool | deployment and payment-readiness checklist |
| Token safety + deployment | `POST /v1/checklists/token-safety` | $0.10 | An agent may sign, pay, or use a wallet | wallet, spend, retry, and deployment controls |

Suggested depth multiplier: `brief` $0.05, `standard` $0.15, `production` $0.50. Price is a product decision, not a protocol fee. x402 itself states that it charges no protocol fee; network/facilitator costs can still apply.[^x402-site]

### Request contract: Best workflow

```http
POST https://<operator-host>/v1/workflows/best
Content-Type: application/json
Accept: application/json

{
  "topic": "compare two B2B CRM niches",
  "objective": "recommend one niche with cited evidence",
  "deadline_minutes": 45,
  "budget_usd": 1.00,
  "risk_level": "low",
  "allowed_actions": ["search", "draft"],
  "forbidden_actions": ["send email", "purchase", "deploy"],
  "depth": "standard",
  "output_format": "json"
}
```

`topic` and `objective` are required. `budget_usd` is a **maximum for downstream paid tools**, not permission to spend it automatically. Reject a request with an empty objective, deadline under one minute, or a `risk_level` outside `low|medium|high`. Return `400` with machine-readable validation errors before requesting payment.

The seller must configure its own HTTPS host, receiving address, supported `(scheme, network)` pair, asset, facilitator, and price. Do **not** hard-code a wallet/address, token contract, chain, or public facilitator into this product spec: those are operator-controlled deployment settings.

### x402 payment handshake

1. Agent submits the request without a payment payload.
2. The paid route returns `402 Payment Required` and a Base64-encoded `PaymentRequired` object in `PAYMENT-REQUIRED`.
3. The agent decodes the offer, checks the URL, exact price, asset, recipient, scheme/network, expiry and its local spend policy; it selects at most one acceptable offer.
4. Only if every policy check passes, the agent creates a payment payload and retries the **identical** request with `PAYMENT-SIGNATURE`.
5. The server verifies payment, produces the workflow, settles through its chosen configuration, and returns `200` with `PAYMENT-RESPONSE` plus the JSON result.

These header names and the 402/retry pattern are protocol facts from the x402 HTTP transport specification.[^x402-http] Server work should occur only after successful verification; the x402 reference flow places fulfillment after verification and settlement afterward.[^x402-flow]

## The recommended autonomous-agent workflow

### 0. Admission gate — orchestrator (30–60 seconds)

Create a compact job record:

```text
objective | decision owner | deadline | deliverable | allowed actions
sources required | max external spend | max tool calls | risk level | stop condition
```

If the task involves money, credentials, publishing, contacting people, destructive changes, or legal/medical/financial advice, require explicit permission at the relevant boundary. “Research” is not authorization to buy, deploy, send, or sign.

**Exit:** one measurable outcome, one owner, and a no-go condition. If absent, return questions—not a fabricated plan.

### 1. Plan — orchestrator (1–3 minutes)

Decompose into no more than five independently checkable work packets. For each packet specify: input, agent role, permitted tools, cost cap, evidence needed, and exit test. Start with reversible/retrievable work; place paid calls and irreversible actions behind approval gates.

Use a single coordinator to own state and final judgment. Parallel specialists may gather evidence, but no specialist may silently broaden scope or execute an external side effect.

**Exit:** a dependency-ordered queue and a spend ledger initialized to `$0`.

### 2. Gather evidence — researcher (time-boxed)

Collect primary/authoritative material first: official specifications, owner documentation, original datasets, and direct product documentation. Record every decision-relevant assertion in a claim ledger:

| Claim | Classification | Source URL | Retrieved date | Confidence | Effect on plan |
|---|---|---|---|---|---|
| x402 HTTP uses a 402 and `PAYMENT-REQUIRED` | fact | spec | 2026-10-21 | high | client must parse header |
| $0.15 is viable for a standard plan | inference | product choice | 2026-10-21 | medium | test conversion/compute margin |

Use external paid tools only where their unique output changes the decision. Before each call, compare its displayed price with remaining budget, set a timeout, and attach the tool output to the job record.

**Exit:** enough attributable evidence to support the final decision, or an explicit evidence gap.

### 3. Execute — operator (bounded)

Perform only the actions admitted in step 0. Keep inputs and outputs structured (JSON/files), validate schemas at each boundary, and make retries idempotent. For code or content, use a separate check step before release. For deployment, stage then smoke-test, rather than making production the first execution target.

**Exit:** artifact plus reproducible command/API record; no unapproved side effect.

### 4. Critique — independent reviewer

The reviewer receives the objective, constraints, evidence ledger, output, and spending record—not the orchestrator’s hidden reasoning. It must answer:

- Does each material factual claim have an attributable source?
- Are recommendations labelled as inferences rather than facts?
- Did any tool spend exceed its cap or use a mismatched chain/asset/recipient?
- Is the deliverable complete for the requested decision and format?
- What remains uncertain or unanswered?

If a material check fails, route the finding back to the smallest relevant packet; do not restart the whole job by default.

**Exit:** `pass`, or a short repair list with severity.

### 5. Deliver and learn — orchestrator

Return the recommendation, artifact links/identifiers, evidence ledger, exact spend, limitations, and the next safe action. Preserve request id, idempotency key, payment/settlement reference (if present), source URLs, versions, and timestamps. These make a later dispute or failure diagnosable.

**Exit:** owner can decide or execute the next approved action without asking the agent what it did.

## Required tool setup

### IMD

Use IMD as the managed worker/publishing layer when it fits the task. Its documented worker model advertises a tool only when required variables are set and the tool probe succeeds; use that readiness check before assigning a capability-dependent packet.[^imd-worker] Its documentation also describes worker-side build/typecheck/interaction validation for ordinary website skills, which supports keeping a verification packet in the plan.[^imd-worker]

Minimum operational checklist:

- [ ] Install/pair/configure IMD outside the agent task; keep secrets outside prompts and artifacts.
- [ ] Register only the capability the job requires; verify it is ready before planning around it.
- [ ] Give each run a narrow repository/path scope and a test/validation command.
- [ ] Publish only an approved built artifact; record the resulting location/identifier.
- [ ] Restart/re-check after a tool or configuration change if the worker documentation requires it.[^imd-worker]

### x402 client and server

- [ ] Use HTTPS and preserve the initial method, URL, headers, and body for the paid retry.
- [ ] Parse `PAYMENT-REQUIRED` from the response headers; do not assume the body contains the terms.[^x402-http]
- [ ] Allowlist schemes/networks/assets/recipients; enforce `max_price`, per-task and daily caps locally.
- [ ] Verify the response’s `PAYMENT-RESPONSE` and retain its settlement reference before marking the work paid/complete.[^x402-http]
- [ ] Choose a production facilitator deliberately. The x402 reference explicitly says not to assume the public facilitator is the default production path for mainnet EVM routes.[^x402-flow]
- [ ] Make the paid operation idempotent with a request/idempotency key; never create a fresh payment authorization merely because a network retry occurred.

## Cost estimate and controls

### Per-call price menu (seller-facing)

| Tier | Price | Included | Recommended maximum work |
|---|---:|---|---|
| Brief | $0.05 | one pattern + three risks | 1 topic, no live research |
| Standard | $0.15 | full workflow, tool plan, evidence plan, gates | 1 topic, bounded research/template retrieval |
| Production | $0.50 | standard + deployment/token safety adaptation | 1 topic, higher-risk review |

**Estimate, not fact:** A $0.15 call is viable only if average inference, retrieval, settlement, hosting, support, and refund/failure costs stay below $0.15 with the operator’s desired margin. Measure the actual cost per completed response for 50 calls before treating this as a durable price. Network fees and facilitator terms vary by chosen rail; x402’s “zero protocol fees” statement does not mean total cost is zero.[^x402-site]

### Agent-side spend policy

```json
{
  "currency": "USD",
  "per_call_max": 0.15,
  "per_task_max": 1.00,
  "daily_max": 5.00,
  "allowed_routes": ["https://<operator-host>/v1/"],
  "allowed_schemes_networks_assets": ["operator-approved only"],
  "require_human_approval_above": 0.50,
  "retry_policy": "reuse same idempotency key; reconcile before new authorization"
}
```

The placeholders above are configuration inputs, not values to guess. A deployer must explicitly select them from its own supported payment setup.

## Common mistakes to avoid

1. **Treating a 402 as permission to pay.** It is an offer. Check endpoint, recipient, exact amount, asset, expiry, scheme/network, and local budget before signing.
2. **Giving a broad-purpose agent a broad wallet.** Use an isolated, capped payment capability; never expose private keys in prompts, logs, repositories, or tool output.
3. **Double-paying after a timeout.** Keep an idempotency key and reconcile the prior attempt/settlement state before generating a new authorization.
4. **Assuming every x402 rail is interchangeable.** The specification requires client/facilitator support for the particular `(scheme, network)` pair.[^x402-flow]
5. **Starting work before payment verification.** Fulfil only after payment verification, and return machine-readable failure states.
6. **Shipping prose where an agent needs a contract.** Return schema-validated JSON with `facts`, `inferences`, `uncertainties`, and `unanswered_questions` every time.
7. **Calling an output “research” without provenance.** Keep source URLs, retrieval dates, claim classifications, and confidence next to material claims.
8. **Confusing validation with independent review.** A build/test pass checks mechanics; it does not establish that research claims are true or complete.
9. **Putting a secret, real payment address, or token choice in a reusable template.** Make those deployment configuration values with owner approval.

## Response quality contract

Every successful response must include all four fields below, even if empty:

| Field | Meaning | Rule |
|---|---|---|
| `facts` | directly supported, externally verifiable claims | include source URL and retrieval date |
| `inferences` | recommendations or conclusions drawn from facts | name the supporting fact IDs and confidence |
| `uncertainties` | material unknowns or source limits | say how they could change the recommendation |
| `unanswered_questions` | input needed to proceed safely or accurately | ask only questions that materially change execution |

Return `status: "needs_input"` rather than inventing a missing owner choice (such as payment recipient, production network, or approval threshold).

## Evidence, classification, and limits

### Facts

- x402’s HTTP transport uses `402 Payment Required`; the payment terms are carried in `PAYMENT-REQUIRED`, the retry payload in `PAYMENT-SIGNATURE`, and settlement information in `PAYMENT-RESPONSE`.[^x402-http]
- The x402 reference implementation/documentation describes a flow in which the server verifies a payload, fulfills the request after valid verification, and can settle via a facilitator; it also says scheme/network support is explicit.[^x402-flow]
- IMD’s published worker documentation says a tool is advertised only when its required variables are set and its probe responds, and that `imd tools`/`imd doctor` report readiness.[^imd-worker]

### Inferences

- A low-price, bounded JSON planning endpoint is more useful to agents than a static report because it can be invoked as a tool and its output can drive the next orchestration step. This is a product-design inference, not a measured demand result.
- The recommended coordinator/researcher/operator/reviewer pattern reduces avoidable scope drift and makes evidence review tractable. It is a pragmatic operating recommendation, not a universal proof of optimality.
- $0.05–$0.50 is an appropriate *test range* for a workflow-checking product only if completion rate and fully loaded unit cost support it; validate with real call telemetry.

### Uncertainties and unanswered questions

- No specific seller host, receiving address, token, chain, facilitator, wallet custody model, or jurisdiction is supplied. Those must be chosen by the operator before deployment.
- No target agent runtime, language, expected daily volume, model cost, or allowed data classes is supplied. Therefore this specification does not claim a final production margin, latency, or compatibility guarantee.
- Buyer willingness to pay has not been measured here. Run a small, consented price test before raising spend or committing to a rail.

## Source notes

[^x402-http]: [x402 HTTP transport specification](https://github.com/x402-foundation/x402/blob/main/specs/transports-v2/http.md), accessed 2026-10-21. Primary protocol source for the 402 and header assertions.
[^x402-flow]: [x402 reference repository: production path and typical flow](https://github.com/x402-foundation/x402), accessed 2026-10-21. Primary project source for the flow, facilitator warning, and scheme/network support assertions.
[^x402-site]: [x402 official site](https://x402.org/), accessed 2026-10-21. Source for its no-protocol-fee claim; payment-network/facilitator costs remain operator-dependent.
[^imd-worker]: [IdentityMD worker documentation](https://github.com/Identity-md/worker), accessed 2026-10-21. Source for the IMD worker/tool readiness and validation statements.