How it works
RunwayCtrl is building a pre-release execution control plane for production agents.
In v0.1 (design partner preview) we're focusing on policy, bounded retries, and reconstructible execution receipts at the tool boundary.
Why it exists
- •Duplicate incidents and comments when agents retry under failure
- •Retry storms that amplify partial outages into full ones
- •Racing agents that apply conflicting remediations
- •No way to reconstruct what happened during a postmortem
The core mental model
Every tool call flows through a single pipeline. The pipeline is designed to enforce policy, record attempts, and optionally emit traces (when enabled).
tool call → ActionKey (stable action identity) → policy gate → attempt ledger → trace emissionActionKey is an idempotency key for agent writes: same intent → same key.
Tool call: The agent requests a write action (create incident, post comment, set label).
ActionKey: Developer-provided OR derived from canonicalized/normalized action inputs (tool + resource + operation + key fields). If two calls share an ActionKey, they represent the same write and can be deduped/replayed.
Policy gate: The request is checked against retry budgets, concurrency leases, and rate limits. If policy is violated, the call is rejected before execution.
Attempt ledger: Every attempt (success or failure) is recorded with metadata, timing, and outcome.
Trace emission: OpenTelemetry spans are emitted and linked to the attempt record for distributed tracing.
The four primitives
Policy Gate
v0.1 focus — Execution controlA policy-enforced checkpoint between the agent and the tool. Designed to check every write request against retry budgets, concurrency leases, and rate limits before execution.
- •Unbounded retries that amplify outages
- •Unreviewed tool writes hitting production
- •Writes that violate rate limits or quotas
- ○Retry budgets and backoff curves
- ○Rate limits per tool/action
Attempt Ledger
Append-only recordAn append-only record of every tool attempt, outcome, and metadata. The source of truth for governed actions.
- •Unreconstructible runs
- •Missing audit trails for write actions
- •Disagreement about what was attempted
- ○Retention period
- ○Fields to redact (optional)
Retry Governance
Bounded retry behaviorBudgets, exponential backoff, jitter, and stop rules that prevent retry storms. Retries are scoped to the action, not the agent.
- •Self-DDoS via unbounded retries
- •Escalation loops under partial failure
- •Cascading failures across integrations
- ○Max attempts per action
- ○Backoff curve (exponential, linear, custom)
Concurrency Leases
Scoped permissionsShort-lived leases that prevent multiple agents from racing the same action. Only one agent holds the lease at a time.
- •Conflicting remediations from parallel agents
- •Duplicate side effects from retries
- •Race conditions across agent instances
- ○Lease duration (TTL)
- ○Scope granularity (per-action, per-resource)
Attempt records
Every governed action produces a receipt (attempt record) and trace linkage. The ledger is the source of truth for governed actions — what happened, when, and why.
{
"schema_version": "0.1",
"attempt_id": "att_01H…",
"action_key": "github:comment:repo/owner#123:hash(intent)",
"integration": "github",
"actor": "agent:<name-or-id>",
"intent_hash": "sha256:abc123…",
"policy": {
"retry_budget": 3,
"backoff_ms": [250, 500, 1000],
"lease": "lease_01H…"
},
"outcome": "success",
"timestamps": {
"started_at": "2026-01-25T20:19:12Z",
"finished_at": "2026-01-25T20:19:12Z"
},
"trace": {
"trace_id": "4bf92f3577b34da6a…",
"span_id": "00f067aa0ba902b7"
},
"tool": {
"name": "github.issues.createComment",
"endpoint": "POST /repos/{owner}/{repo}/issues/{issue}/comments"
},
"redaction": false,
"error": null
}Example shape for v0.1 (may evolve during build)
Trace fields align to OpenTelemetry + W3C Trace Context.
How you adopt it
RunwayCtrl integrates at the tool-call layer. Wrap your existing tool calls, define policies, and start collecting receipts.
Wrap preview SDK
Use the preview SDK wrapper around your existing tool calls. The wrapper intercepts the call before execution.
Define ActionKeys + policies
Specify how to compute the ActionKey and what policy rules apply (retry budget, lease scope, rate limits).
Observe receipts + traces
Attempt records are stored in the ledger. Traces can export to your observability stack when enabled.
// Wrap tool calls with RunwayCtrl
const result = await runway.govern({
actionKey: "github:comment:owner/repo#123:intent_hash",
integration: "github",
policy: {
retryBudget: 3,
backoffMs: [250, 500, 1000],
leaseScope: "per-issue"
},
execute: () => github.issues.createComment({
owner: "owner",
repo: "repo",
issue_number: 123,
body: "Automated remediation applied."
})
});
// result includes attempt_id, outcome, trace linkageLanguage-agnostic pseudocode — SDK details may vary
What we store
Default metadata (v0.1 plan)
- ✓Attempt metadata (action key, actor, integration)
- ✓Timestamps (started, finished)
- ✓Outcomes (success, failure, reason)
- ✓Trace linkage (trace_id, span_id)
- ✓Policy decisions (budget used, lease held)
Not captured by default
- ○Secrets or credentials
- ○Full request/response payload bodies by default
- ○PII beyond actor identifiers
Payload capture, retention, and redaction are configurable; default is metadata-only.
What's in and what's not
In v0.1
- ✓PagerDuty: incident create/update governed (initial dedupe-safe patterns)
- ✓GitHub: PR/Issue write actions governed initially (comments, labels, status checks)
- ✓Attempt ledger per action
- ✓Bounded concurrency via leases
- ✓Retry governance (budgets + backoff + jitter)
- ✓Trace emission tied to attempts (when enabled)
Not in v0.1 (yet)
- ○Broad integration marketplace
- ○Full autonomous remediation (autopilot)
- ○Enterprise policy packs / compliance claims
- ○Human approval workflows (optional later)
We're starting with write-safety + receipts, not autopilot remediation.
What we target
As teams move agents from suggestion → execution, these failure modes go from rare → weekly.
We're starting with the failure modes teams hit the moment agents start writing to real systems.
Build with us
We're looking for teams running production agents that need governed execution.
- •Bring one real workflow (PagerDuty or GitHub).
- •We'll help define ActionKeys + policies for your writes.
- •Design partners get early builds, a shared Slack channel, and help defining ActionKeys + policies for one real workflow.