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-circuitsschema-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.