Book a demo

Open by Default

Why we built Plain to be programmable, and why that bet is paying off

Simon Rohrbach

Co-Founder & CEO

March 5 2026

Product

Channels

Customers

Resources

Pricing

Support

Sign in

Book a demo

We started Plain 5 years ago on a bet that customer support would eventually need to be something teams could build on, not just configure. We believed support was becoming infrastructure, not a help desk you configure through dropdown menus.

So we started building Plain API-first. In practice, this meant that anything (and I mean anything) our app could do, you could do programmatically. Most tools in the space treated the API as a feature, gradually enhanced but always behind the core platform.

Our first pitch deck said "Stripe for customer support". That framing sounded great on paper, but didn't make sense in practice. The idea was right, but extending a support system through code didn't create enough value to justify the cost.

But now, the cost side of the equation has changed, and it's changed quickly.

What changed

Every support tool out there is built on three assumptions:

01. AI is bundled into the platform, because that's where the economic value is.
02. An API is a feature prioritised or de-prioritised like any other, not a fundamental design principle.
03. You get new capabilities when the vendor ships them, on their roadmap, on their timeline.

But over the past 12 months, we've seen 3 distinct changes taking place:

01. Building your own AI agents is cheap and practical. It's no longer a niche activity.
02. We're moving towards multi-agent support, not single-agent. In the future, you will have many AI agents with different skill sets involved in your support, mirroring how human teams are already structured.
03. Software is easier to shape and easier to build. Customer expectations are shifting from static UIs to products that adapt to the use case.

If you can't build on your support tool, it will hold you back.

Not eventually, but now. The pace of change has already outrun what most support platforms were designed to handle.

The answer isn't another support tool. It's support infrastructure that's open by default.

What we mean by "open"

There's a lot of debate about the death of traditional SaaS: That you can now vibe-code your support tool in an afternoon. That if you're not an agent, you're already dead.

All of these assertions are misplaced.

You can vibe-code a lot, but you probably don't want to spend time vibe-coding conditional SLA logic.

Round-robin with capacity planning. Templated text snippets. Multi-language support. Detailed evals. Integrations with your own systems. I could go on.

And you definitely don't want to deploy any of that without guardrails over who can access customer data.

Instead, I think the world is finally moving towards open infrastructure for specific business functions.

I don't mean "open" like open source. Open as in:

01. Vibe-coding your own UI and tools on top of proper guardrails, audit logs, and domain logic for customer support.
02. Doing anything programmatically, not just through the UI. Every action, every workflow, every piece of data accessible through the API. Humans and AI agents operate through the same surface.
03. Orchestrating your AI agent work next to your human work, in the same UI.

Bring your own AI agent. Connect your own models. Build your own workflows. No vendor lock-in.

The best technical teams we work with already operate this way. They build and rebuild their own tools constantly. They expect their infrastructure to be programmable, because everything else in their stack is.

A great example of this is n8n. As Gualter Augusto, Head of Support, puts it:

"Our users are builders. They choose n8n because they don't want to be locked into someone else's decisions. They expect the same from us. Plain gives us exactly that."

Bring your AI Agent to Plain, like Gualter

Bring your AI to Plain, like Gualter

What this enables

When infrastructure is open in this way, a few things change.

People in support spend less time handling routine interactions and more time designing how systems behave.

A new role is emerging out of this shift. Support engineers build and operate the systems that talk to customers. Their output isn't tickets closed. It's systems that scale.

As teams build more agents, they need a shared surface for those agents to coordinate through. Without one, specialization leads to fragmented experiences. With one, context flows between agents and the customer doesn't notice the seams.

And as the number of interactions grows, the signal becomes the product.

Product sees what customers are struggling with. Engineering knows which releases created friction. This only works when the infrastructure treats conversations as a system of record, not as disposable tickets.

This is already happening.

At Granola, one of the fastest-growing AI companies in Europe, Vicky Firth, Customer Experience Lead, describes how the openness of Plain's tooling and APIs means they can make changes dynamically as they scale.

They build internal tooling both in and outside of Plain, pull data for insights, bring their own agents, and customize workflows in ways that keep pace with their growth.

build support your way, like Vicky

Looking ahead

I don't know exactly how support will work in three years.

But we've spent five years building infrastructure with a specific conviction: that the platforms which survive this transition will be the ones that were open enough to get out of the way.

Open to being built on. Open to whatever models, agents, and workflows a team needs next.

Open to changing as fast as the people using them.