Why API-First Infrastructure Wins in an Agent-Driven World (2026)

Plain, the AI-native Customer Infrastructure Platform, was built API-first before there was clear market pull. We believed customer support would eventually need to be programmable, not just configurable. For years, that belief outpaced reality. Now, everything has changed.

In 1,350 conversations with B2B support leaders and engineers between January 2025 and April 2026, 100 teams cited AI as a hard requirement for their next support platform and 71% flagged AI capabilities as high-severity pain with their current tool. Every team in the cohort knew AI had to be at the center of their support motion. The question that separates the teams winning the next 12 months from the ones repeating Klarna's mistake is what architecture you bet on. Gartner predicted in March 2025 that agentic AI will autonomously resolve 80% of common customer service issues by 2029, with a 30% reduction in operational costs. The platforms that get teams to the 80% milestone will be the ones architected for amplification, not replacement.

This is our thesis on why.

Plain is used by Vercel, Sourcegraph, n8n, Raycast, Stytch, Sanity, Prisma, Voltage Park, Fly.io, Buildkite, Tinybird, Depot, Resend, Northflank, Granola, Clerk, Mintlify, Tines, and Ashby — the B2B SaaS teams shaping how customer support gets built in 2026.

What changed to make API-first infrastructure essential?

Two shifts happened simultaneously: AI reduced the cost of building systems that reason and respond, while software development speed collapsed from weeks to hours. Teams now build and iterate on internal tools at lightning speed. Bug fixes go from days to minutes.

The result: more companies are building their own AI agents. This is no longer R&D experimentation — it's how modern teams work. GitHub's Octoverse 2024 reports 97% of US developers have used AI coding tools and the number of generative AI projects on GitHub more than doubled in 2024. Companies like Cursor, n8n, Vercel, and Raycast now treat agent development as a core capability, not a side project.

When your engineering team is shipping agents in hours, the support platform that takes quarters to add new capabilities becomes the constraint. The constraint moves from how smart your AI is to whether your platform can keep up.

Why do AI agents need infrastructure, not applications?

Building an agent is now the easy part. The hard part is deciding where that agent runs and what it can safely do.

Agents need to:

• Observe real system state — read conversations, customer context, account tier, ticket history

• Take actions like a human user would — respond, escalate, change status, create linked issues

• Coordinate with other agents — pass context between specialized agents handling different parts of a workflow

• Interact with humans seamlessly — hand off to a support engineer mid-conversation without losing thread state

This shifts the constraint away from models and toward infrastructure. The question isn't "how smart is your AI?" it's "can your AI actually do anything?"

The Klarna lesson: vendor AI is not architectural AI

In February 2024, Klarna's then-new OpenAI-powered customer service assistant handled two-thirds of customer chats — the equivalent work of 700 full-time agents, according to the company's own press release. Fifteen months later in May 2025, CEO Sebastian Siemiatkowski reversed course, telling Fortune the all-in AI strategy had delivered "lower quality" service: "As cost unfortunately seems to have been a too predominant evaluation factor when organizing this, what you end up having is lower quality." Klarna is now hiring human customer service agents again under an "Uber-type" flexible-staffing model. The same Fortune article cited IBM research showing only 1 in 4 AI projects deliver promised ROI, and just 16% scale enterprise-wide.

The architectural failure mode Klarna hit is the one every vendor-locked AI customer is exposed to: when quality drops, you can't tune the model — the model isn't yours. You can adjust prompts within the vendor's allowance, file feature requests, or wait for the next release. The Klarna failure wasn't AI failing. It was a platform architecture failing — the choice to run everything through vendor-defined inference with no surface to compose, tune, or rebuild.

This is exactly the failure mode API-first infrastructure prevents. When n8n's AI resolution quality plateaued early in their deployment, their engineering team rewrote the prompts, swapped models, and shipped the change in days — because the agent runs in n8n's own infrastructure (n8n the workflow product) and connects to Plain's queue via webhooks and Machine Users. n8n now handles 60% of tickets with AI, with a goal of 80% by end of 2026. That's the architectural difference made concrete.

