Managed execution
Start with the production path that exists today.
If you want repeat managed execution, the honest default is governed API key first. Use pricing to understand the rail, use quickstart for free reads, use x402 only when zero-signup per-call payment is the point, and bring BYOK or Agent Vault only when provider control is the point.
Best fit today: new agent projects, a narrow repeat workflow that needs a governed execution path, or a team that wants proof before the first paid call. Not the default move yet for broad multi-system automation migrations.
1. Start with governed API key
If you want repeat managed execution, this is the default production path today. It keeps repeat traffic on the stable X-Rhumb-Key execution header and the simplest operational model.
2. Check pricing before the first paid call
Discovery stays free. Execution is pay-per-call, so review the rail chooser and cost model before you wire it deeper.
3. Keep quickstart for free reads
If you are still evaluating, stay on the no-signup read path first. Paid execution should follow a real workflow, not curiosity clicks.
The honest default is governed API key, but the right next step still depends on whether you are evaluating, putting managed execution into repeat use, or crossing into your own systems.
Governed API key
Use this when you want repeat managed execution on the cleanest rail Rhumb exposes today.
Get governed API keyQuickstart first
Stay on free reads when you are still testing capability fit and do not want to wire paid execution yet.
Use free quickstartBYOK or Agent Vault
If the workflow needs your own provider accounts, workspace data, or production systems, review the credential paths before you execute.
Review credential pathsSelf-onboarding is only safe when setup creates bounded authority.
An agent-friendly first run is not a blank check for autonomous setup. The useful bootstrap path separates inspection, claim, credential choice, and execution so the first paid action inherits a boundary the operator can audit.
- Name the actor before the first call: human operator, agent principal, workspace, credential lane, and quota owner should not be inferred from a broad session token.
- Separate inspect, claim, and execute. A bootstrap flow can let an agent discover fit without silently minting production authority or touching customer systems.
- Make the credential path explicit before side effects: governed Rhumb key, BYOK, Agent Vault, or no paid execution yet.
- Record the claim semantics in trace context so the next run can prove which setup step created authority, who approved it, and what recovery path exists if the first action fails.
If the setup step cannot name the actor, credential lane, quota owner, and recovery path, stay on free quickstart or inspect credential paths before promoting the lane.
The capability id has to be validated before authority is read.
Managed execution becomes auditable when the request names the exact capability it is allowed to run. Resolve can help choose that capability, estimate can price it, and execute can run it, but a malformed execution path should stop before credential lookup, policy evaluation, or provider routing.
- Treat the capability id as the execution object, not a decorative URL segment. A blank or missing id should fail before policy, credential, or provider selection starts.
- Resolve the capability from the public catalog before promotion. The paid call should inherit an explicit capability id, interface, credential mode, and cost ceiling instead of reconstructing intent from chat text.
- Keep the same id through resolve, estimate, execute, and receipt review so recovery can tell whether a retry continued the original job or drifted into a neighboring capability.
- When the id is invalid, return a typed parameter error and no policy read. That is the boundary that keeps malformed execution requests from becoming authority probes.
If you do not have a stable capability id yet, start at capabilities or use the free quickstart before wiring paid execution.
The rail header is part of the authority boundary.
The first paid call should prove more than capability fit. It should prove the request entered through the intended rail before any telemetry, billing, credential, proxy, or provider state can observe it. Header validation is the boring preflight that keeps a pricing experiment from turning into an accidental execution probe.
- Send the intended rail header only: X-Rhumb-Key for governed execution, X-Payment for per-call x402, or provider credential context for BYOK and Agent Vault paths.
- Reject missing, malformed, or mixed headers before telemetry, billing, credential lookup, proxy routing, or provider execution can observe the request.
- Carry the normalized auth mode into the estimate, execute, receipt, and retry trace so a later recovery step can prove which credential lane and budget owner were used.
- Treat header validation failures as typed preflight outcomes, not provider errors. The boundary is working when a bad key never becomes a billable or side-effecting attempt.
For E-006, count a governed-key click as stronger intent only when the downstream path preserves the normalized auth mode and budget owner through estimate, execute, receipt, and recovery. Otherwise it is just another ambiguous CTA click.
The governed key lane starts before the first API key is issued.
A managed-execution proof sprint is only trustworthy if the admin surface creates agents, grants service access, and reports usage with the same boundary discipline as the execution path. The newest product truth treats agent names, owners, services, and rate limits as authority inputs, not dashboard decoration.
- Create the agent only after name, organization id, and global QPM are normalized and validated. Blank owner fields and out-of-range rate limits should fail before identity-store writes.
- Grant service access only after the service name is canonicalized onto the public slug and the per-service QPM override is bounded. Aliases should collapse before policy, credential, or usage state sees them.
- Reject blank agent ids, blank service values, invalid status filters, and invalid usage windows before broad admin reads or writes can run.
- Keep service labels canonical in usage summaries so one provider lane does not split into multiple budgets, traces, or dashboard rows just because the caller used an alias.
For E-006, a governed-key signup is stronger evidence only when the admin setup preserves a bounded actor, canonical service grant, quota owner, and typed rejection path before any managed call can spend budget.
Credential-mode normalization has to happen before database authority is resolved.
Database reads are a sharper managed-execution boundary than generic discovery. The newest product truth normalizes the Agent Vault credential mode and token before DSN resolution, then binds the vault token to connection, agent, and organization context before any read executor can observe a database handle.
- Normalize credential_mode before route execution. The DB read lane should treat ` AGENT_VAULT ` and `agent_vault` as the same explicit credential path, not two different budget or trace families.
- Trim X-Agent-Token before DSN resolution. Whitespace around a signed vault token should not become a false credential failure, and blank tokens should still fail before DSN lookup or database connection.
- Bind the token to connection_ref, agent id, and org id before any query, schema, or row-read executor sees a DSN. Vault resolution is the authority boundary, not a convenience parser.
- Preserve the normalized credential mode and connection reference in the result and failure audit so recovery can tell BYOK errors from Agent Vault authority errors.
For E-006, a database workflow-fit request is stronger only when the caller can name the connection reference, credential lane, denied neighboring connection, and audit proof that the vault token was normalized before a query could run.
If the agent can run commands, start smaller than a shell.
Remote-command MCPs are attractive because they turn suggestions into action. Managed execution should not copy that power as a generic terminal lane. The paid path is only honest when the first command-shaped workflow has a named runbook, bounded target, explicit approval rule, and receipt evidence before production systems are touched.
- Name the runbook before execution. A broad shell request should not be promoted into provider credentials, target inventory, or billing until it maps to an approved command class.
- Bind the target first: host group, container, working directory, environment allowlist, max runtime, and rollback or verify command should be explicit before the command runner starts.
- Separate operator approval from retry. Missing approval, neighboring host, blocked flag, or unsafe directory should fail as a typed preflight outcome, not as a command error the agent retries.
- Carry command class, redacted arguments, target, approval source, exit code, stdout/stderr disposition, and recovery hint through the receipt so the next run can prove what happened.
For E-006, a remote-command workflow-fit request is stronger only when the caller can name the allowed command class, denied neighboring target, approval source, and recovery proof that would make the first execution boring.
Proof before the first paid call.
Managed execution is only honest if you can tell whether your workflow fits the launchable surface. Rhumb has 999 scored services and 435 capability definitions for discovery, but the current execution-ready surface is 18 callable providers and 21 MCP tools, strongest today for research, extraction, generation, and narrow enrichment.
New to the category? Start with what managed API execution means for AI agents, then use the first repeat workflow pricing guide before wiring the loop.
Not every service or capability in the index is executable through Rhumb today. Discovery breadth is wider than current callable coverage.
Start with governed managed execution when the job looks like the current beachhead and you want the fastest repeatable path.
- web search and live research
- scraping, capture, and extraction
- image generation and media transforms
- document parse, OCR, and structured extraction
- email verification and narrow enrichment
- classification, summarization, and content transforms
Need the public surface first? Inspect capabilities or read trust before you wire the paid path deeper.
If the workflow crosses into your own systems or sits outside the current launchable surface, do not force it through the managed lane just because it is convenient.
- deep CRM, support, GitHub, warehouse, or internal-tool automation
- workflows that must stay on your own provider contracts or compliance boundary
- general business-agent automation beyond the current beachhead
That is where BYOK or Agent Vault becomes the right next step instead of a generic managed-execution CTA.
Bring one workflow, not a vague platform bet.
If you would pay for Rhumb to make one agent-executed workflow safer, start with a proof sprint scope. The useful artifact is not a broad demo; it is the acceptance test, trace requirement, denial case, and launch boundary that would make the first paid call boring.
- one capability or workflow you would actually put behind an agent
- the failure you care about: scope escape, quota burn, stale provider contract, credential exposure, replay, or bad recovery
- the acceptance test that would make the first paid execution feel boring instead of magical
This is the narrowest commercial question: would a team ask Rhumb to scope the governed execution fix for a specific workflow after seeing the proof requirements?
- Capability or workflow: the exact repeat job, not a broad platform idea.
- Current boundary: Rhumb-managed, your provider account, workspace data, or another system of record.
- Expected repeat volume and cost ceiling: how often the agent will call it before a human reviews the result.
- One denial case: the neighboring target, tenant, domain, amount, or tool call that must fail closed.
- Trace proof: what receipt, log, or typed outcome would make the first paid call boring enough to trust.
Experiment tag: E-006. This is a scoped-inquiry signal, not proof of paid conversion until a real team asks for or starts a paid execution path.
If this is a real workflow, price the first repeat call.
The next honest step is not another generic demo. Pick one narrow repeat workflow, confirm it fits the live managed surface, estimate the call before execution, then decide whether a governed key is worth wiring into the loop.
- Use this path for one specific capability, not broad multi-system automation.
- Review pricing and estimate before the first side-effecting managed call.
- If the workflow needs your own provider account, switch to the credential-path review instead of forcing managed execution.
These links separate pricing curiosity, governed-key intent, and qualitative workflow fit so the signal is cleaner than a generic CTA click.
Use this path when the question is not "can Rhumb answer a free read call?" but "am I ready to put managed execution into a real workflow?"
If you still need to inspect trust boundaries, read Resolve, Pricing, and Capability-First Agent Onboarding first.
- Governed API key is the cleanest repeat-traffic rail today.
- Pricing, route checks, and cost checks should come before the first paid execution call.
- Use x402 only when zero-signup per-call payment is the point, and bring BYOK or Agent Vault only when provider control is the point.