The Old World Died Quietly
For about fifteen years, building a conversational AI agent meant the same thing. You mapped out intents. You wrote rules. You built decision trees. You trained classifiers on example utterances. And then you spent months patching the cracks when customers said things your intent map did not anticipate, which they did constantly.
The arrival of large language models did not just add a new tool to this process. It rendered most of it obsolete. The entire intellectual framework for "training" an agent shifted. The skills that mattered changed. The bottlenecks moved. And the people who had spent years mastering the old approach found themselves in a fundamentally different discipline.
This article is about what actually changed, what the new discipline looks like in practice, and what most teams still get wrong when they build LLM-powered agents.
What Agent Training Used to Mean
Before LLMs, the term "agent training" referred to a specific, labor-intensive process. It worked roughly like this:
Step 1: Intent mapping. A team of conversation designers would catalog every possible thing a customer might want to do. "Check order status." "Request a refund." "Change shipping address." "Ask about product compatibility." Each of these became an intent, and each intent needed a name, a description, and a set of example utterances.
Step 2: Utterance collection. For each intent, the team would write or collect dozens of example phrases. "Where's my order?" "Can you track my package?" "I need to find my shipment." "What's the status of order 12345?" All of these map to the same intent, and the classifier needed enough examples to learn the pattern.
Step 3: Dialog flow design. Once intents were defined, designers built the conversation flows. If the customer says X, ask Y. If they provide Z, look up W. Each path through the conversation was a hand-crafted tree of conditions and responses.
Step 4: Entity extraction. Within each utterance, the system needed to identify specific pieces of information: order numbers, dates, product names, addresses. Each entity type required its own training examples and validation rules.
Step 5: Testing and patching. The team would test the flows, find gaps, add new intents, write more utterances, and repeat. This cycle never really ended. Every new product, policy change, or unexpected customer behavior required manual updates to the system.
This process worked. Plenty of companies built useful chatbots and IVR systems this way. But it had fundamental limitations that no amount of effort could overcome.
Coverage was always incomplete. No matter how many intents you defined, customers would say things that did not match any of them. The "fallback" intent, the one that fired when nothing else matched, was often the most-triggered intent in production systems.
Maintenance was relentless. Every product launch, policy change, or seasonal shift required updates to intents, utterances, flows, and entities. A team of conversation designers could spend more time maintaining the existing system than improving it.
Natural conversation was nearly impossible. Customers do not follow decision trees. They change topics mid-sentence, provide information out of order, ask tangential questions, and circle back to earlier points. Rule-based systems handled this poorly because every deviation from the expected path required an explicit rule.
Scaling across domains was prohibitively expensive. Building an agent for billing support was one project. Building one for technical support was a second project almost from scratch. The skills and structures from one domain rarely transferred cleanly to another.
What LLMs Actually Changed
When teams started building agents on GPT-3.5, GPT-4, Claude, and other large language models, several things changed simultaneously. It is worth being specific about each one, because the implications are different.
Natural language understanding became a commodity
The most immediate change was that intent classification went from a hard problem to a solved one. An LLM does not need 50 example utterances to understand that "Where's my package?" and "Can you track shipment 4521?" are both asking about order status. It understands language natively. You do not train it to understand intents. It already understands them.
This eliminated the most tedious part of the old process. No more utterance collection. No more intent classifiers. No more entity extraction models. The LLM handles all of it as a side effect of its general language capability.
The bottleneck moved from understanding to behavior
With understanding solved, the challenge shifted to a different question: how do you get the agent to behave the way you want?
In the rule-based world, behavior was specified explicitly. Every response was written by a human. Every decision point had a hand-crafted condition. The agent could only do what it was explicitly told to do.
With LLMs, the agent can do almost anything. It can generate fluent responses on any topic. It can reason through multi-step problems. It can adopt different tones and personas. The problem is no longer "how do I make the agent understand?" but "how do I make it behave consistently, accurately, and within appropriate boundaries?"
This is a harder problem than it sounds. LLMs are capable but not reliable by default. They can hallucinate facts, go off-topic, make promises the company cannot keep, or adopt an inappropriate tone. The new discipline of agent training is largely about constraining and guiding this capability.
The unit of work became the prompt
In the old world, the unit of work was the intent, the utterance, the dialog node, the entity. In the new world, the unit of work is the prompt.
A system prompt defines who the agent is, what it knows, how it should behave, what it can and cannot do, and how it should handle ambiguous situations. A well-written system prompt can accomplish in a few hundred words what used to require thousands of rules and dialog nodes.
But "well-written" is doing a lot of work in that sentence. Writing effective prompts is a skill. It requires understanding how LLMs interpret instructions, where they tend to go wrong, and how to structure guidance that remains effective across thousands of diverse conversations. Prompt management has become a distinct operational discipline.
Knowledge management replaced utterance collection
In the rule-based world, the agent's knowledge was implicit in its rules and responses. It knew what it was programmed to know and nothing else.
LLMs know a lot from their training data, but they do not know your company's specific policies, products, or procedures. And their training data has a cutoff date, so even general knowledge can be outdated.
This makes knowledge management the new form of "training." Instead of writing utterances, you curate documents. Instead of building intent classifiers, you build a knowledge base that the agent can query in real time. The quality of the agent's responses depends directly on the quality and organization of this knowledge base.
Tools became the new decision trees
Rule-based agents took actions through pre-programmed integrations triggered by specific dialog paths. LLM agents take actions through tools: structured functions the agent can call when it determines an action is needed.
Instead of building a dialog flow that says "if the customer provides an order number, call the order lookup API," you give the LLM a tool called "look_up_order" with a description and parameters. The LLM decides when to call it based on the conversation context.
This is more flexible but introduces new challenges. The agent might call tools unnecessarily, with wrong parameters, or in the wrong order. Tool design and documentation become critical parts of agent training.
The New Discipline: What Agent Training Actually Looks Like Now
Here is what teams building LLM-powered agents actually spend their time on today. It looks nothing like the old process.
Prompt engineering and management
The system prompt is the single most important artifact in an LLM agent's configuration. It defines behavior, personality, boundaries, and decision-making logic. Teams iterate on prompts constantly, testing variations to improve performance on specific scenarios.
Effective prompts share certain characteristics:
They are specific about behavior, not just personality. Saying "be helpful and professional" is nearly useless. Saying "when a customer asks about a product that is out of stock, acknowledge the inconvenience, offer to check availability at nearby locations, and suggest similar products that are in stock" gives the agent actionable guidance.
They include boundary conditions. What should the agent do when it does not know the answer? When should it escalate to a human? What topics is it not allowed to discuss? What commitments is it not authorized to make? These boundaries matter more than the happy-path instructions.
They are structured for scannability. LLMs process prompts sequentially, and the structure of the prompt affects how reliably the instructions are followed. Using clear sections, consistent formatting, and explicit priority ordering (which instruction wins when two conflict) improves consistency.
They evolve based on data. The first version of a prompt is never the best version. Teams analyze real conversation data, identify where the agent goes wrong, and refine the prompt to address those gaps. This iterative process is the core of ongoing agent "training" in the LLM era.
Knowledge base curation
A well-curated knowledge base is often the difference between an agent that sounds smart and one that actually is. This work includes:
Content creation and formatting. Documents need to be written in a way that an LLM can use effectively. Long, unstructured policy documents work poorly. Structured documents with clear headings, explicit answers to common questions, and specific examples work well.
Coverage analysis. Which topics generate the most questions? Which questions does the agent answer incorrectly? Coverage analysis identifies gaps in the knowledge base that need to be filled.
Freshness maintenance. Products change. Policies change. Prices change. The knowledge base needs a maintenance process that keeps it current.
Relevance tuning. When the agent queries the knowledge base, the retrieval system needs to return the most relevant documents. This requires attention to how documents are chunked, how queries are formulated, and how results are ranked.
Tool design and configuration
Giving an agent access to tools is easy. Giving it access to well-designed tools that it uses correctly is harder.
Tool descriptions matter enormously. The LLM decides when and how to use a tool based on its description. A vague description ("looks up information") leads to misuse. A specific description ("retrieves the current status, shipping carrier, and estimated delivery date for a given order number") leads to correct usage.
Parameter design affects accuracy. Tools with too many parameters confuse the agent. Tools with too few force the agent to make assumptions. The right level of granularity depends on the specific use case.
Error handling is essential. What happens when a tool call fails? What if the API is slow? What if the returned data is incomplete? Agents need guidance for handling tool failures gracefully.
Evaluation and testing
In the old world, testing meant verifying that specific inputs triggered specific intents and produced specific responses. In the new world, testing is fundamentally different because the agent's responses are generated, not scripted.
Effective LLM agent testing uses scenario-based evaluation. AI-powered personas simulate realistic customer conversations, testing the agent across diverse situations, edge cases, and emotional contexts. Scorecards grade performance across multiple dimensions: accuracy, tone, policy compliance, tool usage, and resolution effectiveness.
This testing needs to happen continuously, not just at deployment. Prompt changes, knowledge base updates, and tool modifications can all alter agent behavior in unexpected ways. Automated testing catches regressions before they reach customers.
The Old World vs. The New: A Practical Comparison
| Dimension | Rule-Based Agent Training | LLM-Based Agent Training |
|---|---|---|
| Core activity | Writing rules and decision trees | Writing and iterating on prompts |
| Language understanding | Train intent classifiers on example utterances | Built-in LLM capability |
| Agent knowledge | Hard-coded in rules and responses | Retrieved from curated knowledge base |
| Taking actions | Pre-programmed integrations in dialog flows | LLM calls tools based on conversation context |
| Handling the unexpected | Fallback intent (usually poor experience) | LLM reasons about novel situations |
| Maintenance trigger | Every product/policy change requires rule updates | Knowledge base update, possibly prompt revision |
| Testing approach | Verify specific input/output pairs | Scenario-based evaluation with AI personas |
| Key skill | Conversation design, intent taxonomy | Prompt engineering, knowledge management |
| Scaling to new domains | Near-complete rebuild per domain | Mostly prompt + knowledge base changes |
| Time to first working agent | Weeks to months | Hours to days |
| Time to production-quality agent | Months to quarters | Weeks to months |
What the Industry Still Gets Wrong
The shift to LLM-based agents happened fast, and many teams carried over assumptions from the old world that no longer apply. Some of the most common mistakes:
Over-prompting
Teams accustomed to writing detailed rules often create enormous system prompts with instructions for every conceivable situation. This backfires. LLMs handle extremely long prompts with diminishing reliability. Instructions at the top of a 5,000-word prompt are followed more consistently than instructions at the bottom. Contradictory instructions (which become more likely as prompts grow) create unpredictable behavior.
The fix is concision. Focus the prompt on the most important behaviors and boundaries. Use the knowledge base for factual content. Use tool descriptions for action guidance. The prompt should define personality and judgment, not serve as an encyclopedia.
Treating the knowledge base as an afterthought
Many teams invest heavily in prompt engineering but neglect the knowledge base. This is backwards for most use cases. The prompt tells the agent how to behave. The knowledge base tells it what to say. If the knowledge base is incomplete, poorly organized, or outdated, the agent will hallucinate to fill the gaps, and no amount of prompt tuning will fix that.
Skipping systematic evaluation
In the old world, testing was straightforward: did the right intent fire? In the new world, evaluating a generated response is subjective and multi-dimensional. Many teams deploy prompt changes based on gut feel or a handful of manual tests. This leads to regressions that only become visible when customers complain.
Automated scenario testing with consistent evaluation criteria is not optional for production agents. It is the only way to maintain quality as the system evolves.
Confusing capability with reliability
LLMs are remarkably capable. In a demo, they can handle complex conversations, switch topics gracefully, and generate impressively natural responses. This capability creates a false sense of confidence. In production, at scale, the edge cases accumulate. The agent that handled your demo conversation perfectly will eventually encounter a situation where it hallucinates, goes off-script, or makes an inappropriate commitment.
Building a reliable production agent means accepting that capability and reliability are different things, and investing the effort to close the gap through testing, monitoring, and guardrails.
Ignoring the human-AI handoff
Many teams focus exclusively on the AI agent and treat escalation to a human as a failure condition. In reality, the handoff is a critical part of the system. When should the agent escalate? What context should it pass to the human? How does it explain the transition to the customer?
Designing the escalation experience is part of agent training. A graceful handoff that provides the human agent with full conversation context is worth more than an AI that stubbornly tries to handle every situation itself.
What Works in Production: Practical Patterns
After watching dozens of teams build and deploy LLM agents, certain patterns consistently produce better results:
Start narrow, then expand. Deploy the agent for a single, well-defined use case first. Get that working reliably before expanding to additional scenarios. Each new use case introduces complexity, and it is easier to manage that complexity incrementally.
Invest in the knowledge base early. Before writing a single prompt, audit the documentation the agent will need. Is it complete? Is it current? Is it structured for retrieval? A strong knowledge base makes everything else easier.
Write prompts for the worst case, not the best case. Your prompt needs to handle the angry customer, the confused customer, the customer who asks something completely unrelated, and the customer who tries to manipulate the agent. If the prompt only works for cooperative, straightforward conversations, it is not ready for production.
Test with adversarial scenarios. Include scenarios designed to break the agent: ambiguous requests, contradictory information, requests for things the agent should not do, rapid topic changes. If the agent handles adversarial scenarios gracefully, it will handle normal ones easily.
Monitor after deployment. Production traffic always includes situations you did not anticipate. Continuous monitoring surfaces issues quickly, before they affect large numbers of customers. Build a feedback loop from monitoring data back to prompt and knowledge base improvements.
Version everything. Prompts, knowledge base documents, tool configurations, and evaluation criteria should all be versioned. When something goes wrong (and it will), you need to know what changed and the ability to roll back.
The Skills That Matter Now
The shift from rule-based to LLM-based agent development changed the skills that matter.
Conversation design is still valuable, but different. Understanding how conversations flow, where they break down, and what makes a good customer experience remains important. But the expression of that understanding shifted from decision trees to prompts and evaluation criteria.
Writing skill became critical. The quality of an LLM agent is directly related to the quality of its prompt and knowledge base, which are written in natural language. People who write clearly, concisely, and with attention to edge cases produce better agents.
Data analysis matters more. Improving an LLM agent requires analyzing conversation data to identify patterns: where does the agent go wrong, which topics generate the most issues, which prompt changes actually improved things. Comfort with data is essential.
Evaluation design is a new discipline. Defining what "good" looks like for an LLM agent, and building systems to measure it consistently, is a distinct skill that did not exist in the rule-based world. It draws from product management, quality assurance, and assessment design.
Tool and API design experience helps. Because LLM agents take actions through tools, the ability to design clean, well-documented APIs that an LLM can use effectively is directly relevant to agent quality.
Where This Goes Next
The discipline of LLM agent training is still young. A few directions are becoming clear.
Prompts will become more structured and modular. Instead of monolithic system prompts, teams are moving toward composable prompt systems where different modules handle different aspects of behavior. This makes prompts easier to maintain, test, and share across agents.
Evaluation will become more sophisticated. Simple pass/fail tests will give way to multi-dimensional evaluation frameworks that assess accuracy, tone, policy compliance, efficiency, and customer experience simultaneously. AI-powered evaluation will reduce the human effort required.
Knowledge management will professionalize. As teams realize that knowledge base quality is the primary determinant of agent accuracy, dedicated roles and tools for knowledge management will emerge. This is already happening at larger organizations.
The line between "training" and "operating" will blur. In the old world, training and deployment were distinct phases. With LLMs, the agent is continuously evolving: prompts change, knowledge bases update, tools are added. The concept of a "trained" agent that ships and does not change is disappearing.
None of this means the new approach is easy. LLM-based agents are faster to build than rule-based ones, but getting them to production quality still requires significant effort, skill, and iteration. The effort just looks different than it used to.
The teams that succeed will be the ones that recognize this is a new discipline with its own best practices, not just the old discipline with a better language model underneath.
Build agents the new way
Chanl gives you prompt management, knowledge base tooling, scenario testing, and production monitoring in one platform. Everything you need to train and operate LLM-powered agents.
Start BuildingCo-founder
Building the platform for AI agents at Chanl — tools, testing, and observability for customer experience.
Aprende IA Agéntica
Una lección por semana: técnicas prácticas para construir, probar y lanzar agentes IA. Desde ingeniería de prompts hasta monitoreo en producción. Aprende haciendo.
