Runner vs Aileron: Competitive Assessment

A prosumer desktop assistant that connects to 50+ apps and runs multi-step tasks on your behalf, with credentials stored in Runner’s cloud, a user-level approval dial you can switch off, and SOC 2 Type 1 + CASA Tier 2 as its trust story. No public runtime, SDK, connector manifest, team vault, or audit trail.

Aileron’s Action is a capability unit: a deterministic execution path bound to an LLM-facing descriptor, with idempotency (ADR-0010), approval (ADR-0009), and audit declared at the manifest — so the model picks what to do while the runtime governs how. Actions compose into larger capabilities, and the planned Skills layer makes that composition a first-class, named artifact; team-scoped authoring and sharing follow the v5 vault-and-tenancy direction. Runner runs multi-step tasks within one user’s session and has an internal edit-policy, but exposes no authoring manifest, no SDK, and no shareable capability artifact — nothing a teammate publishes once and others reuse under the same governance. The distinction is a library of governed, shareable execution paths vs per-user task automation that ends with the session. (Skills and team sharing are Aileron roadmap, not shipped — but Runner has no public equivalent even on paper.)

Runner asks permission “before it takes an action for you,” then explicitly invites you to “turn these safeguards off and go really fast” — a per-user trust ratchet, not a policy engine, designed to be disabled. Aileron’s v4 runtime already owns the container PTY: approvals render on a surface the agent cannot see and land asynchronously so the agent never blocks, driven by per-action policy rather than a personal toggle. Team-scoped approval queues and delegation are the v5 extension. The shapes diverge most exactly where an enterprise buyer cares most.

Aileron’s v4 runtime is a container the customer operates — self-hosting is the core of the architecture, not an enterprise tier. Runner’s enterprise page claims “run models on-prem or in your VPC so inference never leaves your network,” but no deployment docs, Helm chart, or self-hosted connector framework is publicly visible. The difference is an architecture built around customer operation vs a marketing claim with nothing public behind it.

Aileron’s vault architecture is settled though not yet shipped: a user-derived KEK (Argon2id), per-secret AES-256-GCM, a random vault key wrapped per authorized member, with decryption bound to a TEE — landing as the team and multi-tenant primitive at v5 (v4 test/dev uses an in-memory vault). Runner’s security page asserts “Data is encapsulated” with no described mechanism, no team key model, and no per-member access. This is a designed Aileron primitive on the roadmap; Runner has no equivalent even on paper.

Nitro Enclaves on AWS, Confidential Space on GCP, Confidential VMs on Azure — the customer verifies through attestation rather than trusting a vendor assertion. Runner’s trust story tops out at point-in-time SOC 2 Type 1 and a CASA Tier 2 scoped to Google OAuth. Attestation is a structurally stronger claim than “bank-level encryption,” and Runner has nothing here.

Aileron declares audit shape per action, producing an enterprise-grade trail. Runner exposes user-facing session transcripts (pause/resume visibility) but no team audit log surfaced on any public page. Audit-trail switching cost compounds with time for the buyer who needs it.

Runner already shows SOC 2 Type 1, CASA Tier 2, and a plain-language security page (“you approve every action,” “disconnect at any time,” “connect only what you need”). A buyer skimming gets an immediate, badge-backed answer. Aileron’s deeper architecture is harder to convey on a skim, and “credential sealing at the TLS boundary” loses to a visible badge unless Aileron makes it legible.

Runner ships 50+ working consumer integrations with a managed connection layer and a 94-release cadence. On breadth and end-user polish of integrations available right now, Runner is ahead. Aileron’s curated, policy-bearing connector catalog is earlier and deliberately narrower — the right trade for the substrate, but a buyer counting logos sees Runner’s longer list.

”Save 6+ hours per week” at $50–$200/month is a value proposition a founder grasps in one sentence and expenses without a procurement cycle. Aileron’s infrastructure value is more abstract and a longer sale. Where the buyers overlap (a technical founder), Runner’s framing is the easier yes.

Runner’s “ask permission, then turn it off as you trust it” is a shipped, understood interaction. Aileron’s team-scoped policy HITL is more powerful but must become as legible and as pleasant to use, or it reads as friction next to Runner’s one-tap dial.

The core team built Clearco and Agora and ships at a high cadence. This is not a side project. A team this fast can close an architectural gap quickly once it decides to — which is exactly what makes the down-stack threat credible.

For a small team that wants outcomes and isn’t yet thinking about credential architecture, Runner is the lower-friction answer. Aileron’s advantages compound at the point a team starts caring about who holds its tokens — and Aileron has to bring the buyer to that realization rather than assume it.

Runner is the application; Aileron is the substrate. “Apps that act on your systems should be built on a runtime that seals credentials, not on cloud-stored OAuth.” This reframes Runner from competitor to exemplar of the category Aileron secures — and a possible consumer of it.

SOC 2 and CASA are table stakes Aileron should clear so it is never disqualified on a checklist — then differentiate above them with TEE attestation and per-action audit. “Verify through attestation, don’t trust our assertion” is a strictly stronger claim than a point-in-time Type 1.

A team that cannot let a vendor hold live tokens is structurally unable to adopt Runner’s cloud-stored model. That buyer is Aileron’s by construction. Make credential sealing the headline for exactly this segment.

Declared idempotency, approval, and audit per action are what a vendor needs to go upmarket. If Aileron’s manifest extensions become the way agentic actions are governed, any app moving enterprise — Runner included — adopts the substrate rather than reinvents it.

If Aileron’s credential, policy, and connector layer can sit beneath apps-that-act, a product like Runner could ride Aileron for the parts it has not built. Worth a one-page sketch even if the head-on developer/team sale stays the default.

A repeat-founder team raising and shipping an agent-that-touches-your-apps product is evidence the buyer problem exists. Cite it as category validation, then articulate where Aileron operates a layer down.

”Why not just use Runner?” is inevitable from any buyer who hasn’t yet separated application from infrastructure. Runner’s visible SOC 2 + CASA badges win the skim. The longer Aileron’s pitch stays abstract, the more buyers default to the legible option.

Runner positions MCP as its enterprise integration story. As MCP standardizes, the line between “app that uses MCP” and “runtime that hosts MCP” blurs for the buyer. Aileron must articulate what the substrate provides beyond vanilla MCP hosting — policy, idempotency, credential sealing, audit.

SSO, admin console, role-based access, and a team audit log would narrow the enterprise-controls gap without Runner rebuilding its credential model. The Teams & Enterprise tier already signals upmarket intent.

Runner’s one-sentence value prop and one-tap approval set buyer expectations for ease. An infrastructure-first product still has to meet that bar on the surfaces a human touches, or it reads as harder to use regardless of its deeper guarantees.

A flat $50–$200/seat is trivial to evaluate and expense. If Aileron’s pricing is harder to reason about at the point of overlap (a technical founder weighing both), the simpler model can win the deal before architecture enters the conversation.