Why does customer support shift to infrastructure first?

Customer support undergoes this transformation early because the economics are immediate:

• High interaction volume creates automation leverage

• Clear cost pressure makes ROI obvious

• Repetitive patterns suit agent handling

• Per-customer revenue exposure makes quality breaks economically expensive

Salesforce's 2024 State of Service Report reveals that 91% of organizations now track service-driven revenue, up from 51% in 2018. The direct revenue tie of getting support right has hardened in the last five years — which is exactly why getting AI architecturally wrong (Klarna's path) is now financially catastrophic, not just operationally inconvenient.

As agents handle more conversations on the right architecture, support costs fall while quality improves. **Tinybird reduced first response time from 1 hour to 12 minutes** after moving to Plain's API-first architecture. **Sourcegraph cut first response time by 67%** after replacing 3 tools with Plain. **Buildkite runs follow-the-sun Slack support with sub-5-minute SLA response times** across APAC, Europe, and the Americas — on routing + AI, not headcount. **Resend took automated resolution rate from 10% to 33% in four months** with a three-stage AI pipeline built on Plain's webhooks and Customer Cards.

Support becomes an early signal of how all customer-facing functions will evolve. The architectural choices made in support tooling in 2026 will be made in product onboarding, customer success, and revenue operations in 2027.

How does the human role change when agents handle volume?

Humans remain essential, but their work concentrates in high-impact situations:

• Revenue-sensitive conversations where judgment matters

• Complex technical issues requiring deep context

• Relationship moments that build customer loyalty

• Designing the system itself — prompts, routing, escalation rules, graduated-trust rollouts

The shift is from responding to tickets to designing how systems behave. Humans operate alongside agents, not behind them as a fallback. At n8n, the support engineering team now spends most of their time tuning the AI agent that handles 60% of tickets, rather than working a queue. The job changed shape: less queue triage, more agent-tuning.

What is a support engineer?

A new role emerges from this shift. One that looks more like engineering than traditional support.

Support engineers:

• Build and operate agent-driven systems

• Define workflows and coordination logic

• Maintain quality across automated interactions

• Tune AI prompts, routing rules, and escalation thresholds

• Measure system performance, not tickets closed

In analysis of those 1,350 conversations, roughly 1 in 3 evaluations were led by an engineer, technical founder, or CTO rather than a support leader. The buyer for B2B support tools has shifted, and so has the work the buyer does. For the full discipline definition, see what support engineering is and why B2B SaaS teams need it.

2026 is the year the support engineer becomes a recognized role rather than an emerging one — and the platforms that win this cycle will be the ones that treat support engineers as the primary buyer rather than the buyer's IT counterpart.

Why does MCP change the architectural picture?

The most underrated architectural shift of 2026 is Model Context Protocol (MCP) — the open standard that lets AI assistants like Claude or Cursor directly query and act inside a support platform without requiring custom integration code. Plain ships a native MCP server with 30+ tools: thread create, customer find, tenant lookup, help-center search, status update, and more. Zendesk added MCP support in early 2026 per TechRadar reporting. Intercom shipped one of the earliest MCP servers in the category.

The practical change MCP introduces is bidirectional: not only can your team's AI assistants act on your support data, but your customers' AI assistants can too. A customer's developer working in Cursor can ask "what's the status of my last support ticket?" and Cursor — addressing your Plain MCP server with the customer's auth — returns the answer without leaving the IDE. The support tool becomes addressable infrastructure rather than a destination web app.

In an agent-driven world, the platform that is not MCP-addressable becomes invisible to the assistants buyers and customers are already using. That's a competitive position no support vendor wants to be in by 2027.

Why do businesses need multiple specialized agents?

As teams build more agents, specialization increases. It becomes normal to deploy different agents for:

• Onboarding workflows

• Technical support triage

• Customer success check-ins

• Industry-specific interactions

• Compliance-sensitive responses (regulated industries)

