Introducing Bring Your Own Agent

We think support teams should choose their own AI agent. Not have one chosen for them by their platform.

Today, we're making that real: Bring Your Own Agent lets you connect any AI agent to Plain's infrastructure, alongside or instead of ours.

What is BYOA (Bring Your Own Agent)?

BYOA stands for Bring Your Own Agent. In customer support, it means running an AI agent you chose or built yourself on a support platform you did not buy it from — the platform handles channels, routing, escalation and SLAs, while your agent handles the conversations.

The acronym is overloaded, so it is worth separating the three things people mean by it:

• Bring Your Own Agent — the customer-support sense used here: a third-party or in-house AI agent that works inside your support platform as a first-class participant, with the same access to threads, customer context and handoff rules as a native agent.

• Bring Your Own AI — used loosely and interchangeably with the above. Sometimes it means something narrower: supplying your own model or API key to a vendor’s agent, without control of the agent itself.

• Bring Your Own App (or Application) — an older, unrelated term from device and SaaS management, describing employees using unapproved software at work. It shares the acronym and nothing else.

A useful test for the customer-support sense: if switching AI agents means rebuilding your routing, queues and escalation paths, you do not have BYOA. You have an integration.

What BYOA requires of a support platform

Connecting an outside agent to a support platform takes four things, and most platforms are missing at least one:

An identity for the agent. The agent needs to exist in the system as an actor that can be assigned work and audited — in Plain that is a machine user — rather than acting through a borrowed human account.

Event access. The agent has to know when something happens. That means webhooks for thread created, new message and status change, not a polling workaround.

Write access to the thread. Reading is easy; the agent also has to reply, change status and hand off through the same API the platform uses itself.

Retained infrastructure. Routing, queue logic, SLAs and the AI-to-human handoff stay with the platform. If they live inside the agent, swapping agents means rebuilding them — which is the lock-in BYOA exists to remove.

This is why BYOA tends to appear on platforms built API-first. The capability is an architectural consequence, not a feature that can be added later; the same is true of how support platforms expose their data to AI tools through MCP.

The principle

Look at how most support platforms work today. They build a proprietary AI agent, couple it tightly to their infrastructure, and optimize everything around keeping you inside their ecosystem.

The switching costs aren't a bug. They're the business model.

We think that's the wrong approach. Not because those agents are bad, but because it puts the platform's interests ahead of the customer's.

If your AI agent decision is dictated by your platform choice, that's not a real decision. And if switching agents means rebuilding your entire support operation, you're not going to switch, even when you should.

We'd rather build infrastructure that's good enough that teams stay because they want to, not because leaving is too painful.

That's the bet behind Bring Your Own Agent.

What we built

Bring Your Own Agent lets you connect any AI agent to Plain. Parahelp, Sierra, Decagon, Fin, Decimal. Whatever agent you've built or bought, it works with Plain.

Your agent handles the conversations. Plain handles everything around it: thread routing, queue management, escalation paths, SLAs, and the handoff between AI and your team.

Here's how it works:

You create a machine user in Plain to represent your agent. Your agent subscribes to webhooks (thread created, new messages, status changes) and responds to threads via our API. As your agent works, it updates thread status, and Plain's infrastructure takes care of the rest.

Your agent's activity appears under Plain AI → Activity, where you get a clear view of every thread your agent has touched, basic performance stats, and a breakdown by agent status. Meanwhile, your human-centric queues (My Threads, Needs First Response, Needs Next Response) stay focused on the work that actually needs a person. AI-handled threads are filtered out automatically so your team isn't wading through noise.

The full setup guide is in our help center.

In practice

Teams are already connecting their own agents to Plain.

Mintlify tried a lot of support tools before landing on Plain. None gave them enough flexibility to run a third-party AI agent the way they wanted.

"Plain is the only reason we can run a third-party AI support agent at all. We tried a lot of other support tools, and none came close to this level of flexibility. Machine users unlock everything — from external agents to custom prioritization and workflows."

— Dean Sliney, Founding Support Engineer at Mintlify

Tines had a different problem. They'd already built an AI agent that worked — Intercom's Fin, tuned over months to match their tone and handle their customers' questions. They didn't want to replace it. They wanted to run it everywhere. So they used Plain as the infrastructure layer, Tines as the orchestration layer, and kept Fin as the brain.

"Bringing Fin into Plain meant we could roll it out across Slack, MS Teams, and any future channel without starting over. And once I got deeper into the handover process from AI agents to humans, it became so smooth and easy it was a no-brainer."

