By David, co-founder of Kaddi

Most of what gets called "AI for sales" right now is a rep with a chat window open in another tab. They paste in a transcript, ask for a follow-up email, copy the answer back out. It works. It's also entirely dependent on that one rep remembering to do it, being good at asking, and having the patience to re-explain the account every single time or to somehow organise projects for many sales opps.

That's not a system. It's a habit, and habits don't survive a busy quarter.

What I want to describe here is what the other version looks like - a real agent, doing a real job, triggered from inside the tool your team already lives in. We've been building exactly this with our clients, and it's genuinely buildable today with off-the-shelf pieces. None of it requires a research team. It does require getting a handful of design decisions right, and most of those decisions are less about AI than they are about where things live and who owns them.

Start with a job, not a capability

The first mistake is scoping by tool: we should use AI for customer success. That produces nothing you can build.

Scope by job instead, and pick one with a clear finish line. A customer case study. A QBR deck. A renewal brief. A monthly account wrap. Each of those has an obvious definition of done, someone is already paid to produce them, and they happen often enough that getting them right compounds.

For the rest of this post I'll use a case study agent as the running example, because it's the one where the gap between "we should do more of these" and "we produced four last year" is widest in most companies.

The four pieces, and why they live in different places

An agent that survives contact with a real business has four components, and the single most important design decision is refusing to let them collapse into one place.

The process - the sequence of steps the agent runs. Summarise the source material, draft the narrative, structure it into an outline, rewrite it in the company's voice, QA it against the sources, build the deck. Six steps, each one reviewable, rather than one enormous prompt. Chaining them like this is what makes output consistent from run to run, and it's what lets you find and fix the specific step that's below par rather than rewriting everything.

This is code. It should be version-controlled and changed only by whoever owns it - in practice, packaged as a plugin installed across the organisation rather than living in one person's chat history. That matters more than it sounds. If the process lives in the head or the laptop of the person who built it, you have a consultant, not a capability. When they leave, it leaves.

The standards - the goal, the definition of "good," the brand voice, a few reference examples of excellent output. These are content, not code. Your marketing team should be able to sharpen the voice guide or add a new reference example on a Tuesday afternoon without filing a ticket against the plugin. So they live in a shared drive folder the agent reads at runtime.

That split - logic in the plugin, standards in a folder - is the one I'd argue hardest for. It's the difference between a system that improves weekly and one that ossifies.

The data - the raw material about the specific customer. More on this next, because it's where most people get stuck.

The people - split by role, not by ownership of the whole pipeline. The CSM or AE originates the work, because they're closest to the customer and they're the only ones who actually know whether something is case-study-worthy. Marketing owns the quality gate, because brand consistency needs one chokepoint regardless of who wrote the draft.

Where the source data comes from

Every customer gets a folder, and inside it a Source/ folder. That folder is the agent's entire view of the world. Whatever's in there is what the case study will be built from — and, just as importantly, whatever isn't in there is what the agent has to admit it doesn't know.

How the folder gets filled is a genuinely open choice, and I want to be straight about that.

You can fill it by hand. A CSM drops in the call transcript, the QBR notes, the email thread where the customer described their before-state. It's unglamorous and it works fine for a pilot. If you're testing whether this whole idea has legs, start here and don't let anyone tell you it isn't sophisticated enough.

You can fill it from the tools you already have. Most conversation intelligence platforms, CRMs, and support desks will export or sync. It's more setup, but it removes the remembering.

Or you can use a system that ingests continuously - which is what Kaddi does. It pulls email, call transcripts, Slack messages and support tickets into a per-customer workspace as they happen, then exposes a targeted extract when an agent asks for one. The advantage isn't just automation. It's that you can ask for the material relevant to a case study rather than dumping eighteen months of everything into the agent and hoping it finds the signal. Feeding a model a firehose is slow, expensive, and produces worse output than feeding it a curated handful of the right things.

Whichever route you take, one rule holds: write the extract into the folder as a real file. Don't treat it as something that flows through invisibly. When marketing questions a claim in a draft six weeks later, you need to be able to point at the exact source material the agent was working from. That audit trail is what makes people trust the output enough to send it to a customer.