• After-hours escalation routing

Without shared infrastructure, this leads to fragmented experiences, minimal knowledge sharing, and duplicated logic. A shared operational surface — what we call Customer Infrastructure — allows agents to coordinate, share context, and interact consistently.

Plain provides this unified layer where Ari (our customer-facing AI agent), Sidekick (internal AI copilot), and custom-built BYOA agents all operate on a standardized, company-specific set of rules. Engineering teams compose new agents on top of Plain's GraphQL primitives; product teams ship customer-facing AI without re-platforming.

Why does value shift from resolution to insight?

As conversation volume scales through automation, the limiting factor becomes interpretation.

The value of support shifts toward understanding what customers are saying across thousands of conversations, not just the most recent tickets. That requires treating support interactions as a system of record, not a byproduct.

Infrastructure plays a central role in preserving that signal. Plain's Insights layer automatically surfaces themes, trends, and churn signals from every conversation across Slack, Teams, Discord, in-app chat, and email — all programmatically queryable through the same GraphQL API agents use. The same surface that AI agents act on is the surface support engineers query for trend analysis. One data model, many consumers.

This is the asymmetry API-first delivers that vendor-locked platforms can't: when your insight layer, your AI agents, your custom workflows, and your dashboards all read from the same programmable surface, every improvement compounds across all of them. With vendor-locked platforms, each consumer has its own integration path, its own caching layer, its own drift problem.

Why does traditional SaaS break in an agent-driven world?

Traditional SaaS assumes teams will adapt their processes to the product. Change follows a vendor-defined roadmap. Even well-designed platforms eventually impose constraints.

When your team builds and rebuilds systems faster than your vendor ships features, those constraints become unacceptable.

The breaking points:

Craft Docs, a 30-person startup, recently announced they're leaving Zendesk after 5 years. The reason? They built their own AI agents that outperformed Zendesk's $20K/year AI add-on — and Zendesk's API couldn't keep up with how they wanted to work. The Craft Docs migration is one public version of the pattern that, per our 1,350-conversation dataset, roughly 14% of B2B SaaS support evaluations are now actively leaving Zendesk for. The cohort number compounds the anecdote: this is no longer the edge case, it's the median engineering-led evaluation.

For the full picture of how teams migrate, see how 3 B2B SaaS teams migrated from Zendesk — Sourcegraph cut FRT by 67%, Sanity gained 120% in team satisfaction, Prisma became the first user of Plain's Zendesk importer.

What makes Plain different from traditional support tools?

Plain is built as infrastructure, not application. Everything visible in the product is available through the API. Teams compose their own workflows, agents, and tools without waiting for product features.

Core architecture:

• API-first — public GraphQL API with no rate limits and full UI-to-API parity

• BYOA-ready — Machine Users + webhooks let engineering teams connect Claude, GPT, Gemini, or fine-tuned custom models as first-class queue participants

• Native MCP server — 30+ tools make Plain addressable directly by Claude, Cursor, ChatGPT, and any MCP-compatible AI assistant

• Unified multi-channel — Slack, Microsoft Teams, Discord, email, in-app forms, Help Center — all native first-class channels, not bolt-on integrations

• AI-native — Ari handles routine queries with no per-resolution fee; Sidekick keeps humans in the loop on the complex tail; BYOA opens the architecture

• Extensible — webhooks, custom data models, programmable workflows

Companies like Vercel, Cursor, n8n, Raycast, Stytch, Sanity, Buildkite, Tinybird, Fly.io, Resend, and Granola use Plain because they need infrastructure they can build on, not software they're stuck inside.

For the deeper comparison, see the best API-first support platforms for B2B teams, the 2026 guide to AI-powered support for B2B SaaS, and the practical MCP for customer support guide.

The thesis

Extensible, API-first infrastructure becomes the foundation for customer-facing systems. The goal isn't to predict exactly how support or AI agents will evolve. It's to build infrastructure that doesn't get in the way as they do.

