How we run customer support with an AI agent
Our own customer support runs on Machine. An AI agent sits on top of Plain, our support tool, and can also see our code and our Stripe account. A real support question usually needs product knowledge, engineering context and billing data all at once. A help-centre chatbot can recite the docs. It cannot open the code behind a bug, check that a subscription renewed, or take a carefully limited action on someone's account.
Below we explain how it fits together: what it connects to, how each conversation gets its own workspace, and where the limits sit.
The problem
Tickets multiply faster than headcount. The tickets that count are the ones no saved reply can handle: "Why did you bill me twice?", "Nothing happens when I click this button", "Can your API do X?" Each one takes someone who knows the product, reads code and can open the customer's account: usually a senior engineer.
A help-desk bot copes with the simple stuff and gives up on these. Hiring more people grows cost one-for-one with ticket volume. And handing a general-purpose AI assistant real keys to production is a tough sell in any security review.
What we built
We wired our Plain inbox to an agent on Machine. Each incoming thread gets a sealed-off session of its own, with narrow access to the places a support problem can lead: what the product knows, the code and Stripe. The agent digs in, fixes what it is allowed to fix, and hands sensitive steps to a person.
How it works
Let Plain start each run
Plain sends a signed webhook to the project. A new thread or a fresh customer reply sets it off, and each time a brand-new session is created: a fresh cloud computer (sandbox) just for that conversation. Nothing is shared between threads, and a busy day simply means more sessions working side by side.
Teach the agent the product
What the agent knows about the product sits in skills and memory, the playbook it loads at the start of every session. That includes how the product behaves, our support playbook, the voice we reply in, and fixes that solved similar problems before. Each time a thread is closed, the playbook can learn something new.
Plug in everything a ticket might need
Connectors are scoped connections to your tools, with the keys held on our servers so the model never sees them. Through them the agent can:
- Search the code: when a bug comes in, find the code behind it, look at what changed lately, and check whether it is a known issue.
- Check Stripe: the customer's plan, invoices and subscription status, so billing answers come from real account data.
- Read and reply in Plain: take in the whole thread, then send back an answer.
Draw the lines
Out of the box the agent mostly reads: it can look around freely, but its writes are tightly limited. Refunds, plan changes and anything else that touches a customer's money or account halt at a human approval gate. Credentials are stored encrypted in the Secrets Manager and only handed to the agents you grant them to, at the moment a run starts.
Let each thread play out
When a thread arrives, the agent sorts it, digs through all three systems, and then either solves it outright or passes it to a person with the legwork done and the context attached. "Why did you bill me twice?" turns into a Stripe check and a clear answer. "Nothing happens when I click this button" turns into a code search that either explains what is going on or files a bug for engineering.
Summary
Hook your support tool up as a trigger. Give the agent narrow connectors into every system a ticket could reach. Store what it knows about the product as skills and memory, and put a person in front of anything sensitive. From then on, every incoming thread gets a session of its own.
Guardrails
Letting an agent into your code, your Stripe account and your support inbox is as much a security decision as a product one. Here is what keeps it safe on Machine:
- Isolation. Every thread runs in a sandbox and on a branch of its own. Inside, the session can install tools, run code and try things out to reproduce a bug, and only what it is explicitly allowed to send ever leaves.
- Scoped secrets. The Plain, Stripe and GitHub credentials are stored encrypted in the Secrets Manager and only handed to the agents you grant them to, injected into the sandbox when the run starts.
- Human approval gates. Anything that cannot be undone, such as moving money or changing an account, needs a person to approve it.
- Everything is code. The agent's persona, skills and permissions are files in the repo. They keep a version history and change through a reviewed change request, not a setting in a dashboard.
The outcome
The detective-work tickets that once pulled a senior engineer off their work now go to the agent first, and when it passes one along, the diagnosis comes with it. Customers get a real answer at any hour.
Four building blocks make it work: a sandbox that keeps every session contained, a Secrets Manager that handles the keys, approval gates in front of anything that cannot be undone, and memory that gets smarter each time a thread is closed.
More use cases
How we answer GDPR data-subject requests before the deadline
Our Machine agent checks each GDPR access or deletion request, finds the person's data across our product database, builds the report well within the SLA and hands it to legal before anything is sent.
How we keep our docs matching what the code does
Once a day a Machine agent reads every commit merged since its last pass, finds the doc pages those changes made wrong, rewrites them and sends you one pull request to review.
How we test every pull request without lifting a finger
Our Machine QA agent works with GitHub and our test environment. For each pull request it checks out the branch, runs the tests, tries the change for real, and posts what it found.
Put your first agentto work today.
- SSO
- RBAC
- Governed agents
- Full audit trail