A coaching brand came to us with a problem most AI projects don't admit out loud: the AI didn't sound human.
The client had 15 years of experience and 700+ client engagements behind her. She knew exactly what to say when someone's IVF had failed, when a diagnosis had just landed, when a woman had tried everything and was ready to give up. She had a voice — warm, expert, direct — and it worked. The question was whether an AI could carry that voice into Instagram DMs at scale, qualify leads naturally through conversation, and bring the right people to a discovery call.
We said yes. Then we spent weeks learning why that's harder than it sounds.
The instruction list that grew to 600 words and still didn't work
The first instinct was obvious. Write a system prompt. Tell the AI what to do.
We wrote the rules: be warm but not a therapist. Never give medical advice. Ask one question per reply. Don't open with "I'm glad you reached out." Match the emotional weight of what the person is saying. Don't push toward booking too early. Keep sentences short — this is Instagram DMs, not email.
We ran test conversations. The AI did something we didn't want. We added a rule. It did something else. We added another rule for that.
By the time we were done, the prompt was 600 words long. And it still wasn't working.
The model would follow a rule for a few turns and then drift. It would say "I'm sorry to hear that" — a phrase we'd explicitly banned — because it had processed the ban as text but hadn't internalised the reason behind it. Generic empathy. Technical compliance. Completely hollow.
The harder lesson: the more rules we added, the worse it got. The model was cognitively overloaded — simultaneously trying to write warmly, avoid 15 banned phrases, classify the scenario, time the booking invitation, ask exactly one question. Somewhere in all of that, the client's actual voice disappeared.
The pipeline we built and scrapped in one afternoon
If the monolithic prompt was failing, the engineering answer seemed obvious: break it apart.
We designed a multi-stage pipeline. A classifier that reads each message first and decides what kind of response is needed. A strategy engine that determines the goal for this turn. A writer that only writes — no classification, no strategy. A separate lead tagger. A quality gate that reviews the reply before it goes out.
Each stage had one job. On paper it was elegant.
We built it. We tested it. The conversations were worse than before.
When you compose a reply through four AI stages, you accumulate small errors and lose the thread. Voice that felt fragmented in a monolithic prompt felt completely incoherent when assembled from four separate calls. And when something went wrong — which it still did — diagnosing it meant tracing through every stage to find the failure point. The system had become opaque and still wasn't producing good conversations.
We scrapped the entire pipeline in a single afternoon.
The insight that changed everything
Somewhere in the middle of this, we stopped and asked a different question.
Not: how do we tell the AI what to do?
But: how does the AI actually learn?
The answer is right there in how these models were built. They weren't trained on rulebooks. They were trained on enormous quantities of human writing — conversations, stories, articles — and they learned by absorbing patterns. Not instructions. Patterns.
We had been treating the model like a new employee: hand it a policy document, expect it to follow it. That's not how it works. The model learns from examples, not from descriptions of examples. Show it what good looks like and it generalises. Describe what good looks like and it forgets by turn three.
The second shift was in how we wrote the prompt itself. We had been writing instructions — do this, don't do that, when X happens do Y. We rewrote it as reasoning: here is who this person is, here is what she believes, here is what she has learned from 700 client cases. When the model understands why, it can apply that reasoning to situations you never anticipated. When it only knows what, it fails the moment the situation doesn't exactly match a rule it was given.
What we built instead
We wrote 13 conversations in the client's voice. Real scenarios: a miscarriage, a failed IVF cycle, a PCOS diagnosis, a partner who isn't on board, someone who had tried everything and given up hope. Each one was a complete example of how she actually talks — the rhythm, the warmth, the way she holds someone's pain and then gently shifts the frame.
These examples went into every AI call. Not as instructions. As demonstrations.
The transformation was immediate. The model wasn't fighting rules anymore. It had seen how she handles grief, so it handled grief the way she does. It had seen how she responds to "IVF is my only option" — reframing without dismissing — so it started doing that naturally, including in scenarios the examples didn't explicitly cover.
We also rewrote the core prompt as a portrait of her thinking: her belief that the body isn't broken, just not fully supported. Her instinct to listen before advising. Her understanding that trust has to come before any invitation to book a call. The model understood why she behaves the way she does, and that understanding carried into conversations in a way that rules never had.
The final system: a clear description of who she is, 13 example conversations, one AI call per message. No classifier. No routing. No pipeline.
For one piece of state-dependent logic — how pricing is handled across repeat questions — we kept that in application code, not the prompt. State-dependent logic belongs in code. Conversation logic belongs in examples.
The engagement level and quality of leads coming through shifted measurably. For a high-ticket coaching programme, that's the only metric that matters.
What this means for how we build now
This project changed how we approach every LLM system we build.
Examples outperform instructions every time. If you want an AI to behave a certain way, show it that behaviour. Don't describe it — demonstrate it. Write the conversations you want it to have. The model was trained on human writing, and it learns at the prompt level the same way.
Explain why, not what. A model that understands the reasoning behind a behaviour will handle novel situations correctly. A model that has memorised rules will fail as soon as the situation doesn't match a rule it was given.
Complexity backfires. Every layer of infrastructure we added made things worse. More stages, more opportunities for errors to compound, harder to diagnose what's actually failing. The simplest version of the system produced the best conversations. That's almost always how it goes — but you have to build the complicated version first to really believe it.
The hardest part is never the technology. It's understanding how to communicate with the model in a way it can actually learn from. Once you understand that, the implementation is straightforward.
We now apply this to every AI system we build — whether it's a client-facing conversational agent, an internal workflow tool, or a multi-step reasoning system. The principle holds across all of them.
FAQs
What is few-shot prompting and why does it work better than instructions?
Few-shot prompting means giving a language model worked examples of the behaviour you want, rather than written rules. It works better because LLMs were trained on patterns in human writing — they learn by generalising from examples, not by following instruction lists. When you show the model what good looks like across 10–15 diverse scenarios, it generalises to situations those examples never explicitly covered. When you describe what good looks like in rules, it follows them inconsistently and fails on edge cases.
How many examples do you need for few-shot prompting to work?
In our experience, 10–15 high-quality examples covering your most important scenarios is the practical threshold for voice-consistent behaviour. Below that, the model lacks enough pattern signal to generalise reliably. Above 20, you're unlikely to see meaningful improvement and you're consuming context window that could be used for conversation history. Quality matters more than quantity — each example should represent a meaningfully different scenario, not variations on the same one.
Why did a multi-stage AI pipeline produce worse results than a single call?
Multi-stage pipelines accumulate errors across each handoff. Each stage makes small interpretation decisions that the next stage inherits — by the time the final output is assembled, you've lost the coherence that a single call maintains naturally. Voice consistency in particular degrades badly across stages because each stage is optimising locally, not for the overall conversational thread. Diagnosis also becomes harder: when something goes wrong, you have to trace every stage to find the failure point. For conversational AI specifically, a well-structured single call almost always outperforms a pipeline.
How do you handle state-dependent logic in a conversational AI system?
State-dependent logic — decisions that depend on what has happened earlier in the conversation, like how to respond differently the second time someone asks about pricing — belongs in application code, not in the AI prompt. The prompt handles conversation logic: voice, tone, reasoning, response structure. Application code handles state: what turn we're on, what the user has already asked, what threshold has been crossed. Mixing the two into the prompt creates a system that's harder to debug and less reliable. Keep them separate.