The teams winning the next 12 months are the ones who chose architectural commitment over feature checklist — BYOA over vendor-locked AI, MCP-addressable over UI-destination, programmable workflows over admin-UI configuration, and a single composable surface over a stack of integrations. The Klarna reversal is the most public version of the wrong-architecture cost. The n8n / Sourcegraph / Buildkite / Resend outcomes are the most public version of the right one.

Plain exists to provide that shared operating system for humans and AI agents. The customer support category is the early signal. Customer Infrastructure is the architectural commitment that follows.

Frequently Asked Questions

What is Customer Infrastructure?

Customer Infrastructure is the foundational layer that enables all customer-facing interactions — support, success, and engagement — to operate through a unified, programmable system. Unlike traditional support tools that silo conversations, Customer Infrastructure treats every interaction as data that informs product, revenue, and relationship decisions. Plain is the AI-native Customer Infrastructure Platform built API-first for B2B SaaS in the agent-driven world.

What is an API-first support platform?

An API-first support platform exposes its full capabilities programmatically, allowing teams to build custom workflows, integrate AI agents, and extend functionality without waiting for vendor features. Plain's GraphQL API provides complete feature parity with the UI — anything a human can do, an agent can do. The architectural commitment matters because AI agents need infrastructure they can compose with, not applications they have to work around. See the deep API-first support platforms comparison for the dimension-by-dimension breakdown.

Why are B2B teams moving away from Zendesk for AI-driven support?

B2B teams increasingly need programmable infrastructure rather than configurable software. In Plain's analysis of 1,350 conversations with B2B support leaders and engineers between January 2025 and April 2026, roughly 14% of evaluations were active Zendesk migrations — the single most common migration in the cohort. Zendesk's UI-first architecture limits how teams can deploy AI agents and custom workflows. Companies cite slow API performance, vendor-locked AI add-ons, and the inability to compose workflows as engineering teams build them as the reasons for switching. Klarna's May 2025 reversal — abandoning its all-in-on-vendor-AI strategy because quality dropped and the company couldn't tune the model — is the most public version of the architectural failure. See how 3 B2B SaaS teams migrated from Zendesk for the detailed migration patterns.

How do AI agents work with customer support platforms?

AI agents need platforms that let them observe state, take actions, and coordinate with humans seamlessly. API-first platforms like Plain treat agents as first-class citizens — they can read conversations, respond to customers, escalate issues, and update records through the same GraphQL interfaces humans use. Plain's BYOA architecture lets engineering teams connect Claude, GPT, Gemini, or a custom fine-tuned model as a queue participant via Machine Users + webhooks. Plain also ships a native MCP server with 30+ tools that any MCP-compatible AI assistant — Claude, Cursor, ChatGPT — can address directly.

What is the difference between support software and Customer Infrastructure?

Support software focuses on ticket management and resolution metrics. Customer Infrastructure focuses on enabling relationships — unifying channels, exposing data through APIs, and providing the foundation for both human and AI-driven interactions. Plain consolidates Slack, Microsoft Teams, Discord, email, and in-app support into one programmable workspace where Ari (customer-facing AI), Sidekick (internal AI copilot), and custom-built agents all operate on a standardized, company-specific set of rules.

What is BYOA and why does it matter for AI customer support?

BYOA (Bring Your Own Agent) means engineering teams connect their own AI model — Claude, GPT, Gemini, or a custom fine-tuned model — as a first-class participant in the support queue, rather than being locked into the vendor's inference layer. Plain implements BYOA via Machine Users + webhooks. The architectural significance is durability: when AI quality drops, you can tune the model because the model is yours. When Klarna's vendor-locked OpenAI deployment underperformed in May 2025, they couldn't tune it; BYOA would have let them swap models or rebuild prompts without changing platforms. n8n handles 60% of tickets via Plain's BYOA architecture today, with a goal of 80% by end of 2026.

Plain, the AI-native Customer Infrastructure Platform for B2B SaaS, is the support stack for teams building on infrastructure rather than configuring around applications. Book a demo or start a free trial.