How to Turn 238,000 Customer Conversations Into Work Your AI Agents Actually Do

Your AI agent replying to customer DMs is the least valuable thing it does.

The valuable part is what happens after. Route every conversation into one analyst agent, let it trace which threads became sales, and let it dispatch work to your other agents. Over six months my Instagram agent handled 238,000 conversations. 4,200 became sales. The analyst read all 238,000.

That second number is the one people quote back to me. It is the wrong number to care about.

Why does a working DM agent still leave most of the value on the table?

Because a reply is a terminal event. The agent answers, the person leaves, and the conversation dies in an inbox nobody will ever open again.

238,000 conversations is not data. It is noise. No human reads that. No team reads that. Not in six months, not in six years. A team of ten reading full-time would still be reading conversations from March.

So the default outcome is that the most honest research asset your business will ever produce sits in a database, unread, while you go pay for a survey tool.

That is the actual bottleneck in most AI agent workflows. Not the quality of the replies. The fact that nothing downstream consumes them.

Step one: where do 238,000 conversations actually go?

Into a single system with an analyst agent pointed at them. Not a reporting tool. Not a CRM view. An agent whose entire job is to read and understand.

I connected the Instagram conversations into Focus Pilot and pointed a business analyst agent at the whole corpus. That distinction matters more than anything else in this post.

A chatbot's job is to respond. An analyst's job is to comprehend.

They are different roles with different success conditions. The chatbot is measured on whether the person felt answered. The analyst is measured on whether it told you something true that you did not already know.

Most people build the first one and stop. They never build the second one, so the first one never gets smarter.

The analyst agent brief

You are a business analyst. You do not talk to customers.

Your input is the full transcript archive of customer conversations, with outcome data attached to each thread (purchased, did not purchase, went quiet, and at which stage).

Your job:

1. Read the full corpus, not a sample.
2. For every thread that ended in a sale, reconstruct the sequence: first message, questions asked, objection raised, moment of resolution, purchase.
3. For every thread that stalled, identify the last question asked before the person went quiet.
4. Cluster the questions and objections by frequency and by how close they sat to the buying decision.
5. Quote real customer language verbatim. Do not paraphrase into marketing speak.

Output a written plan, not a dashboard. Tell me what to build, what to send, and what to publish, and cite the conversation evidence behind each recommendation.

Notice what is missing from that brief. No metrics targets. No KPIs. I am not asking it to score anything. I am asking it to understand a body of human conversation and tell me what it found.

Step two: how does an analyst agent trace revenue backwards?

It starts at the sale and walks the thread in reverse, message by message, until it reaches the first thing that person ever said.

That is the move. Forward-looking analytics tells you what percentage converted. Backward tracing tells you what the person asked ninety minutes before they converted, and what changed in their language when it clicked.

For every one of the 4,200 sales, the analyst reconstructed:

Which thread turned into a customer. What that person asked before they bought. Where the hesitation showed up in the conversation. What words they used at the moment it finally landed.

Then it did the same thing for the threads that died. That half is arguably more valuable. A stalled conversation has a last message, and the last message is almost always a question you were not answering well.

This is the thing a human team physically cannot do at this volume. Not slowly. Not ever. The math does not work.

An agent doing this well needs to hold context across an entire thread and across thousands of threads at once. That is a real constraint, and it is the reason a lot of these builds fall apart in month two. If your agent cannot retain what it learned, you are re-teaching it constantly. I wrote about that failure mode in detail in why AI agents forget.

Step three: what does the analyst produce instead of a dashboard?

A written plan. Prose. Recommendations with evidence attached.

It did not hand me a dashboard. I do not want a dashboard. A dashboard is a machine for converting insight back into homework, and the homework never gets done.

Here is the difference in practice.

A dashboard says: 31% of conversations mention pricing.

A plan says: people are not confused about price, they are confused about what happens after they pay, here are eleven verbatim quotes showing it, and the fix is a section on the sales page that shows the first seven days step by step.

One of those is a fact. The other is an instruction.

The plan it wrote covered the real objections, the real gaps, and the real questions we were never answering anywhere on our site, in our emails, or in our content. Not hypothetical objections from a swipe file. Objections that 238,000 people actually raised.

This is the difference between an operator and an engineer, and it is covered at length in the operator's system for running agents. An engineer builds the reporting layer. An operator asks the agent to just tell them what to do.

Step four: how does one agent dispatch work to other agents?

By writing instructions and handing them off. The analyst never built anything itself. It told the agents that build things what to build.

This is the part that changed how I work.

The analyst went to my website agent and told it what to build. Then it told my email agent what to send. Then it told my blogging agent what to write.

Every instruction was grounded in real conversation data. Not a guess. Not a swipe file. Not best practices from a 2019 conference talk. What our actual buyers said, in their own words, in the minutes before they bought.

What does a dispatch instruction look like?

It is specific enough to build from without a follow-up question. Vague instructions between agents fail the same way vague instructions between people fail.

For the website agent, it did not say "improve the page." It specified the layout. Break out each point individually. Show untrained AI against trained AI side by side, because that comparison was the single thing that resolved the most stalls. Hook the live chat directly into the page rather than burying it in a corner widget.

Then it handed the landing page agent the audience segments it had found in the data, plus the copy for each one.

Dispatch instruction format

TO: [receiving agent]
BUILD: [the specific asset]
BECAUSE: [the pattern found in conversation data]
EVIDENCE: [3-5 verbatim customer quotes]
LAYOUT / STRUCTURE: [explicit, section by section]
AUDIENCE SEGMENT: [who this is for, defined by observed behavior, not demographics]
SUCCESS CONDITION: [what changes in future conversations if this works]

