Describe it. Automate it. Done.

The research

The pain and the gap aren’t Aileron inventing a wedge — they’re the analyst consensus.

The bimodal workforce. WRITER’s 2026 AI Adoption Survey — 79% of organizations face AI adoption challenges, up double-digit from 2025 — names the pattern directly: “a minority of intensive users captures most of the gains while the majority captures almost none.” Same survey: AI super-users deliver 5x productivity gains, nearly identical to the 5–6x Will Dellwo cited about his own work in the 2026-06-02 discovery call. Only 29% of organizations see significant ROI from generative AI, and 23% from agents — the gap between individual gains and organizational outcomes is real and measured.

Perpetual pilot, at population scale. MIT NANDA’s The GenAI Divide: State of AI in Business 2025 (research base: 150 leader interviews, 350-employee survey, 300 public AI deployments) found that 95% of enterprise GenAI pilots fail to deliver measurable ROI. Only 5% achieve rapid revenue acceleration. MIT’s root cause isn’t model quality or regulation — it’s the “learning gap for both tools and organizations” and “flawed enterprise integration,” i.e., the work required to make AI safe to roll out across an org. Internal builds succeed about one-third as often as buying from specialized vendors — meaning most companies cannot close the gap on their own.

Won’t vs can’t. The strategy frames the pain as prioritization — the 20% of safety work almost never gets justified against other priorities. MIT’s framing is capability — a learning gap and an integration gap. Both are real and complementary: the work doesn’t get done because (a) it’s hard, and (b) when it gets weighed against shipping the next feature, it loses. Will’s framing (won’t) comes from the discovery interview; MIT’s (can’t) comes from population data. Aileron addresses both.

Bottom line. The 5x super-user productivity gain, the bimodal-workforce framing, “no mechanisms to spread enterprise-wide,” the 95% pilot failure rate, and the “learning gap rooted in enterprise integration” — these are the analyst consensus from MIT, WRITER, Deloitte, and others. The positioning sits squarely on the gap the industry is already naming.

Sources

• WRITER — Enterprise AI adoption in 2026: Why 79% face challenges despite high investment
• WRITER — Key findings from our 2026 AI adoption survey
• AI2Work — The AI Productivity Gap: Why the Boom Isn’t Reaching Workers
• Deloitte — The State of AI in the Enterprise 2026
• Fortune — MIT report: 95% of generative AI pilots at companies are failing
• MindTheProduct — Why most AI products fail: Key findings from MIT’s 2025 AI Report
• Unframe AI — 95% of AI Pilots Fail

A concrete example

An auto dealer has just closed a financed sale. Five recurring steps follow: pull the deal from the dealership management system, open the customer in QuickBooks, send the DocuSign loan packet, send a welcome SMS, schedule the first-payment reminder. Today, a finance manager runs these by hand — or stitches them across half-finished integrations. As an Aileron Flight Plan, they ship as one signed, runnable artifact:

The finance manager Dispatches a Flight with one click — or a CRM webhook Dispatches one automatically after signing. The agent assembles the work from the bounded set of actions the Flight Plan declares against the dealership’s actual systems. Approval routes to the right person when the spend label trips; the welcome SMS waits on external-send confirmation; the audit log lands in the dealership’s own sink. No “agent” appears in the user’s view — the finance manager Dispatches a Flight; the outcome arrives.

What we sell: Flight Plans

A Flight Plan is a repeatable business process built for your organization. Author it once, customize it as your operations evolve, and share it across your team. Anyone authorized can Dispatch a Flight from it — no one has to run an agent to operate the work.

• Repeatable and customizable. Author one process for how your business actually does its work, then refine it as your operations evolve. The author is not the operator; the same Flight Plan is dispatched many times.
• Hooks into your services. Connects to the systems your team already uses — your CRM, your billing system, your document signing, your calendar, your DMS, your vertical system of record — so a Flight runs on real data in real systems, not on a copy in someone else’s cloud.
• Shared across your team. Once authored, anyone in the org can Dispatch a Flight: a sales rep, a customer success agent, a service desk operator, a manager. Authoring is a one-time act; dispatching is the daily one.
• Dispatched, not operated. Dispatching a Flight is a single action — click a button, submit a form, send a Slack command, click a portal link. The intelligence runs in the background; the operator stays in front of their actual work, not in front of an agent.

A small accounting practice authors a Flight Plan for new-client intake — collect info, create QuickBooks entity, send DocuSign engagement letter, schedule kickoff, make Drive folder. The principal customizes it for their template library; every associate Dispatches a Flight against it for every new client. A clinic authors one for patient discharge follow-up; nurses Dispatch Flights at end-of-shift. A real estate brokerage authors a lead follow-up packet; every broker Dispatches Flights as leads come in. An auto dealer authors finance-customer post-signing onboarding; the finance manager Dispatches a Flight after every signing. Each Flight Plan is the org’s — built on its stack, customized to its workflow, Dispatched by its team.

The ICP

The target organization is a business whose primary competence is not the creation of technology — a services business that runs on repeatable work, has real systems already in place, and does not have a dedicated AI/automation engineering team. Concretely:

