Clementino our new AI colleague

A few months ago, my CEO came to me with what seemed like a straightforward request: build an AI agent that can answer questions about our operational data, just like Ramp did. At Domu we run a platform that powers call center operations for Fortune 500 Companies, and we have a database full of call analytics that nobody was querying efficiently. The ask seemed simple, a chatbot that could answer “how many calls did we handle yesterday?” without someone having to write SQL.

I built it in a few days. It worked. My CEO was happy. And honestly, at the time, I didn’t fully see the scope of what we’d just started. We use slack as our main UI because we found that the best way to get our team to adopt our new tools, is to reduce as much as possible the friction to use it, a big majority of our automations can be run from Slack right now.

The First Version Was a Lie (In a Good Way)

The first agent was straightforward: a Python script running on Windmill (our automation and orchestration platform) triggered by a Slack webhook, backed by Claude. You’d ask a question in a Slack channel, it would generate a query, run it, and reply with the answer.

But the moment people started using it, the requests expanded. “Can you also look at our CRM data?” “Can it remember what we talked about last week?” “Can it help me with my deals?” “Can it send emails on my behalf?” Each new request seemed reasonable on its own. And so I started building.

Phase 1: The Bot Zoo

The natural instinct, when you have a new problem, is to build a new tool for it. And that’s exactly what I did.

We ended up with a collection of specialized bots: a knowledge bot for querying data, a coach bot for sales coaching, a finance bot for expense questions, a recruiting bot for the interview pipeline. Each lived in its own Slack channel, had its own codebase, its own system prompt, its own integrations.

On paper, it made sense. Each domain had different needs, different tools, different levels of sensitivity. In practice, it was a maintenance nightmare, and worse, it was confusing for the team. Which bot do you ask about a deal that involves both CRM data and an upcoming invoice? Which channel do you go to when you need something that crosses domains? We had too many bots and nobody knew which door to knock on.

This is the part nobody talks about when they write about AI agents: the operational overhead of managing multiple independent agents at scale.

Phase 2: One Brain, Many Skills

The rethink came when I stopped thinking about agents as separate bots and started thinking about them as skills that a single brain could invoke.

The architecture shift was conceptually simple but technically meaningful. Instead of six bots, we now have one orchestrator, we call it Clementino, that runs on Claude Opus as its central reasoning engine. Clementino has access to six specialist delegates: sales/CRM, finance, client operations, engineering, recruitment, and knowledge. When you ask it something, it figures out which delegate(s) to call, and can call multiple in parallel if the question spans domains.

The team now has one virtual peer, just one bot, and one context. Clementino knows who you are, remembers what you talked about last week, and handles the messy cross-domain questions that real business operations actually generate.

What I learned from this transition: the hardest part isn’t the AI. It’s designing the seams between systems. Where does one agent’s responsibility end and another’s begin? How do you pass context across a delegation boundary without losing information? These are system design problems with AI complexity layered on top.

The UX Journey Nobody Talks About

The architectural shift was only part of the evolution. The other part was all the small things that make an agent actually usable day-to-day.

Memory: Early agents have no sense of continuity, every conversation starts from zero. We built a persistent memory layer where Clementino can store and retrieve facts across sessions. If you told it last week that a deal is closing at the end of the quarter, it still knows that next week.

Thread continuity: Slack conversations are threads, and agents need to understand that context. If you asked three questions in a thread and your fourth is a follow-up, the agent needs all of that history. We built a session system that fetches the thread and feeds it into every request.

Human-in-the-loop approval: This was critical for trust. Some actions like: sending an email, scheduling a calendar meeting, creating a Stripe invoice, sending an NDA via DocuSign, require human sign-off before execution. We built a “gated tools” system where the agent proposes the action with a full preview in Slack, and a human clicks Approve or Reject. This single design decision made the team comfortable letting agents act on their behalf.

Model routing: Not every request needs our most powerful (and most expensive) model. A quick data lookup doesn’t need the same reasoning capacity as a complex multi-source analysis. We added a classification layer that routes requests to the appropriate model tier based on complexity. The result: faster responses on simple queries, lower costs overall, and full power where it actually matters.

Adoption Numbers:

• 1500+ Threads

• 10k+ Messages

• 700 Hours Saved in One month

Across a team of 20 people, in the first month after deploying the first Agent.

What I’d Tell Myself at the Start

Start with one agent, not many. Resist the urge to create specialized bots for every problem. The coordination cost of multiple agents compounds faster than you expect.

Invest in UX before investing in capabilities. Memory, thread continuity, and human-in-the-loop approval did more for adoption than any new feature we added. People trust agents that feel coherent and don’t act without asking.

The architecture will evolve, and that’s fine. The first version will be wrong. Build it, learn from how people use it, then refactor. The orchestrator we have now wasn’t obvious at the start. It emerged from real usage patterns and real pain.

Build trust incrementally. We started with data queries. Then CRM lookups. Then email drafting. Then autonomous workflows with approval gates. Each step built on the trust established by the previous one.

What’s Next

We’re currently at 7X. The goal is 20X, and we have a clear path to get there.

The next frontier is expanding horizontally across the company. What started as a GTM and sales tool is becoming infrastructure for engineering, finance, client operations, and recruitment. The same agent, the same memory, the same approval system, just with new skills plugged in.

The vision is a company where every person has an AI layer that knows their context, handles the routine, and escalates the important. Not a chatbot. A AI colleague.

We’re building it live. And in the next post, I’ll share more learning we'll have down the road.