Bitmovin: a support-side engineer built the agent that closes some support tickets

Primary account: Neil Ebrey, “Building a Multi-Agent AI Support System at Bitmovin,” May 8, 2026. The author is identified as a senior software engineer in Support and describes himself as not a traditional software engineer. This is first-person production experience, not an independent audit or before/after evaluation.

Sequence. Ebrey explored models and retrieval for months, agreed on a RAG tool with his manager, and first shipped a Zendesk triage-and-summary app for internal support use. A colleague suggested Cursor; Ebrey says he used it to generate a working reproduction of a customer-reported bug without a supplied sample app. He was not initially ready to let an untested model answer customers. With Google ADK, he built a customer-facing orchestrator: documentation lookup, technical diagnosis, external search, and a human-engineer handoff after triage; greeting/farewell agents and guardrails prevent escalation or ticket closure before required information is collected. The system is live; he says it resolves ‘many’ routine Zendesk cases without human involvement. He also describes a Claude Code–built debugger UI discovered to duplicate ADK’s own web client—an example of avoidable work when the builder does not inspect the existing tool.

What this moves. This is a direct, named example of a support-domain worker designing and shipping a software system that changes support work, with action boundaries, rather than merely receiving engineering output. It offers a real bounded-closure design that is more autonomous than Linear’s human CX follow-up; it neither disproves Taobao’s measured support failure modes nor establishes safe closure generally. Ebrey’s ‘input/output’ stance is provocative beside the human learning question: domain expertise and code fluency can diverge, but we cannot infer independent maintenance competence or inability from this account.

Absent evidence. No ticket IDs, case-level customer acknowledgement, total incoming Zendesk denominator, escalation and reopen rates, customer satisfaction or wrong-closure audit, development/review labor, team coaching, post-release fixes or independently assessed maintenance ability. A screenshot of a solved example is not a sampled outcome. Ask for stratified ticket cohort, resolution verification, first- and 30-day recontact, human engineer minutes and code ownership over time. Link bounded closure, role map, requester-confirmation hunt.