• Industries: professional services (accounting, legal, real estate, financial advice), regulated services (clinics, dental, mental health), customer-facing operations (auto dealers, agencies, brokerages, customer success orgs inside larger SaaS), trades and small commercial operations.
• Size: SMB through mid-market, roughly 10–500 staff. Big enough that recurring work is a daily cost; small enough that the buyer is one or two roles deep, not a committee.
• Stack: already running a recognizable set of SaaS tools (a CRM, an email/calendar provider, a billing or invoicing system, a document tool, often a vertical-specific system of record). Aileron connects to what they have.
• AI posture: They want the benefits AI can deliver, not the operational burden of running it. They have read about agents; they would not bet a customer relationship on babysitting one. The point of bringing AI into the business is to free their team from the work, not to add a new system the team has to learn to drive.

SMB/mid-market is the initial wedge, not the addressable market. Fortune 500 buyers benefit from the same trust contract — arguably more, given regulatory burden, stack heterogeneity, and the volume of recurring work at scale — but they buy on 6–18 month procurement cycles through security, legal, IT, and business committees, and they expect enterprise features (SSO, SAML, SCIM, SOC 2 / HIPAA / FedRAMP attestation, advanced RBAC) that arrive in v4.x and v5. They are a downstream expansion target where the trust story compounds, not an exclusion. The wedge is SMB/mid-market because the buyer has unilateral authority, the sales motion is short, and v4 ships exactly the product they need today.

Less-fit segments: startups (engineering-rich, build it themselves, workflows still changing) and consumer (no recurring business outcome to package).

The buyer

Within the ICP, the buyer is the leader who owns the operational outcome and is on the hook when it breaks. Specifically:

• Roles: Director / VP of Operations, VP of Customer Success, practice manager, owner-operator at the small end, COO at the upper end.
• Decision criteria: “Will this make my team faster without making me explain to a regulator, a customer, or my board what happened when it went wrong?”
• Budget line: operational efficiency, customer experience, IT enablement. Already a line item; does not require a new “AI strategy” allocation.
• What they will not accept: “Trust us, the AI is safe.” “Connect your accounts and we’ll handle the rest.” “Your team will get used to the agent UX.” All three are common pitches from incumbents; all three lose this buyer.

This buyer is not the AI engineer (Composio’s customer) and not the integration architect (Workato/Boomi’s customer). There are roughly an order of magnitude more of them, they already buy software for this category of work, and they do not yet have a credible vendor for this problem.

The users

The end user is the buyer’s team or the buyer’s customers.

Neither population sees an “agent.” No chat-with-the-bot UX, no agent persona to debug, no “thinking…” spinner. They Dispatch a Flight; the work happens; the outcome arrives. The AI is in the work, not in front of the user.

The hidden agent: our unique approach to AI

This is the differentiated bet. Other AI-for-business products put the agent in the user’s face: a chatbot, a copilot, an assistant. Aileron puts the agent behind the user-visible surface, doing only the parts traditional computing can’t, bounded by a contract the org owns.

The agent does:

• Parses messy natural-language input into structured action arguments. An inbound email, a voice note, a customer message becomes “refund order 1234 for customer 5678 because of damaged goods.”
• Chooses among declared actions for the case at hand. The Flight Plan exposes a bounded set of actions; the agent decides which sequence to invoke for this specific instance.
• Generates the natural-language content the action needs at runtime — email bodies, summaries, replies. The action declares “send email”; the agent writes the body within the declared constraints.
• Absorbs long-tail branching — “customer already exists, look them up by email,” “this lead is enterprise, route differently” — without each edge case being hand-coded.

The agent does not:

• Hold credentials. The runtime does; the agent never sees them on outbound, and response redaction rules strip sensitive fields before they reach the agent on inbound.
• Choose which systems to talk to or what effects to have. The Flight Plan’s action contract is the only execution surface.
• Speak directly to the end user. Users see outcomes, previews, and approvals — not agent prose.

The action contract is what makes that freedom safe: the agent reasons broadly, but it can only execute what the Flight Plan’s actions declare, under the effects, approvals, and redactions those actions carry. This is the structural reason AI-enabled automation can be safe to ship to non-technical end users — a claim no agent-first product can credibly make today.

What we are not

The strategic bet

Three separate bets:

1. The unit choice is right. The Flight Plan — a repeatable, customizable, shareable business process — is the unit a non-engineer can author and a whole team can Dispatch. The trust contract sits inside it as the substrate, not the headline. This shape is structural and not retrofittable for competitors built on tool-shaped primitives.
2. The audience choice is right. Aileron applies AI intelligence to an audience that doesn’t principally need to use AI — they want the benefits in their organization, not a new system to operate. Services businesses at SMB/mid-market have recurring work, real budget, and no credible vendor for AI-enabled automation that fits this posture.
3. The UX choice is right. Erasing the “agent” from the end-user surface — Dispatching a Flight, not running an agent — is what makes this product safe to roll out to staff and customers who shouldn’t have to evaluate AI to use it.

The strategy holds if all three land. Validation comes from one real customer authoring one real Flight Plan against their actual stack and a real team Dispatching real Flights from it — not from more strategy writing.