The part that makes it click: Slack

Here's where this stops being an interesting architecture diagram and starts being something a team actually uses.

Most companies running per-customer Slack channels have already built the perfect front door for this and don't realise it. The channel for a given account is where the CSM, the AE, and the Sales Engineer are already talking about that customer. The context is there. The people are there.

So make that the trigger. Someone types "hey, run a case study for this account" in the channel. A few seconds later they get an acknowledgement. 10-20 minutes after that, a draft lands back in the same thread, ready for review.

Three things make this dramatically better than any alternative I've seen:

No new tool. The adoption tax of a new interface is brutal and consistently underestimated. Every dashboard, portal, and internal app I've watched get built for a sales team follows the same curve: enthusiasm for three weeks, then quiet death. Slack has no curve because there's nothing to adopt.

No installation. The person triggering the agent doesn't need Claude CoWork or any AI software on their machine. The agent runs on a service account behind the scenes — properly permissioned, fully logged, but invisible to the requester. That's the difference between rolling this out to five pilot users and rolling it out to fifty.

It's social. This one surprised me with how much it matters. When someone triggers an agent in a shared channel, everyone else in that channel sees it happen, sees the output arrive, and sees that it was good. That's adoption spreading by demonstration rather than by training session. You can't get that from a private chat window.

And it runs in both directions. The agent shouldn't only wait to be asked. It can post proactively: there's been strong signal on this account, worth a case study — or this renewal is ninety days out, want the brief? That's the shift from a tool people have to remember, to a colleague who reminds them.

The same principles should apply for Microsoft Teams - next we need to prove the technical build.

The quality gate is a folder, not a policy

Inside each customer folder, work moves through stages: Source/, then Summary/, then QA/, then Output/.

That's not filing tidiness. It means a document's location is its status. Nothing lands in Output/ until a human has reviewed it, so you never need a separate tracker to know what's waiting on whom - and nothing reaches a customer unreviewed, because the structure enforces it rather than a policy asking nicely.

How rigorous that review needs to be should scale with the stakes. An internal monthly wrap can be approved with an emoji reaction. A case study going on your website gets opened and read properly.

Two more things to lock this in

A dashboard. Once you're running several agents across a hundred-plus customers, nobody can hold the state in their head. A live view - what's in flight, what's stuck in QA, what's stalled for a fortnight, progress against the annual target - turns a pile of folders into something a manager can actually run.

A conductor. A dashboard is a pull mechanism: it only works when someone remembers to open it. So add a weekly scheduled job that checks what's due, checks what's already in flight so it doesn't nag about work in progress, works out who owns it, and sends each person one short digest. Not five separate notifications from five agents - notification fatigue kills.

Three sections, capped at five or six items: what's due, what's stalled on you, and what you finished last week. That last one works. A digest that only ever nags gets muted inside a month. The small bit of positive reinforcement is what keeps it being opened in week twelve.

What breaks when you scale it

The instinct at fifty customers is to centralise - put a small ops team in charge of running all the agents for everybody.

It may not work, for two reasons. The volume math turns brutal fast, and a central team becomes permanently underwater. But the deeper problem is that you throw away the thing the CSM brings: they know whether a customer is genuinely worth writing about in a way that nobody reading an extract ever will.

Keep triggering distributed. Keep the quality gate centralised.

Why this is worth your attention now

None of the individual components here are exotic. A shared drive. A chat tool you already pay for. A model with tools and a clear job. The novelty is entirely in how they're arranged - what lives where, who's allowed to change it, and where the human check sits.

Which is good news, because it means the barrier isn't budget or engineering headcount. It's design judgement, and that's learnable. The teams pulling ahead right now aren't the ones with the biggest AI spend. They're the ones who worked out that an agent needs a defined job, real context, a quality gate, and a front door where people already are.

We're building this with customers now, and learning things in the process that I couldn't have told you six weeks ago. If any of it is useful to you, I'm happy to talk it through.

Kaddi and Kaddi Studio are operated by SalesGRID Pty Ltd, Melbourne.