That last field is the one people skip. A success condition closes the loop. It tells the analyst what to look for in next month's conversations to know whether the thing it commissioned actually worked.

Without it you have a one-way pipeline. With it you have a system that grades its own output.

Why does chaining agents beat one big agent?

Because each agent stays narrow enough to be good at its job, and narrow agents are debuggable.

When the blog output is weak, I know it is the blogging agent. When the page converts worse, I know it is the website agent or the brief it received. One monolithic agent doing all five jobs is a black box, and black boxes cannot be improved.

The orchestration pattern here, one agent producing structured instructions that other agents consume on a loop, is the same shape I use for engineering work. If you want the mechanics of building the loop itself, that is covered in loop engineering for Claude Code agents.

Step five: how does an agent go hunting for prospects on its own?

It leaves your data entirely and goes to the open internet with the context it already built.

After the dispatch round, the analyst went hunting. It analyzed prospect websites. It read their social profiles. It worked out who these people actually are as businesses, not as handles in an inbox.

Then it kicked me a prospect list with the work already done. For each name:

Where the relationship currently stands. A summary of every conversation we have ever had with them. What the business actually is. The scale of the opportunity. The specific problem they have. The buying signal, quoted from their own message.

I opened it and started talking to people.

That is the whole experience. No research phase. No tab sprawl. No twenty minutes of context reconstruction before every call. The context was already assembled by something that had read every word.

What did 238,000 conversations teach me that no dashboard ever did?

People want to talk and get answers. At scale. That is functionally impossible for a human team and completely normal for an agent.

Over 80% of our business is attributed to those DMs. Eighty percent. Through a channel most companies treat as a support cost center and staff with the cheapest labor they can find.

The reason it works is not automation. It is that the agent is trained on our actual business intelligence, so it answers people instead of deflecting them. It knows what we do, what we do not do, what things cost, and what happens next. When it makes sense, it points someone toward the step that would actually help them.

Deflection is what most companies deploy. A deflection bot exists to reduce ticket volume. An answering agent exists to give someone what they came for. Customers can tell the difference inside two messages.

Why was a static website quietly costing us money?

Because every visitor who arrived with a question had nowhere to ask it, and questions that go unasked become people who leave.

My analyst surfaced this and it was obvious in retrospect, which is the signature of a good finding. We had built an entire business on conversation. Eighty percent of revenue came from people talking to us. And our website, the single highest-intent surface we own, offered no way to have that conversation.

So the analyst told me to put the agent on the site. I did.

This is exactly the kind of gap that shows up when you audit a site against how people actually behave rather than against a design checklist. I broke down that process in the AI agent website audit.

What breaks when operators try to build this themselves?

Four things, in roughly this order.

The analyst has no outcome data. Conversations without purchase outcomes attached cannot be traced backwards. You get a topic summary instead of a revenue map. Connect the outcome data first, even if it is imperfect, even if it is a manual tag.

The output is unstructured. If the analyst writes a beautiful essay, no downstream agent can act on it. The dispatch format has to be rigid enough for another agent to parse and specific enough to build from. Structure the output before you scale the input.

The agents have no shared memory. Each one starts cold, re-derives context, and drifts from the others. Within a month they are three agents with three different pictures of the business. This is the most common failure and the least visible one.

The setup never finishes. This is the big one. Most people quit during configuration, not during operation. They get 70% through wiring, hit a schema problem on a Thursday night, and the project quietly dies in a folder.

How do you build a smaller version of this before you have volume?

Start at 500 conversations. The mechanism does not require 238,000. Volume gives you statistical confidence, but the process is identical and the findings appear early.

Here is the compressed version.

Export your last 500 customer conversations from wherever they live. Instagram, email, support desk, sales calls, all of it. Tag each one with its outcome: bought, did not buy, went quiet.

Point one agent at the archive with the analyst brief above. Give it the corpus in full, not a sample.

Ask it for one written plan naming the top three questions that appeared immediately before purchase and the top three that appeared immediately before silence.

Build one thing off that plan. One page, one email sequence, one article. Not six.

Wait thirty days, feed it the new conversations, and ask whether the pattern moved.

That loop, run five times, will teach you more about your buyers than any research vendor you could hire. It costs you an afternoon of setup.

What is actually running this, and where is it right now?

Everything above flows through one central brain: Focus Pilot. The analyst, the website agent, the email agent, the blogging agent, and the landing page agent all coordinate through it.

I am building it in public. It runs my business today. It is not a finished product sitting on a shelf, and I am not going to pretend otherwise.

We are days from opening it up to the community, and I am doing it that way deliberately. I want to work one-on-one with people through the setup, because the setup is where most people quit. That is not a marketing line. It is the observed failure point across every operator I have watched attempt this.

No AI slop. No three-week configuration nightmare. If you are non-technical, that is who this is being built for.

What is the real shift here?

The shift is from agents that respond to agents that decide.

A responding agent handles volume. That is useful and it is where almost everyone stops. A deciding agent reads what the responding agent collected, works out what it means, and puts the rest of your agents to work on it.

One reads. One acts. The reading agent is the one that compounds.

Every conversation your business has is either an asset or exhaust. The only thing that determines which is whether something is reading them.

Mine reads all of them. It has never asked for a day off.

If you want to build this alongside me while it is still being assembled, The Sprint is where it happens. The $1 entry and the current monthly price both change when Focus Pilot goes live.