Fixer

Inspiration

Every AI support bot on the market does the same thing: it answers questions and stops there. Ask it to actually fix your account and it hands you off to a human, exactly the outcome it was supposed to prevent.

What software did we replace? Zendesk and Intercom, or more precisely the AI layer both ship as their flagship support feature, the one that answers and stops there.

Why did we choose it? The Xano challenge asked for a SaaS tool rebuilt with AI doing the work a human used to do, and support has clean boundaries to build against: an order is eligible for a refund or it isn't, a service is suspended or it isn't. Real state, real rules, a gap between answering and acting a demo can actually show.

What it does

Fixer is a support agent with real write access. It checks an order's status, issues a refund when the order is actually eligible, restarts a suspended service, extends a trial, and escalates to a human when a request falls outside its rules. Every action is a real database write.

The dashboard splits into two sides sharing one screen. The customer side is the voice call or text chat, plus a resolution card showing the outcome in plain language once the agent acts. The Loopline side, Loopline being the fictional SaaS business Fixer supports, is the internal view: a live ticket feed, the customer roster, and the order book, updating in real time. The customer never sees that side. The split makes the point visible: every action the agent takes is something the business can audit.

How we built it

Xano holds everything: three tables (customer, order, ticket), five XanoScript functions carrying the actual refund and eligibility logic, five AI tools that wrap those functions, an AI agent bound to the tools, and a realtime channel that pushes every action to the dashboard. The same five tools are exposed as plain REST endpoints, so an ElevenLabs Conversational AI agent calls the identical backend a human-built frontend would, no relay layer in between.

The frontend is one static HTML file hosted on Xano static hosting, polling Xano's REST endpoints and embedding the ElevenLabs widget. The architecture diagram above shows the full path: request in, decision made, write committed, reply spoken back.

Which AI tools did we use? Claude Code, driving the Xano CLI directly: writing XanoScript, pushing tables and functions, wiring the agent, and testing every call against the live API in the same session it was written. ElevenLabs' Conversational AI agent, configured through its own dashboard, gave Fixer a voice.

How long did it take to build? Five days, across a handful of focused sessions.

What would have taken significantly longer without AI and Xano? Hand-rolling an equivalent backend, a schema, REST endpoints, a tool-calling agent loop, a realtime push channel, would normally mean picking a framework and wiring infrastructure before writing a single line of business logic. Here the schema and the logic are XanoScript files pushed straight to a hosted backend, and the agent's tool-calling loop already exists as a Xano primitive, ready to bind five functions to and call live.

Challenges we ran into

XanoScript's block syntax turned out to be stricter than the docs implied. db.get and similar calls needed each property on its own line; putting two on one line produced a parser error pointing at the wrong token, which cost a few rounds of guessing before the pattern became clear.

Configuring the ElevenLabs agent's five webhook tools through browser automation was the single biggest time sink of the build. The in-app sandboxed browser fought back at nearly every step: dropdowns that opened without rendering, clicks that landed on the wrong element after a viewport resize, a phantom command-palette dialog that kept stealing focus, and repeated 30-second timeouts on one specific control. Switching to the user's own Chrome, driven the same way, fixed almost all of it immediately. The sandboxed renderer was the actual bottleneck. Even there, ElevenLabs' form pre-filled each new tool with the previous tool's values, which had to be caught and overwritten field by field rather than trusted.

Xano's free-plan rate limit (10 requests per 20 seconds, instance-wide) surfaced mid-demo: the dashboard's own polling loop was eating most of that budget on its own, so a live tool call from the voice widget would occasionally get squeezed out and the agent would stall with no graceful fallback. The fix was mundane, slow the polling interval, but finding it meant reproducing the exact failure with a direct curl call first.

Accomplishments that we're proud of

The full loop is real: a live voice call restarted an actual suspended account and the customer table changed in front of us while the call was still running. The refund path enforces its own policy in code, so asking it to refund an ineligible order gets a real rejection with a real reason. And the two-sided dashboard came together from a single ask into a layout that makes the audit-trail story legible at a glance, which matters more for this kind of product than any amount of prose would.

What we learned

The most reliable path through repeated browser-automation failures came from noticing they clustered around one specific environment, the sandboxed renderer, and switching environments. XanoScript rewards writing in the exact shape the docs show. A formatting deviation alone, with the underlying logic unchanged, is enough to break the parser. And a rate limit that seems generous in isolation can be entirely consumed by a feature (dashboard polling) that has nothing to do with the feature being tested (a live tool call), which is a class of bug that only shows up under real, simultaneous use.

What's next for Fixer

Per-session scoping for the resolution card, so two people testing at once don't see each other's outcomes. A written policy engine instead of five hardcoded eligibility checks, so new refund rules don't require a new function. Multi-tenant support, so Loopline becomes one business among many the same backend can serve. And a small library of these support-agent patterns (the identity-check-before-any-write rule, the policy-in-code-not-in-prompt rule) written up as a reusable Xano skill, since none of it was specific to refunds.

Built With

• claude-code
• elevenlabs
• python
• xano