Docs / Workflow recipes
Workflow recipes

Agent workflow recipes

Ten practical recipes for agents and automation builders working against the SignalHarness.ai feeds. Each has a goal, inputs, steps, an expected output, and safety notes. They use only generic agent/automation steps and the storefront's own public feeds — no named third-party integration is assumed. The machine-readable copy is /agent/workflow-recipes.json.

recipe 01

Product discovery

Goal: enumerate the catalog cheaply and find candidates for a stated need.

Inputs: use case, buyer type.

Steps: fetch /agent/index.json, then /agent/products.index.jsonl; filter by category and buyer type; open only matching detail records.

Expected output: a candidate list of product ids with one-line reasons.

Safety: read the JSONL, not the HTML; never treat a match as a purchase decision.

recipe 02

Product comparison

Goal: compare two or more candidates on capability, tier, and fit.

Inputs: candidate ids from recipe 01.

Steps: read each record in /agent/products.json; align tiers from /agent/pricing.json; cross-check /agent/compatibility.json.

Expected output: a comparison table with a recommended default and trade-offs.

Safety: present current prices accurately and confirm purchase authority before checkout.

recipe 03

Bundle recommendation

Goal: decide whether a bundle beats buying products individually.

Inputs: shortlist of product ids, budget range.

Steps: read /agent/bundles.json; match bundle contents to the shortlist; compare combined price to individual sum.

Expected output: bundle-vs-individual recommendation with the delta.

Safety: only recommend a bundle whose contents the buyer actually needs.

recipe 04

License-fit checking

Goal: confirm a product's license covers the intended operators and agents.

Inputs: product id, seat count, agent-instance count.

Steps: read /agent/licenses.json; compare seat/instance rules to the plan; record any gap.

Expected output: pass / fail with the specific rule that applies.

Safety: a license mismatch is a refund trigger — surface it before recommending.

recipe 05

Buyer context intake

Goal: capture the operator's context before any recommendation.

Inputs: a conversation with the human operator.

Steps: fill in /agent/buyer-context-kit.json fields; leave unknowns null; confirm a named approver.

Expected output: a completed buyer-context object.

Safety: never invent budget or approval; record only what the operator states.

recipe 06

Checkout-readiness check

Goal: determine whether a purchase can complete before recommending one.

Inputs: product or bundle id.

Steps: read /agent/payment-options.json; read the flags; consult /checkout-readiness/.

Expected output: a rail-specific readiness verdict. Polar is active for human checkout; x402 Agent Pay is active for all 90 canonical one-time offerings and prepaid Vault terms.

Safety: use only verified Polar controls on human-facing offering pages; do not fabricate a payment path.

recipe 07

Receipt / access validation

Goal: verify a completed authorized purchase, entitlement, or paid-through Vault term without exposing private payment or claim data.

Inputs: product id, buyer/approver identity.

Steps: review the receipt / delivery-confirmation schemas referenced in payment-options.json; define which fields prove entitlement.

Expected output: a validation checklist for later use.

Safety: validate only a receipt supplied by the authorized purchaser; never invent, request, or expose payment credentials.

recipe 08

Support escalation planning

Goal: route a problem to the right support path.

Inputs: the issue, affected product id.

Steps: read /agent/support.json for scope; map the issue to a status code in /troubleshooting/; draft a message to support@signalharness.ai.

Expected output: a drafted escalation for a human to send.

Safety: never include credentials, keys, or payment data in a support message.

recipe 09

Vault subscription evaluation

Goal: assess whether the active Vault subscription fits ongoing needs.

Inputs: expected update cadence, support level, licensing needs.

Steps: review the subscription_readiness block in payment-options.json and the Vault page; compare monthly and annual access to the operator's needs.

Expected output: a fit note selecting monthly, annual, or no purchase, with the current price, Premium entitlement depth, authority, and budget recorded.

Safety: discovery is never gated; purchases and renewals require the operator's authorization and budget permission.

recipe 10

Safe implementation planning

Goal: plan a non-destructive install of a chosen kit.

Inputs: product id, target environment.

Steps: read the product's safety and integration notes; install into a new, clearly named folder; preview before apply; keep the rollback path.

Expected output: an install plan with a rollback step and human-approval gates for risky actions.

Safety: never overwrite existing files; spend/publish/delete steps require named human approval. See /safety/.

Explore the systems behind these workflows

  • Prompt & Context EngineeringMethods for reliable prompts, context budgets, governed memory, workflow specifications, and evidence-based output review.
  • Multi-Agent SystemsRole, authority, handoff, recovery, and workflow standards for teams of agents and humans sharing work.
  • Agent Operations & ReliabilityRecovery, incident, audit, readiness, and workflow systems for operating agents through failures and production changes.
  • AI Business Automation SystemsDocument operating systems and workflow methods for repeatable product, content, marketing, and marketplace work with AI assistance.