AI Agent Knowledge Gaps: How to Log Unanswered Questions

An AI agent knowledge gap is a question from a customer or staff member that the agent cannot answer correctly from its memory, documents or tools. You find these gaps by logging every unanswered or escalated question with the same fields each time, then grouping the entries by cause so each cluster becomes a documentation fix, a memory entry, a tool change or a rule for handing off to a person. Logged this way, the gaps become a ranked list you can act on, instead of a general feeling that the agent is not good enough.

Key takeaways

• A knowledge gap is a question the agent could not answer correctly. A wrong answer is a separate problem and needs its own log entry.
• Record the question, the context, what the agent did and how the question was finally resolved, using the same fields every time.
• Group entries by cause (missing document, outdated fact, retrieval miss, missing tool, unclear policy) before deciding what to change.
• Rank each cluster by how often it appears, what a wrong answer costs and how much effort the fix takes, then give it one owner and a re-test date.
• Close the loop by checking that the next similar question gets a correct answer with a visible source.

What counts as a knowledge gap?

A gap is any question where the agent should have had an answer and did not. That includes a plain refusal such as "I don't have that information," a vague answer that leaves the person stuck, and a handoff to a human when the answer should have been available. Be careful with two neighboring categories. A wrong answer is more serious than a gap because someone may act on it, so log it separately with the answer that was given. A boundary is a question the agent should not answer, such as a refund above a set limit or a clinical judgment, and the correct behavior is to hand it to a person. Boundaries still belong in the log, because they tell you which rules are working and which requests keep arriving at the wrong place.

Staff questions matter as much as customer questions. An internal team member who asks the agent about a warranty exception, a holiday schedule or the approved wording for a delay notice is showing you a gap in the company's shared knowledge. Many of these questions never reach a support queue. They appear in chat, get a weak answer and are forgotten.

Illustrative scenario: a small equipment rental company gives its agent access to the rate sheet, the return policy and the booking calendar. Over one week, staff ask the agent several questions about late return fees for multi-day rentals. The rate sheet covers daily rates but says nothing about fees, so the agent guesses or escalates. Without a log, the team hears only that the agent is unreliable. With a log, the team sees one repeated gap with a clear cause.

Which fields should every log entry have?

The log is only useful if entries are comparable. A spreadsheet or a simple table in your ticketing tool is enough to start. Each entry should contain the following fields:

• The question as asked, with personal details removed or replaced by a label.
• The channel and the role of the person asking, such as customer, technician, manager or front desk.
• The topic or business area the question belongs to.
• What the agent returned: refusal, wrong answer, partial answer, or handoff.
• Which sources or tools the agent used, if any, and whether it had access to the right ones.
• How a person resolved the question, and where the correct answer was found.
• An initial cause guess, marked as a guess, to be confirmed during review.
• The date of the entry and an owner for follow-up.

Do not paste full customer records into the log. Store the minimum needed to reproduce the question. If a question contains health, financial or identity details, keep the category and omit the detail. The sensitive data in AI agent memory guidance applies to logs as well as to memory, because logs are also stored data.

How do you start logging without building a large system?

Start with a short, time-limited capture period and a clear rule for what gets logged. A team that tries to log everything usually stops within a week. A team that logs only unresolved questions and handoffs can keep going.

• Step one: choose one channel or one agent role where the questions already reach a person, such as the support inbox or the operations chat.
• Step two: agree on the trigger. Log every refusal, every handoff caused by missing information, and every answer that a staff member corrects.
• Step three: assign one person to own the log for the capture period. This person does not need to answer every question, but must make sure entries are complete.
• Step four: add the fields from the previous section and test them on ten real entries. Remove fields nobody fills in and add any field that would have helped you find the answer.
• Step five: review the log at a fixed time each week. Read the new entries, mark duplicates, and note the first suspected cause for each new pattern.
• Step six: after the capture period, decide which clusters are worth fixing and which should stay as known limits.

