Skip to content

Agent Recipes

Use these copy/paste workflows to build RQM Platform and RQM Studio integrations without guessing undocumented behavior.

Always read /llms.txt, /api/overview/, and Swagger UI first. Prefer documented routes and schemas over inferred behavior.

Recipe cards

Validate a circuit payload

  • Goal: confirm a circuit payload is acceptable at the public boundary before downstream steps.
  • Inputs: rqm-circuits schema-aligned payload target (0.2), API base URL, request metadata.
  • Expected outputs: validation status, response envelope, error details (if invalid), stored request/response artifact JSON.
  • Docs to read first: Circuits API, Canonical Circuit Boundary, API Overview.
  • Safety/caution: do not call optimize on unvalidated payloads; confirm exact schema in Swagger UI before implementation.

Analyze a circuit

  • Goal: run documented analysis on validated payloads.
  • Inputs: validated circuit payload, analysis route confirmed in docs/Swagger, request ID.
  • Expected outputs: analysis data and metadata in standard envelope, archived JSON artifacts.
  • Docs to read first: Circuits API, API Overview.
  • Safety/caution: never invent analysis fields not present in response; preserve meta.

Optimize a circuit safely

  • Goal: request optimization under trust-sensitive, proof-gated posture.
  • Inputs: validated payload, confirmed optimize route/schema, optional execution intent.
  • Expected outputs: optimization candidate output, before/after metrics when available, verification/trust metadata.
  • Docs to read first: Circuits API, Optimization Engine, Verification / Trust.
  • Safety/caution: use conservative claims; do not claim guaranteed advantage or undocumented speedups.

Generate a verification/trust report

  • Goal: expose reproducible trust artifacts for optimization outcomes.
  • Inputs: request/response JSON artifacts, reported metrics, documented trust principles.
  • Expected outputs: verification report bundle (inputs, outputs, diffs, metadata), auditable summary.
  • Docs to read first: Verification / Trust, API Overview.
  • Safety/caution: treat optimization as candidate behavior unless verified by documented outputs.

Route execution through a provider bridge

  • Goal: route validated/optimized payloads through documented execution workflows.
  • Inputs: execution target/provider, validated payload, documented execution API behavior.
  • Expected outputs: execution request artifact, provider route metadata, response status.
  • Docs to read first: Execution API, Execution Bridges, API Overview.
  • Safety/caution: execution options are capability-gated; confirm provider-specific requirements before submission.

Build an RQM Studio workflow

  • Goal: build UX flows that orchestrate API calls while preserving platform boundaries.
  • Inputs: Studio use case, API routes, boundary rules, trust requirements.
  • Expected outputs: workflow states, user-facing labels, artifacts linked to each step.
  • Docs to read first: Agent Portal, RQM Studio, Canonical Circuit Boundary.
  • Safety/caution: Studio is workflow/UI, not the canonical computation contract.

Generate an API client

  • Goal: scaffold typed integration code from documented surfaces only.
  • Inputs: Swagger/API routes, response envelope contract, documented examples.
  • Expected outputs: typed modules, error handling, fixture-based tests, validate-before-optimize helper.
  • Docs to read first: API Overview, Circuits API, Agent recipe: API Client Generation.
  • Safety/caution: never generate undocumented methods or inferred schemas.

Debug a failed payload

  • Goal: isolate request construction vs schema vs route mismatch errors.
  • Inputs: failing request/response, endpoint docs, schema target, correlation/request metadata.
  • Expected outputs: root-cause note, corrected payload candidate, regression fixture.
  • Docs to read first: Circuits API, API Overview, Validate → Optimize.
  • Safety/caution: keep failure artifacts; do not “fix” by silently dropping unknown fields.

Separate production API behavior from research concepts

  • Goal: keep implementation claims grounded in shipped/documented surfaces.
  • Inputs: feature description, source docs, status label (production/beta/research/planned).
  • Expected outputs: boundary classification, safe implementation notes, user-facing wording.
  • Docs to read first: Production vs Research Boundary, Verification / Trust, Canonical IR.
  • Safety/caution: label research-only ideas explicitly and avoid production guarantees.