The Enterprise App Store Is Fading — Agents Want Interfaces, Not Apps

Enterprise software is on the brink of a structural shift: the most valuable “applications” in the next era won’t be mass-market products you install.

They’ll be small, bespoke systems synthesized on-demand by agents—assembled from APIs, event streams, and permissions.

A great example comes from Andrej Karpathy. He described a moment that feels like a preview of what’s next: he decided to run an 8‑week experiment to lower his resting heart rate from 50 → 45, with a specific training plan (Zone 2 minutes + one HIIT session/week). About an hour later, he’d “vibe-coded” a custom dashboard to track the experiment—an agent reverse engineered a treadmill cloud API, pulled raw data, processed it, built a frontend, and iterated through bugs like unit mismatches and calendar alignment.

Reference: Karpathy’s tweet: https://x.com/karpathy/status/2024583544157458452

This isn’t just a fun personal story. It’s the enterprise roadmap in miniature.

---

1) There won’t be an app for that (and that’s correct)

Karpathy’s dashboard is exactly the kind of thing that should not exist as an App Store product:

• it’s extremely specific
• it’s time-bound (8 weeks)
• it’s personal/contextual
• it’s small (hundreds of lines of code, not a “company”)

In the agent era, the default flips from “find the right app” to:

describe intent → brief Q&A → software appears

That’s not a UX gimmick. It’s a fundamental change in software economics. The long tail of needs is too long for traditional productization—and too valuable to ignore.

---

2) The winners will be sensors + actuators with agent-native ergonomics

The deeper lesson is about interfaces.

Karpathy’s treadmill is a sensor: it converts physical activity into digital state. The frustrating part wasn’t building a dashboard—it was that the agent had to reverse engineer access to the sensor’s data.

That pattern is everywhere in enterprise:

• HRIS is a sensor (headcount, roles, status) + actuator (onboarding, access changes)
• ERP is a sensor (invoices, spend) + actuator (approvals, payments)
• ITSM is a sensor (incidents, alerts) + actuator (routing, escalation)
• CRM is a sensor (pipeline, activity) + actuator (tasks, outreach, updates)

Most enterprise tools already are sensors and actuators. They’re just trapped behind human workflows and brittle “click-path” documentation.

Agents don’t want your UI. They want your capabilities.

---

3) The 1-minute app: what needs to be true

Karpathy’s story is impressive because it took ~1 hour instead of ~10 hours a couple years ago.

But the more important question is: what has to change so it takes 1 minute?

For “software on demand” to feel inevitable, enterprises need:

• agent-ready auth (scoped, auditable, easy to revoke)
• complete typed APIs (accurate schemas, consistent errors, real pagination)
• event streams (subscribe to change instead of polling UIs)
• reliable tool discovery (agents can find the right endpoints quickly)
• sandboxed execution (safe planning + safe acting)

This is where “AI features” stop being a product checkbox and become infrastructure.

---

4) Docs-as-HTML is increasingly the wrong artifact

A lot of products still ship docs that assume: a human reads a webpage and then clicks around a UI.

In 2026, that’s a regression. Humans don’t want to be a computer. Agents shouldn’t have to be either.

The new expectation is:

• docs should be agent-ingestible
• examples should be executable
• interfaces should be composable (CLI/SDK/API), not just clickable

---

5) Code Mode + MCP points toward the best “agent interface” packaging

Cloudflare’s recent post on Code Mode and MCP (Model Context Protocol) provides a pragmatic pattern for tool access at scale:
https://blog.cloudflare.com/code-mode-mcp/

The key idea: exposing thousands of endpoints as individual tools doesn’t scale—context windows fill up, and agents become slow and brittle.

Cloudflare’s approach is to keep a tiny tool surface (e.g., search() + execute()) and let the agent write code against a typed API representation, executed safely in a sandbox.

For enterprise vendors, the takeaway is straightforward:

• don’t ship “an AI chat bubble”
• ship an agent-optimized interface layer:
  • discoverability
  • typing
  • safe execution
  • stable semantics

---

What “agent-friendly enterprise software” looks like

This is the bar we expect to become table stakes:

1. Full API coverage (not partial, not “coming soon”)
2. Accurate schemas (OpenAPI/GraphQL/JSON Schema that match reality)
3. Agent-native auth + audit (scopes, logs, approvals, revocation)
4. Composable CLI/SDK (designed for chaining + automation)
5. Events first (webhooks/streams as default, not an afterthought)
6. Safe automation primitives (dry-run, policy checks, reversible operations)

---

The shift: bespoke, ephemeral software becomes normal

The app store era was about choosing from a catalog of pre-built software.

The agent era is about synthesizing the exact software you need, when you need it—built from services that expose sensors and actuators with great ergonomics.

It’s not fully here yet. But the direction is clear.