The [observability guidance from OpenTelemetry](https://opentelemetry.io/docs/concepts/observability-primer/) describes the same discipline in engineering terms: collect consistent signals with enough context to explain what happened. A knowledge gap log is a simpler, business-facing version of that idea.

How do you group gaps by cause?

Grouping is where the list becomes useful. Two questions with the same wording may have different causes, and two questions with different wording may share one. Sort each entry into one primary cause:

• Missing source: the answer exists in a person's head or in an informal channel, but was never written down. The fix is to capture the knowledge and review it before the agent uses it.
• Outdated source: the answer was written but has since changed. The fix is to update the document, retire the old version and make sure the agent cites the current one.
• Retrieval miss: the answer exists in a document the agent could access, but the agent did not find it. The fix may be clearer titles, better chunking or a retrieval test, not new content.
• Missing tool or permission: the answer needs a live system, such as an order status or a schedule, and the agent has no access or no approved route to it. The fix requires a decision about access, which should go through a permission review.
• Unclear policy: the answer depends on a judgment that the company has never made. The fix is a decision by the responsible manager, not a guess written into the agent's memory.
• Out of scope: the question should never reach the agent. The fix is routing, not content.

The retrieval quality test process helps separate the retrieval miss from the missing source. Ask whether the answer exists in a document the agent can read, then ask whether the agent retrieves it for that exact wording. Only after that does it make sense to write new documentation.

How do you turn clusters into a ranked list?

Once each entry has a cause, score the clusters. Keep the scoring simple enough that a manager can apply it in twenty minutes. Three criteria are usually enough: how often the cluster appears in the capture period, what a wrong or missing answer costs the business, and how much effort the fix requires. Frequency alone can mislead, because a rare question about refunds may matter more than a common question about opening hours.

The decision guide below turns each cause into the next action:

• If the cause is a missing or outdated source, write or update the document, assign an owner and set a review date.
• If the cause is a retrieval miss, run a retrieval test with the exact question wording and fix titles or structure before adding content.
• If the cause is a missing tool or permission, prepare an access request with the approval boundary stated, and do not grant access inside the agent's conversation.
• If the cause is an unclear policy, send the question to the decision owner and leave the agent on a handoff until the answer is recorded.
• If the cause is out of scope, change the routing so people are not sent to the agent for that request.

Each ranked item needs one owner and one re-test date. Without an owner, the list becomes a document nobody reads. Without a re-test date, nobody can tell whether a fix worked.

How do you confirm that a gap is closed?

A gap is closed only when the same kind of question gets a correct answer, with a source a staff member can check. Take the questions from the cluster and keep them as a small test set. Include the original wording, two or three variants and at least one question that should still be refused. After each fix, run the set and record the result. The [Anthropic guidance on evals for AI agents](https://www.anthropic.com/engineering/demystifying-evals-for-ai-agents) describes this pattern of building task sets from real failures and rerunning them after changes, which is the habit a gap log needs.

Keep the test set. Gaps tend to return after documents change, tools are updated or a new staff member asks a question in a different way. A small, repeatable set is the cheapest early warning you can have.

How does Be Human's managed approach handle this?

Be Human designs the log as part of the first engagement, starting with one agent role and its expected questions, so the fields match the work the agent actually does. In managed operations, the log feeds recurring evaluations, where clusters are reviewed and ranked with the business owner. Documentation changes, memory updates and tool changes are handled as controlled improvements, each with an approval boundary, and permission reviews check whether the agent should have access to the sources behind a fix. Be Human's job is to keep the list current and the changes traceable, while the decisions about policy stay with the people responsible for them.

Keeping the log useful over time

Review the log on a fixed schedule. Weekly review works well during the first month, then a monthly review is usually enough once the top clusters are closed. Archive closed clusters with the date and the evidence, so you can explain later why a rule or document exists. The [NIST AI Risk Management Framework](https://www.nist.gov/itl/ai-risk-management-framework) treats risk management as continuing work across the life of a system, and a gap log is one practical way to keep that work visible. If your agent has a job that matters, the first useful task to hand to it is often the one your log has already marked as recurring. To find that task, take the free Be Human AI diagnostic.

Frequently asked questions

What is the difference between a knowledge gap and a wrong answer? A knowledge gap is a question the agent could not answer correctly, usually because it refused, escalated or gave a partial answer without a source. A wrong answer is one the agent gave confidently and incorrectly, which can cause real harm because people may act on it. Log wrong answers separately, with the answer that was given, and review them first.

How many questions do I need to log before the list is useful? You do not need a large sample to see the first patterns, but you do need enough to avoid guessing. Run a short capture period on one channel and one agent role, then review the entries together. Once the same cause appears more than once, you have a cluster worth examining, even if the total volume is still small.

Should the agent learn from the gaps automatically? No. Gaps should be reviewed before any answer becomes memory or documentation, because a wrong fact stored as memory can be repeated for months. Staff should confirm the correct answer, name its source and set a review date. Only then should the agent use it, and the change should be recorded.

Who should own the knowledge gap log? One named person should own the log, usually an operations lead or a manager who can approve documentation changes. Other staff can add entries, but the owner keeps the fields complete, runs the weekly review and assigns each cluster to someone who can fix it. Without a single owner, the log fills up and no cluster is ever closed.

Be Human editorial guidance. Examples are illustrative unless explicitly attributed. Sources provide background; implementation choices depend on your workflow.