Ticketing agents and an agent platform at Carro

The role

I joined Carro, a used-car marketplace, as an AI engineer in July 2025. Most of Carro’s work with customers runs through tickets: a question about a car, an offer to sell one, a workshop booking. Ops teams in Singapore, Malaysia and Hong Kong work through them every day. My job is to turn their processes into agents, and to make those agents cheap and safe enough to run at that volume.

Noteworthy projects

Ticketing agents

We started with two agents. Today the team runs fifteen, and most of them were built on the new ticketing platform I led.

In the beginning we were on Google ADK. A workflow, like selling a car, has many stages, and each stage has its own rules. You can’t fit all of that context into one agent, so every stage became its own sub-agent, with its own tools and prompts, all written by developers. When we were asked for four more bots, one for each stage of a workflow, I asked why every workflow needed its own bot.

I compared Agno, the Claude Agent SDK and LangChain Deep Agents, built three proofs of concept, and pushed for skills with progressive disclosure. The agent sees a short list of what each skill does, and loads the full instructions only when it needs them. That lets one general agent handle many workflows. Ops can write their own policies as skills and hand them to the agent, instead of waiting for us to build a new bot. The team adopted this approach, and prompts moved into Langfuse instead of code releases. Setting up a new workflow went from about two weeks to about two hours.

The one I’m proudest of is the Carro Care bot, for our workshop. It handles the whole customer journey on WhatsApp: it answers questions, books a servicing slot, reschedules or cancels it later, and keeps our systems and the ops team in step.

Since then I’ve taken charge of eight bots end to end: scoping the requirements with ops, building and testing them, shipping them, and watching how they behave once real customers use them.

Department agents

Internal teams wanted agents too, for investigating tickets, pulling data and putting reports together. We started from Nanobot, an open-source personal agent, and adapted it for Carro. Two things were missing for a company. It had little security, so I added a credential proxy that keeps secrets away from the bot and layered guardrails against prompt injection. And bots couldn’t work together, so I added A2A, which lets one bot hand work to another.

Nanobot also showed us its limit. It was built for one person, so when a whole team shared it, memory and context ran together, and it had no idea who was allowed to do what. So we built department agents instead, with Shannon, my lead, and three others. Each agent mirrors a real department: an orchestrator at the top, clusters of related work under it, and specialist agents under those. Each one owns a clear part of the work and sees only what it needs.

I work on how these agents are managed and changed: their skills, tools, memory and secrets, and the approval flow that lets business users propose a change for an admin to approve. I also built the workflow planner, which turns a department’s SOP into steps across its agents, and an assistant that suggests changes to an agent.

Optimisations

At this volume, agents get expensive fast, and most of the cost wasn’t the model. When I broke the triage agent’s spend down by session, the top 1% of sessions used 19% of the money and 41% of the input tokens. Those were agents searching for something they were never given, like a link they couldn’t open.

I cut the tools they could reach and capped the loops, and the runaway sessions stopped. Separately, a clock in the system prompt changed every minute, so the prompt cache never held. Fixing it cut cache writes by 84% in testing. Then I ran judged trials in production, model against model in matched time windows, and moved six workflows from Claude Sonnet to DeepSeek at 76–80% lower cost per ticket. SOP adherence held at 93%, against 92% before.

Automations

Not everything needs an agent. For fixed flows, like appointment reminders and outreach to Carro Care customers, I built n8n workflows that connect Lark, BigQuery, CAPtain and WhatsApp.

Reflections

Attention to detail

Shannon once told me he thinks ERDs and sequence diagrams are the pinnacle of software engineering. As an engineer, everything I say carries weight. Take “we fetch the file”. What fetches it? From where? Who’s allowed to? When, and what does each fetch cost? What happens if it isn’t there? One sentence in a meeting can skip all of these. A diagram can’t, which is why I now draw before I build.

Structured thinking

I used to start with a fix. Now I follow the same steps every time:

1. Set the objective, and how I’ll know I’ve met it.
2. Get the current context: the traces, the code, the docs.
3. Form a hypothesis.
4. Choose the parameters to change, and hold everything else fixed.
5. Run it.
6. Observe the raw results.
7. Only then, conclude.

The prompt-cache bug took two wrong guesses before a controlled test showed the real cause.

Thoroughness

Before I build something, I ask how we’ll test it. What does done look like? Which cases break it? What happens on the unhappy path, and how will we know in production? When we switched models, I didn’t trust one score. I used three judges, matched time windows, and checked every serious finding by hand.

Reading the room

Shannon also taught me to watch people as well as systems. A manager asking for “a number” usually needs a decision they can defend. An ops lead asking for “a bot” usually needs fewer repetitive chats. Working out what my boss or a stakeholder really needs has saved me more time than any framework.

Big-picture judgement

There’s no perfect solution, only trade-offs. Four bots or one harness, Sonnet or DeepSeek, ship now or test longer: each answer gives something up. My job is to see the bigger picture, say plainly what each option costs, and pick the one that fits where the business is going.

Engineering mindset

My boss hates it when I call a model “cheap”. Every model has its own habits, and it’s on us to build a harness that works with them.

When I started, prompt engineering was all the rage. As models got better, the wording mattered less and what we fed the model mattered more. Better connectors and better data made context engineering the real work. Now models can take on longer and more complex tasks, so the work is the harness: the loop, the tools, the memory and the limits around the model. Does the agent stay on the rails after a run of errors? What happens when memory is truncated, or the context is too full? Does the same harness work well with every model we run, not only the one we tested?

He put it as racing. A real race engineer doesn’t say “the Lamborghini is the best car”. The answer depends on the car, the road and the conditions, and the engineer understands why. It’s the same with models. “Anthropic’s models perform best” isn’t an answer. The better question is why another model does worse here, and what we can change so that it does better.