Maintain an AI support agent and add safe self-learning
The short answer
Improving an AI support agent is a controlled change process. Review failures, find the cause, propose a correction, test it and publish it as a new version. Self-learning can help you find candidate improvements faster, but human replies and customer outcomes need a policy check before they shape future answers.
Review causes before writing new guidance
When an answer goes wrong, the quickest-looking fix is usually to add another line of guidance. That often treats a symptom and leaves the cause in place. Start each week by sampling conversations across the full range of outcomes: successful, escalated, reopened and low-scoring. Include different intents, languages and channels, so one busy topic doesn’t crowd out the rest. When you review each conversation, look at the evidence the agent had at the time, not only what the team learned later.
Then classify the cause. The usual categories are missing or stale knowledge, a retrieval failure (the right source existed but wasn’t found), the wrong task selected, confusing guidance, denied tool access, a tool error, a delivery failure, or a measurement error where the conversation was actually fine but was scored wrongly. Send each correction to the owner of that component. A source problem needs a source correction, and an expired credential needs operational repair. Neither is fixed by changing the prompt.
For each confirmed issue, record the evidence, the cause, the owner, the proposed change and a regression case, a test conversation that fails today and should pass once the fix is in. The following week, check whether the released fix actually solved the original cases. A fix that passes its new test but leaves the real conversations unchanged usually means the cause was misdiagnosed.
Turn an escalation into a candidate learning
Escalated conversations are a useful source of improvements, because a human has already shown what a better reply looked like. Compare the AI’s answer with the human replies that followed and find the smallest useful difference. Was it a missing fact, a better procedure, a clearer way of explaining, or a policy exception? Treat that difference as evidence to examine, not as automatic ground truth, because a human reply can be a one-off judgment call or simply wrong.
Capture each possible improvement as a learning record: the proposed statement, the scope it applies to, a reference to the source conversation, the policy that supports it, the owner, its review state and an expiry or review date. Remove personal details and account-specific concessions before you generalize anything. Check for an existing article or rule first, so a run of similar cases doesn’t create several conflicting versions of the same answer. If the human never followed up, there’s nothing to learn from, and no record should be created.
My AskAI’s public self-learning documentation describes this kind of comparison between AI and human replies to identify gaps. This guide uses that product pattern as an example. It doesn’t reproduce the private implementation, and it doesn’t suggest that every observed difference should be published.
Decide what to do with the difference
Most differences between the AI’s answer and the human’s fall into a handful of patterns, and each one calls for a different response. Only the first leads straight to new knowledge.
| Observed difference | Decision | Reason |
|---|---|---|
| The human cites a current policy that’s missing from the index | Update the approved source or add a reviewed answer | The fact has a policy owner and a valid scope |
| The human makes a one-off concession | Reject it as general learning, and keep the case context if your policy allows | An exception doesn’t change policy |
| The human corrects a wrong tool result | Investigate the API or adapter | New prompt text won’t repair bad data |
| The human asks a question the agent skipped before acting | Propose a task change and add selection tests | The procedure may be incomplete |
| The human gives an answer no source supports | Don’t learn it automatically | Human replies can be wrong too |
Publish learning through the normal release path
An approved learning is a change to what your agent will tell customers, so it should go through the same release path as any other configuration edit. Show the reviewer a diff of exactly what changes, test the questions it affects and get the level of review your policy requires. After publishing, confirm that the search index has picked up the new version and that the agent actually uses it on a test question. Keep a way to correct, unpublish or remove a learning, and set an expiry or review date for anything tied to a temporary policy, such as a holiday returns window.
For many teams, automated learning is a later step. A weekly manual review can use the same evidence and controls with far less engineering, and it’s enough for a first release. Add automation once candidate quality, the review workload and a measurable benefit justify it. If you let some learnings apply automatically, limit that to a clearly defined low-risk scope and monitor the outcomes closely.
Give the monthly review a decision to make
The weekly review fixes individual failures. The monthly review looks at the platform underneath. Review promising new model and retrieval options, upcoming version deprecations and changes to provider terms. Run a small screening set first, and spend time on a larger comparison only for candidates that pass it. Keep your current configuration unless a candidate meets the agreed quality, safety, cost and latency criteria. Switching models is optional, and “newer” isn’t a reason on its own.
Use the same meeting for routine security and measurement checks: dependencies, permissions, credentials, data retention settings and your prompt-injection test cases. Review judge calibration and metric denominators too, so a reported improvement still means what it meant last month. The calendar is for routine work only. An urgent security fix follows your incident process and doesn’t wait for the next monthly meeting.
Retire work as well as adding it
Agents grow by accumulation. Each new rule, task and tool adds tests to run and behavior to keep consistent, and the business keeps changing underneath them. Set time aside to remove obsolete sources, duplicate rules, unused tools and procedures the business no longer supports. Keep a change log of what you removed and why, and run removal tests to show that no required flow was lost.
Once a quarter, revisit the economics using the time you actually spent on engineering, support review and incidents, not just the model bill. You may find that some parts of your agent are distinctive to your business and worth owning, while others are general plumbing you could buy as a managed service. Make that call from observed outcomes and real ownership costs rather than token price alone, and keep your export and migration options open either way.
Ask AI to explain this guide
Build decisions and checks
Use these decisions to turn the worked case into your own implementation. A check is complete only when you have evidence for the stated result.
Review failures by cause
Required. Changing a prompt won't fix stale knowledge or a failed API permission check.
Build. Sample successful, transferred, reopened and low-scoring conversations. Sort the causes into knowledge gaps, unclear policies, retrieval misses, task errors, tool failures, integration errors and measurement errors. Assign each fix to the right owner.
Check. Every issue has evidence, a proposed change and a test that can show improvement.
Turn escalations into candidate learnings
Later. A human's answer can contain a useful fact, a one-off exception or a mistake.
Build. Compare the customer's request, the AI answer and the human's eventual resolution. Pull out possible reusable knowledge gaps. Strip personal details and account-specific concessions. Keep a link to the source conversation, the policy owner and the evidence behind your confidence.
Check. A one-off goodwill refund doesn't become a general refund rule. If no human followed up, no learning is created.
Review, publish and retract learning safely
Later. Publishing automatically can turn one mistake into an answer the agent keeps repeating.
Build. Deduplicate candidates, check for contradictions and apply the review level you've chosen. Version approved knowledge. Retest affected questions, confirm search returns the new content, then monitor outcomes. Support correcting, unpublishing and removing items from the index, through the same controlled release path as other configuration edits. For a first release, manual review of failures is enough; automated learning can come later when volume and evidence justify it.
Check. An approved learning changes the intended answer. A rejected or removed learning can't be retrieved.
Evaluate models and maintain security
Required. Provider changes, new attack methods and dependency bugs keep arriving after launch.
Build. Keep a watchlist of changes. For worthwhile candidates, run a small compatibility check, then offline evaluation, then a limited rollout. Review access, dependency updates, injection tests and data terms. Switching models is optional; security work follows risk.
Check. A candidate improves the agreed outcomes without breaking safety or cost limits. Urgent fixes don't wait for the monthly meeting.
Retire complexity and revisit build versus buy
Required. Unused tasks and overlapping rules add maintenance while the business keeps changing.
Build. Remove obsolete content, tools and rules. Reassess ownership, support demand and total cost. Keep export and migration options open. Compare building in-house, buying a service and a hybrid approach against the same outcome requirements.
Check. The inventory has owners and review dates. Removal tests show no required flow is lost.
Ask AI to apply these decisions
Templates and examples
Every file uses synthetic data. Adapt it to your own policies and test it somewhere safe before it touches customers.
- learning-candidate.jsonJSON fixture or schema
- weekly-review.mdTemplate (Markdown or text)
- maintenance-calendar.csvSpreadsheet worksheet (CSV)
Keep it working
Launch is the start of the work, not the end. These are the recurring jobs this part of the agent needs, and who usually owns them.
| Cadence | Owner | Work |
|---|---|---|
| Weekly | Quality owner | Review the queue weekly, and check whether shipped fixes solved the original cases. |
| Weekly | Knowledge owner | Review candidates and patterns of disagreement. |
| Weekly | Knowledge owner | Review published changes and repeated failures. Audit where each learning came from and when it expires. |
| Monthly | Engineering | Review candidates and routine security work monthly. Act on critical incidents right away. |
| Quarterly | Service owner | Review service value and architecture every quarter. |
Test your decision
Three escalations contain the same one-off concession. Does repetition make it a valid policy?
Show the expected decision
No. Repetition is a reason to ask the policy owner, not a reason to publish. It may reveal an undocumented rule, or it may just mean several teammates are making the same exception. Publish only after the business confirms the intended scope and the change passes its tests.
