Use caseAI agentKnowledge and search
A second-line support agent that checks the logs before an engineer gets pulled in
An AI agent for B2B SaaS support that reads account settings, error logs and past bugs, then hands back a verified answer or a bug report ready for triage.
A blueprint, not a client story. The business described is illustrative; the architecture, integrations and trade-offs are real, and this is how I would build it. By Ergini, .
The short version
A second-line support agent for B2B SaaS companies. For tickets the help center cannot answer, it reads the account's configuration through a read-only service account, pulls that account's errors for the right time window from Sentry and Datadog, and searches Jira or Linear for known issues. It returns a verified answer for support to send, or a bug report with reproduction steps and redacted log excerpts. Engineers set severity; security and data-loss tickets go straight to a person.
- Best for
- B2B SaaS teams where a small support crew escalates to an engineering rota, and the rota spends its time investigating rather than fixing.
- Connects to
- Zendesk or Intercom, Jira or Linear, Sentry and Datadog, Admin API or read replica, Slack, Notion or Confluence
- The AI does
- Turns a ticket into an investigation plan, reads errors and logs against the customer's description, and writes the answer or the bug report.
- People do
- Support sends every customer-facing reply, the engineer on rota sets severity and owns the fix, and security or data-loss reports go to a person at once.
- Built as
- AI Agent Development, usually $12K - $30K
Why engineers end up doing support
Picture a 40-person B2B SaaS company with three people in support and about 600 tickets a week. The help center and the helpdesk's AI agent handle the how-to questions. What is left are tickets like 'the sync stopped overnight', 'the export file is empty' or 'nobody in our EU workspace can log in since this morning'.
Support cannot answer those from the docs. The answer is in the account's configuration, the error logs for a particular hour, and the memory of whoever fixed something similar in March. So the ticket goes to the engineering rota, where a senior engineer starts with lookups: which workspace, which plan, which integration, what failed and when, and whether a bug already exists.
Often it turns out to be a setting, a plan limit or a known issue with a workaround. When it is a real bug, the report gets written from scratch, sometimes duplicating one filed under another title. Meanwhile the ticket falls through the cracks between Zendesk, Jira and Slack, and the SLA clock keeps running.
First-line AI sees only the help center and the ticket, so it never reaches this layer. This agent does: it runs the investigation an engineer would, with the same read access and none of the write access, and hands back a verified answer or a bug report ready to triage. It is an AI agent in the strict sense, choosing which checks to run from a fixed set of tools.
What happens after a ticket is escalated
The model plans the investigation and interprets the results. Access, redaction, routing and anything touching a customer record are ordinary code with fixed permissions.
01 Trigger · Zendesk trigger or Intercom webhook
Support escalates a ticket
Support marks it 'needs investigation', or the first-line AI agent hands it over. A helpdesk trigger sends the ticket ID; nothing starts from customer text alone.
02 Plain code
Screen for security and data loss
Before any model reads the ticket, rules look for another customer's data being visible, deleted records or a leaked key. A match pages the on-call engineer and the security lead, and the agent stops.
03 AI model · Structured output
Plan the investigation
The model writes a structured plan: workspace, feature, and the time window the customer means, converted from 'since this morning' in their timezone to UTC. It rechecks for security language and can only pick from narrow, read-only tools built on these tool-calling practices.
04 System · Admin API, Sentry API, Datadog Logs API
Pull configuration, errors and logs
Plan, flags and integration settings from the admin API or a read replica, errors for that workspace and window from Sentry, and log lines from Datadog filtered on the workspace tag. Every query is capped.
05 Plain code
Redact before the model reads anything
Emails, names, IP addresses, tokens and payloads become placeholders that stay consistent within one investigation, so the model can still tell that two log lines concern the same user.
06 AI model
Compare the evidence with known issues
A semantic search over Jira or Linear issues, runbooks and release notes, following the agentic RAG pattern, then a written finding with the evidence for each claim.
07 Decision
Route the finding
Code routes the structured finding by evidence thresholds. A 'new bug' needs an error tied to this workspace inside the window.
- Settings or plan explain it, and the docs agree then a draft answer for support, citing the setting and the doc
- The error matches an existing issue then ticket linked, account added to the issue, status reply drafted
- A new error tied to this workspace, with no matching issue then a bug report drafted into the triage state and posted to the rota in Slack
- Nothing conclusive, or a tool timed out then a note listing what was checked and what was not, back to support
08 Person
Support and the rota decide
Support edits and sends any customer answer. The engineer on rota sets severity and files the draft or returns it with a reason, which becomes a test case.
09 Result
The investigation stays on the ticket
Plan, queries, redacted evidence and finding are attached as an internal note and logged. Internal notes do not stop Zendesk's first-reply SLA, so the ticket stays in the team's breach views.
Access, system by system
Most of the safety here lives in credentials, not in the prompt. A model told 'change nothing' can be talked into trying; a database role that can only read four views cannot.
| System | What the agent can do | Why that and no more |
|---|---|---|
| Zendesk or Intercom | Read tickets; write internal notes, tags and issue links | Support sends every message a customer sees. |
| Admin API or read replica | Read four configuration views through a dedicated role, one workspace per query | Billing, user content and credentials sit outside those views. |
| Sentry | Read issues and events with a read-scoped token | No power to resolve, mute or delete an issue. |
| Datadog | Search logs by workspace tag within a capped time window | Wide queries are slow and full of other customers' data. |
| Jira or Linear | Search; create issues only in the triage state | Assigning, prioritizing and closing stay with engineers. |
| Anything that changes customer data | Nothing | Refunds, plan changes, flag toggles and job reruns are done by a person. |
An escalation, followed from ticket to bug report
A failing export. The agent rules out the customer's own setup, finds a new error behind it, and drafts the report the engineer would otherwise write.
Zendesk ticket #58112, Thursday 10:42
Customer · Email
Our nightly export to SFTP has failed two nights in a row. Nothing changed on our side and we need the files for month-end. Workspace ws-20931.
- Escalated to second line by support.
- get_account(workspace: "ws-20931")Business plan / eu-central / nightly SFTP export 02:00 CET / SFTP settings unchanged since 14 Jul / flag new_export_pipeline on since 9 Sep
- search_errors(workspace: "ws-20931", from: "2026-09-09T22:00Z", to: "2026-09-11T08:30Z")Sentry EXPORT-4127 ExportStreamTimeout / first seen 10 Sep 00:03 UTC / 7 workspaces affected, all with the flag on
- search_logs(service: "export-worker", workspace: "ws-20931", window: "same")stream closed after 300s at 41,200 of 88,650 rows, both nights / 6 emails and 2 file paths redacted
- find_known_issues(fingerprint: "EXPORT-4127", text: "export timeout large accounts")nothing linked to this fingerprint / nearest: LIN-3312 'CSV export slow', closed 2 Aug, different stack trace / not a duplicate
- search_docs(query: "SFTP export limits")no row limit on Business plan / release note 9 Sep: new export pipeline rolling out
- Finding: new bug. Customer configuration ruled out. Draft posted to #eng-escalations.
Agent · Linear, triage
Nightly SFTP export times out for large workspaces on the new export pipeline Environment: production, eu-central, export-worker, flag new_export_pipeline on Suspected trigger: exports above roughly 40,000 rows; the stream closes at 300s Reproduce: enable the flag on a workspace with 50,000+ invoice rows, run the scheduled export Evidence: Sentry EXPORT-4127; redacted log excerpt attached Affected: 7 workspaces, all flagged since 9 Sep (list attached) Ruled out: SFTP settings unchanged; last good export 8 Sep, before the flag Severity: left for the rota
Agent · Zendesk internal note
Draft for support: 'Thanks for flagging this. We have confirmed a problem on our side with nightly exports for larger workspaces since 9 September, and your settings are fine. Our engineers have the details and we will update you here. If you need last night's file sooner, reply and we will send it manually.'
- The rota engineer set severity to high and moved the affected workspaces back to the old pipeline. Support sent the reply.
How a log-reading agent misleads, and the guard for each
Most of these are data and permission problems that a model makes more visible, not problems a better prompt solves.
Logs full of customer data
Logs carry emails, names, IP addresses and whole request bodies. Redaction runs in code on every result before the model sees it, the originals stay in the log store, and model calls go to a provider under a data processing agreement, in the EU if your contracts require it. More on that in GDPR-compliant AI development.
The same bug, filed five times
Titles differ; stack traces do not. The Sentry fingerprint is checked against linked issues first, then a semantic search runs over open and recently closed ones. A match is linked, not refiled, and a new draft lists the near-duplicates it rejected.
A 'bug' that is really a setting
A plan limit, a disabled flag or an expired token on the customer's side all look like bugs. Configuration is checked first, and without an error tied to the workspace the ticket goes back to support with the checks listed, never to the rota as a defect.
Docs that describe last year's product
Pages carry their last-updated date and release notes outrank older pages. When a doc contradicts the configuration, the agent says so and opens a docs task rather than quoting it, which is the same problem an internal knowledge assistant has to solve.
An error in the window that has nothing to do with it
Busy systems always have errors. One counts as evidence only if it carries this workspace's tag, touches the feature described, and runs above its usual rate elsewhere. Anything else is listed as seen and probably unrelated, never as the cause.
Who decides what on an escalation
The AI model
Turn the ticket into an investigation plan
Mapping a symptom, in the customer's words and timezone, to a workspace, a feature and a window is language work.
Read errors and logs against the report
It takes judgement, so the evidence is attached for an engineer to check.
Write the answer draft or the bug report
Every claim points at a log line, a setting or a doc.
Plain code
Security screen, credentials and redaction
Enforced before and around the model, where no instruction can widen them.
Routing the finding
Evidence thresholds are rules the team can read and change.
A person
Everything a customer reads
Second-line replies confirm bugs or imply timelines, and both are commitments.
Severity, the fix and any action on customer data
Engineers weigh contracts and the roadmap; reruns, restores and credits need a person with the evidence in hand.
Earning a place on the rota
The agent proves itself on tickets whose answer is already known before it works on live ones.
- Replay: run it over three months of past escalations and compare each finding with what the engineer concluded.
- Shadow: on live escalations it writes its note while the rota works as usual, and the engineer marks each note useful, partly useful or wrong.
- Notes first: once notes are reliably useful, support reads them before escalating, and some tickets never reach the rota.
- Bug drafts: issues go into the triage state; engineers file or reject them, and each rejection with a reason joins the test set.
- Automatic linking, only on an exact Sentry fingerprint match, because that match is deterministic and a wrong link takes one click to undo.
Every investigation is traced, so a wrong finding can be replayed and explained; the tooling is compared in the LLM observability write-up. Customer-facing replies stay with support at every stage, by design.
Is your helpdesk's AI agent enough for second-line tickets?
For first-line questions, buy. Intercom's Fin is $0.99 per outcome, Zendesk's AI agents are billed per automated resolution, and Decagon serves larger support organizations; all of them answer well from a help center. Check the billing definitions: Zendesk counts requests resolved without escalation to a human, while Intercom's outcome also includes a completed procedure that ends in a handoff. If your escalations are mostly how-to questions that slipped through, fix the help center first.
Second line is different because the answer sits where no helpdesk agent can see: your admin API, logs, error tracker and issue history. An investigation needs several scoped queries per ticket, redaction, reasoning over stack traces and a hand-off into your engineers' tracker. Sentry's Seer is worth having on the engineering side, as it analyzes root causes and drafts fixes from errors, but it does not know which customer wrote in, how their workspace is set up, or what support already told them.
The usual answer is both: Fin or Zendesk's agent on the front line, this agent behind the escalation step, in the same ticket and the same tracker. If your engineers have time, it is a reasonable in-house build too. What an outside engineer adds is doing the permission, redaction and evaluation work first, so the rota never becomes the test environment.
How you would know it is working
A blueprint has no results to report, so here is what I would measure from the first week instead, on your own data.
- Useful-note rate
- The share of investigations the engineer on rota marks useful or partly useful, per product area, from the first shadow week.
- Escalations closed without an engineer
- Tickets where support sent the agent's verified answer and the customer did not reopen within fourteen days.
- Duplicate rate in the tracker
- New issues later marked as duplicates, before and after the agent starts drafting. It should fall, not rise.
- Overturned findings
- Findings the engineer rejected, with the reason: the number that decides whether bug drafting stays switched on.
What a build like this costs
This is built as AI Agent Development, which runs $12K - $60K overall. A build like this one usually lands in the single-purpose agent tier: $12K - $30K, 2-5 weeks. The first working version runs on your real data well before the end of that window.
What it costs to run
Each investigation is a handful of API calls and two or three model calls over redacted evidence, usually a few cents to a few tens of cents per escalated ticket depending on how much log text is read. That is why queries are capped and long stack traces are trimmed first.
What moves the price
- How many sources an investigation needs: Sentry alone, or Sentry plus Datadog, a read replica and a billing system
- Whether a read-only path to account configuration exists, or has to be built as views, a scoped role or an internal endpoint
- How much personal data your logs carry, which sets the redaction work
- The state of the issue history: thousands of loosely titled Jira issues take more deduplication work than a tidy Linear team
Who this is for
- B2B SaaS companies with a small support team and engineers on an escalation rota
- Products where many reported bugs turn out to be configuration, plan limits or the customer's own integrations
- Teams already running Fin or Zendesk's AI agent who want the next layer handled
- Companies with EU customers whose logs hold personal data that cannot reach a model unredacted
Questions people ask about this
Can an AI agent triage Zendesk tickets that need log access?
Yes, if it gets log access the way a careful engineer would: read-only, scoped to one workspace and time window, with personal data redacted before the model reads anything. It reads Sentry and Datadog through tokens that cannot write, and posts its findings as an internal note on the Zendesk ticket for support to review.
How do I stop an AI agent from filing duplicate Jira tickets?
Check deterministic signals before meaning. The agent compares the Sentry fingerprint with issues already linked in Jira or Linear, then searches open and recently closed issues semantically, and drafts a new one only when neither matches. Drafts land in a triage state with the near-duplicates listed, and an engineer decides.
Is it safe to give an AI agent access to production logs?
It can be, with three controls in code: credentials that can only read, a redaction pass on every result before the model sees it, and a model provider under a data processing agreement that excludes training on your data. Under GDPR the real exposure is the personal data inside logs, which is why redaction is never left to the prompt.
Can AI handle real support tickets without human approval?
At first line, for narrow and well-documented questions, often yes. At second line, not in this design: the agent writes internal notes and drafts, and a support person sends every message a customer sees, because these replies confirm bugs or imply timelines. If you ever let it reply alone, EU customers must be told they are dealing with an AI under Article 50 of the AI Act.
How much work is it to build a second-line support agent?
It usually sits in the lower tier of my AI agent development pricing when the admin API and logs are reachable and one product area goes first. It grows with the number of data sources, the redaction your logs need and the state of your issue history. It works the same with Intercom and Linear as with Zendesk and Jira; only credentials and formatting change.
Sources