How to Cut Support Escalations to Engineering with Coding Agents

A customer writes in at 9am. Their webhooks stopped firing sometime last Tuesday, and their dashboard shows everything as sent.

You know how to answer this. Pull the delivery attempts, match them against the event IDs, check whether the retries ran out. Ten minutes of work. Except you can't run that query, so you write it up, tag it P2, and it sits in an engineering queue behind a release. The customer hears back Thursday, and the answer is one line long.

That ticket wasn't hard. It was locked. You knew exactly what to check and weren't allowed to check it.

What it does. A ticket arrives. The agent pulls that customer's recent requests, errors, and records, checks them against your docs and your code, then posts a draft answer with the evidence. You read it, edit it, send it.

What it is not. It doesn't reply to customers and it doesn't touch production. It closes the gap between "I know what to check" and "I'm allowed to check it."

Build it with Claude Code or Codex. Runtime is where it lives, holds its credentials, and runs unattended.

The tickets worth automating

They share one thing: the answer already exists in your systems. Nobody needs to write code. Somebody needs read access and twenty minutes. At most API-first companies that's the bulk of what gets escalated, and if you're a solutions engineer, implementation manager, FDE, or support engineer, it's most of your week.

Leave the rest alone: code changes, roadmap answers, anything needing a human's name on it.

The stack

Your agent is a new kind of user for the tools you already run. If it has an API, a CLI, or a database connection, the agent can use it.

That last row is what makes the rest safe. Runtime is an operating system for coding agents: a sandboxed computer per agent, a credential vault, network rules, skills that persist between sessions, and scheduling.

Step 1: Decide what it can touch (human)

Do this first. It's the part your security team will actually read, and the reason they'll say yes.

Give the agent a read-only database account. That's much safer than telling it in a prompt to be careful, because a read-only account can't write even if the agent gets something wrong.

Then decide what it sees of each customer. Debugging needs IDs, timestamps, status codes, and amounts. It rarely needs names, card numbers, or email addresses, so strip those out in the query itself.

Two notes if you're in a regulated industry like fintech or healthcare. Anything you connect to regulated data pulls itself into your audit scope, so point the agent at a masked copy instead. And your auditors will ask who accessed what, so give the agent its own login rather than sharing someone else's.

Settle this before you build anything.

Step 2: Create the template

A template is what your agent boots into every time: the repos it can read, the tools it can call, the credentials it holds, and the hosts it's allowed to reach.

This is the whole build. You're not writing an application. You're giving one agent the same reach a senior engineer has when they debug a ticket, minus the ability to break anything.

Connect three kinds of things:

The middle row is the one that changes the job. Your ticket queue and your log provider both have APIs, so the agent can search them directly instead of waiting on a human to click through a dashboard. Anything your team opens in a browser becomes something the agent can query on its own.

"Create a Runtime template from our API repo. Connect Zendesk, Datadog, and Sentry. Add a read-only connection to the analytics replica. Network access only to those hosts. Load every credential from secrets."

Add credentials under the template's secrets, never by pasting them into a chat. Then check the limits actually work. Ask the agent to write to the replica and confirm it gets rejected. Five minutes of testing tells you more than a policy document.

Step 3: Turn every escalation into a skill

Skills are markdown files of durable knowledge attached to the template, the same idea as skills in Claude Code. Every session loads them, so the agent stops rediscovering what your team knows.

This is where the agent gets good, and it's the step teams skip. Every escalation produces a reusable answer that currently dies in a Slack thread.

"We just resolved this escalation. Write a skill capturing it: the symptom the customer reported, what it actually was, which query found it, and how to tell it apart from the two things it looks like."

The topics that pay off fastest:

• Error codes whose real cause has nothing to do with their name
• Your retry, idempotency, and timeout behavior, in customer language
• Staging and production differences that trip up every integration

Runbooks describe the system as designed. Skills describe how it actually behaves, which is what support has always known and never had anywhere to put.

Step 4: Point it at the queue

"Every 15 minutes, check for new tickets tagged technical. For each: find the customer and any IDs in the message, pull their recent requests, errors, and records, check the behavior against our docs and the code, and reproduce it in staging if you can. Post a draft answer as an internal note with the evidence and your confidence. If you can't find the cause, or it needs a code change, say so and write the summary an engineer would need. Never reply to a customer."

Two habits make an operating prompt work harder:

• Say why, not just what. "Read from the replica, a heavy query on the primary slows down live traffic" beats "read from the replica."
• Name the failure you're preventing. "Don't conclude 'no errors found' without confirming the time range and account ID matched" exists because someone got burned.

Escalations don't disappear, they arrive finished. Request IDs, timeline, what was ruled out, the suspected code path. That's the difference between an interrupt and a ticket an engineer picks up cold.

What stays human

Known patterns get drafted for a quick send. Anything new stops and asks.

Lessons that cost the most

1. Empty results lie. The most common failure is a query returning nothing because the account ID was wrong, and the agent reporting "no errors found." Make it distinguish "found nothing" from "didn't search what you think it searched."

2. Give it the code, not just the docs. Docs describe intended behavior. Escalated tickets are where actual behavior differs.

3. Timestamps are where investigations die. Your logs, your database, and your customer are in three timezones, and "last Tuesday" is in a fourth. Normalize to UTC and make the agent state the window it searched.

Measuring it

• Escalation rate. Share of technical tickets reaching engineering. The number this exists to move.
• Time to first real response. Not the auto-reply, the first message with findings in it.
• Engineering interrupt time. Have engineers track it for two weeks first. Nobody knows it and everybody has an opinion.
• Draft acceptance rate. If it's low, you're missing skills, not a better model.

Measure the baseline first, or you'll have no way to prove any of it.

The point

The tickets that get escalated usually aren't hard. They're locked. Support knows what to check and isn't allowed to check it, so the ticket waits on ten minutes of someone else's attention.

Give your team safe read access, hand the slow part to an agent that never gets tired of reading logs, and keep the humans on the decisions.

Then go answer the ticket.

---