— Lasse Høgsholt, Senior Technical Support Engineer at Tines

Neither team had to compromise on their AI agent to get the infrastructure they needed. And if they decide to switch agents next quarter, they can.

For more information on where BYOA fits in your stack, check out The Agentic Support Stack: How to Build AI-First Customer Support in 2026.

Why it matters

The AI agent market is moving fast. New agents, new capabilities, new entrants. The landscape shifts quarterly. That's fine. That's healthy. It means the technology is getting better.

What's not fine is being stuck. Locked into one agent because your platform won't let you use another without starting over. That's not a technology problem. It's a trust problem. It means the platform is optimizing for retention, not for your success.

We wanted to build the opposite of that.

Bring Your Own Agent means your channels, your queues, your workflows, your escalation paths all stay the same no matter which agent you're running. The agent is a layer you can change. The infrastructure persists.

You evaluate agents on merit. You switch when something better comes along. You build a stack that fits your team's needs, not your vendor's.

Why teams ask for it

In conversations with B2B support leaders and engineers, the shape of the question has changed — and the change is measurable. Across more than 2,200 of those conversations, the share in which a team raised running a third-party or in-house AI agent went from roughly 2% in mid-2025 to about 15% by mid-2026, a sevenfold rise across four quarters, spanning 76 distinct companies in the second quarter of 2026 alone.

Teams increasingly arrive at a support platform evaluation having already chosen or built an AI agent — tuned to their tone, wired into their own systems. As one support leader at a B2B software company put it:

“We don’t use a helpdesk today. We built our own agent that answers these questions.”

For those teams the question is no longer whether to adopt AI. It is whether the platform will let the agent they already trust do the work — which turns the platform’s architecture into the selection criterion. In the words of an engineering lead at a developer-tools company:

“We chose it because it’s API-first. That’s how we connect our own agents.”

The objection that follows is consistent: an agent welded into the platform cannot be swapped, cannot be inspected, and cannot call the team’s own APIs. BYOA is the answer to that specific complaint.

When both sides have an agent

BYOA raises a question the category has not settled: if the platform has an AI agent and the customer has one too, who is allowed to do what? Support leaders raise it directly —

“I’m not sure I can fully trust what your agent is asking our agent to do.”

It is a reasonable worry, and the answer is not a feature so much as a boundary. The workable division is that one agent owns the customer conversation at any given moment, handoffs between them are explicit and logged, and any action with a side effect — issuing a refund, changing an account, closing a thread — stays attributable to a named actor a human can audit after the fact. If a platform cannot show you which agent did what on a thread, running two agents is a risk rather than a capability.

What about Plain's own AI?

It's still here, and we're still investing in it. Plain AI is purpose-built for our infrastructure. It understands thread context, routing logic, and escalation paths natively, which means it works out of the box with zero integration overhead.

But we made it optional, deliberately. Because the best AI agent for your team is the one that actually performs best for your team, and we'd rather you choose that than be stuck with ours by default.

Use Plain AI on its own. Run it alongside a third-party agent. Or bring your own and skip ours entirely. Your call, and we mean that. 😊

BYOA FAQ

Does BYOA mean “bring your own agent” or “bring your own AI”?

In customer support they are used interchangeably, and Bring Your Own Agent is the more precise term. “Bring your own AI” sometimes refers to something narrower — supplying your own model or API key to a vendor’s agent, without the ability to replace the agent itself. Bring Your Own App is an unrelated term from IT and device management.

Is BYOA the same as an integration or an app marketplace listing?

No. A marketplace integration usually lets an agent send messages in. BYOA lets an external agent operate as a first-class participant — assigned threads, full customer context, its own identity, and a real handoff to humans — while the platform keeps routing, SLAs and escalation.

Can you run your own agent alongside the platform’s native AI?

Yes. The two are not exclusive: a native agent can cover common questions while a specialist or in-house agent takes the cases it was built for, with humans as the escalation path for both.

Who is accountable when the platform’s agent and your agent both act on a thread?

Whichever one took the action — which is why an external agent needs its own identity in the system rather than a shared or borrowed account. Handoffs between agents should be explicit and visible on the thread, and any action with a side effect should be attributable to a named actor.

What happens to reporting when an outside agent handles a thread?

That depends on the platform, and it is worth checking before committing. The agent’s activity should be visible and attributable, and AI-handled threads should be filtered out of human queues so the team is not triaging work that is already done.

Get started

Check out the full setup guide to connect your agent to Plain. If you have questions, we're around. Reach out to our team anytime.