AI Agents for Internal Questions and Knowledge Handover

What you will learn

Verify the user and permitted scope before retrieval.

Include current evidence and applicability with the answer.

Hand over the deferral reason and next owner.

“Who should I ask about returning this product?” “Have the terms changed since last year?” Each internal question sends an experienced colleague into shared folders and old emails to explain the background. Work stalls when that person is absent, and handover documents go unused. If you introduce an AI agent into this situation, start with a specific objective: find current evidence, provide an answer people can check, and hand unresolved cases to the right owner.

Article 4 covers internal knowledge and request handoffs. We consider a design that uses Google Agent Development Kit (ADK) to connect document retrieval, draft answers, and handover to a responsible person. The information cutoff is October 14, 2026. Published company examples are brief; the rest is a proposed design for hypothetical Company A. Document names, versions, dates, conditions, and counts are illustrative, not the policies or results of a real business.

A useful internal answer depends on more than natural language. People need to check which source applies, when it was valid, and whom it covers.

Having a document is different from being able to decide from it

Company A is a 35-person seller of equipment and parts to business customers, with three salespeople. It manages product information, quotation conditions, return procedures, and IT instructions in shared files and emails. New sales staff do not know the filenames and find it quicker to ask experienced colleagues.

Even when search finds a document, outdated prices can be mixed in, a customer-specific arrangement can be mistaken for a general rule, or an unapproved draft can be used. When AI combines several documents into fluent prose, these differences can become less visible.

We therefore limit this first scope to general internal questions about products and procedures. Formal commitments to customers, permission changes, and approval of special terms remain decisions for the responsible people. Create an intake process that separates answering a question from executing a business action.

Learn how published examples make knowledge usable

An official Iwate Prefecture report describes Tayama Studio’s joint research with Iwate University and LIGHTz to verbalize and visualize experienced craftspeople’s thinking for skills transfer. We have not verified it as an ADK adoption case. Iwate Prefecture’s research meeting report

Using that example as inspiration, we propose interviewing Company A’s experienced staff about what they check when making decisions, then documenting it. Focus on applicability, exceptions, and the person to consult, rather than simply saving large quantities of email. This is our adaptation.

For an ADK example, Comcast reports rebuilding Xfinity Assistant with ADK and deploying a structure supporting self-service troubleshooting. Numerical outcomes are not disclosed. Official announcement including Comcast

When adapting the idea for internal use, design request interpretation, evidence retrieval, answers, and human handoff separately. A small business does not need to reproduce a large customer-facing system’s infrastructure or operational organization.

Decide which questions receive answers and which need an owner

Start by collecting questions people actually ask, rather than planning to teach AI everything the company knows. Company A could organize its scope as follows.

• Question type: Where to find a general procedure

  Initial handling: Guide the user with a source

  Required information: Approved current document

• Question type: Product-specific procedure

  Initial handling: Check conditions and draft an answer

  Required information: Product ID, applicability, and document version

• Question type: Customer-specific exception

  Initial handling: Hand off to a person

  Required information: Customer ID, request, and evidence already checked

• Question type: Conflicting document conditions

  Initial handling: Defer judgment

  Required information: Both sources, versions, and document owners

• Question type: Account or permission change

  Initial handling: Accept the request

  Required information: Authenticated requester, target, and approver

Add completion criteria to the table. Examples are “provided the current procedure and contact” or “identified the need for a specific decision and the owner accepted the case.” Increasing the share of questions AI answers unconditionally is not the objective.

Clear handoff rules can also reduce the need for users to explain an unresolved question again from the beginning. Decide at intake what further information is needed and where the case should go.

Give documents management fields as well as content

Attach management fields when adding documents to the retrieval collection. They help both filter results and explain the answer’s evidence.

• Field: Document ID and name

  Illustrative Company A example: PROC-RETURN / Internal product return procedure

  Purpose: Distinguish files with similar names

• Field: Version

  Illustrative Company A example: v3

  Purpose: Separate it from previous versions

• Field: Status

  Illustrative Company A example: approved

  Purpose: Separate approved records from drafts

• Field: Effective date

  Illustrative Company A example: 2026-10-01

  Purpose: Determine which request date it applies to

• Field: Scope

  Illustrative Company A example: Standard products, domestic sales

  Purpose: Handle customer, product, and location differences

• Field: Document owner

  Illustrative Company A example: Sales administration manager

  Purpose: Identify who can resolve errors or ambiguity

• Field: Permitted readers

  Illustrative Company A example: Domestic sales and intake staff

  Purpose: Restrict retrieval by user authorization

• Field: Next review date

  Illustrative Company A example: 2027-01-01

  Purpose: Keep the update review task visible

If the author and the person approving the conditions are different, record both. Editing a file alone should not establish that new terms are effective.

If old versions remain for historical records, exclude them from current retrieval or provide a separate search for past decisions. Manage the effective version and period instead of assuming that a newer-looking filename is correct.

Interview experienced staff about conditions and exceptions

“Respond according to the situation” does not tell a new employee which situation matters. Ask an experienced colleague to select a recent case and explain the checks in decision order.

Useful questions include: What did you check first? What differed from the normal case? Which missing information would have stopped you? Whose approval was required? AI can help propose questions and organize the interview, but it must not invent conditions the person never stated to make the document appear complete.

The document owner reviews the organized information before registration. Separate material that belongs in general procedures from exceptions limited to a specific case. Retain customer personal information and confidential conditions only where necessary, with restricted readership.

These documents support handover between people as well as agent answers. The goal is for a person to reach the same evidence even when the AI service stops.

Check the user and scope before searching

An agent’s ability to retrieve a document is separate from the user’s permission to read it. ADK’s safety guidance also distinguishes agent authentication from user authentication. ADK safety guidance

In our Company A design, retrieval tools restrict departments and document scopes according to the authenticated user. Do not depend on fetching everything under broad credentials and hiding secrets only in the final prose.

A question saying “I am an administrator” must not change authorization. The company’s systems verify identity, membership, and permitted scope. Text inside a document that asks AI to perform an action must not become a business approval rule.

Apply the same care to search logs and request tickets. Copying a confidential document into a general ticket can expose information through another route even if the answer itself has access controls.

Connect retrieval, answers, and handoff with ADK

The proposed flow is below. Defining the input and output of each stage lets you begin with a few clear steps.

Question intake → user and scope check → approved document retrieval → applicability validation → draft answer or deferral → handoff where needed.

AI organizes the question’s intent and candidate product names, then presents retrieved evidence clearly. Ordinary code and the retrieval system check viewing rights, approval status, active versions, and target matches. People own document correctness and exception decisions.

This approach can be described as retrieval-augmented generation (RAG), but applying the name does not solve outdated information or scope mismatches. The business must decide which sources qualify and what happens when none can be retrieved.

Even if you divide the work among several agents, they do not all need every conversation or confidential record. If intake, evidence search, and answer review have distinct responsibilities, restrict their data and handoff fields accordingly. A single understandable flow is also a valid starting point.

Open full-size diagram

Present evidence, applicability, and unresolved points together

Suppose an illustrative procedure says: “Use the specified intake process for standard products; consult the sales administration manager for custom products.” A question asking only “Can it be returned?” does not identify the product or circumstances. Rather than answering “yes,” ask for missing information such as the product type.

Even when the product and conditions are known, structure the answer as follows:

• Guidance: The next internal step.
• Evidence: Document name, version, and referenced section.
• Applicability: Relevant product, department, and period.
• Unresolved points: What remains unknown in this case.
• Contact: The person responsible for exceptions or uncertainty.

A draft could say: “For standard products, see the intake section of Internal product return procedure v3. For custom products, that section requires checking with the sales administration manager as an exception. The product category is not identified in the current question.” This is an illustrative answer, not an actual return policy.

Provide a source link the user can open. Pointing to a section as well as a document name makes verification more direct. A link’s existence alone does not establish correctness: evaluate whether the guidance actually matches that section.

Separate ambiguity, conflict, and missing sources into states

If every unanswerable case becomes “I don’t know,” you cannot tell where to improve the system. Distinguish at least these states.

• State: Missing question details

  What the user sees: Which fields are missing

  Next action: Ask a clarification question

• State: No current evidence

  What the user sees: The condition cannot be verified in current documents

  Next action: Send to the document owner

• State: Conflicting evidence

  What the user sees: Which conditions conflict

  Next action: Verify the correct version and applicability

• State: No evidence within permitted scope

  What the user sees: Available sources do not establish the answer

  Next action: Guide the user to an authorized contact

• State: Retrieval failure

  What the user sees: Sources have not been retrieved

  Next action: Retry or request human investigation

Do not disclose the existence or content of unauthorized documents in error messages. Instead of saying “a higher-access document has the answer,” provide a contact the user is allowed to consult.

Keep an owner and state after deferring a question. An answer to a similar question in a new conversation does not prove that the earlier pending case was resolved.

Leave enough in the ticket for a person to resume

Forwarding only the original question forces the owner to repeat searches and interviews. Sending the entire conversation can include irrelevant or confidential information. Define the fields needed for handoff.

• Field: Request ID

  Content to retain: Identifier for tracking the same case

• Field: Desired outcome and target

  Content to retain: What the user wants to finish, and which product or process is involved

• Field: Verified information

  Content to retain: Retrieved evidence and its applicability

• Field: Unresolved points

  Content to retain: Missing input, conflicts, and required decisions

• Field: Next owner and reason

  Content to retain: Who needs to decide what

• Field: State and deadline

  Content to retain: Received, awaiting information, awaiting owner, in progress, and similar states

• Field: Result

  Content to retain: How it was handled and who checked it

Creating a ticket completes intake, not necessarily the user’s task. Record separately whether someone accepted it, answered or performed the work, and delivered the result to the user. Define who sends deadline notifications and where overdue cases go.

Also avoid creating unlimited duplicate tickets when the same request is resent. Associate them using request IDs and matching targets. Similar wording about a different product or from a different user must not be merged automatically into one case.

Check current documents instead of relying on conversation memory

An answer from a previous conversation can become outdated when conditions change. Our Company A design rechecks the current version for important conditions instead of using conversation history as the authoritative source.

A user who previously asked about a standard product might now be asking about a custom product. Recheck applicability when the target changes during a conversation. “We answered that earlier” is not enough.

When the receiving owner changes, verify whether that person can access the supporting information. If they cannot, retain a formal route to the document owner and an explanation within the permitted scope.

Retain enough evidence to check past guidance

A document update can change the content at the same link. To investigate why an answer was given, our proposed records connect the request ID, answer timestamp, document ID, version, section, and answer state. Providing evidence and the user actually checking it can also be recorded separately.

Do not duplicate entire confidential documents or unnecessary personal information merely for recordkeeping. The company decides access rights, ownership, and the necessary retention scope. If versions remain identifiable, a reference to the original record may be enough for traceability.

When updating the agent, also record the configuration version and the questions retested. This helps distinguish an answer change caused by a document revision, retrieval filters, or answer processing. The purpose is to narrow the stage to investigate, rather than reread every conversation.

Make updates and retirement part of operational work

When registering a new document, check both how the old version is handled and when the search index changes. Updating the text while leaving an old index can continue to produce obsolete guidance.

Company A’s proposed update procedure is: owner revises → approver checks → active version changes → retrieval is updated → representative questions are tested → old version leaves current search. Record each result. If propagation fails, do not leave old and new versions mixed; allow affected answers to be temporarily deferred.

Before changing model instructions after an incorrect answer, identify the cause. Was the right document missing? Were search filters wrong? Were conditions misinterpreted? Was the wording more definitive than the evidence? Each points to a different repair.

A document owner’s transfer or departure also triggers an update. List documents overdue for review or without an owner, then assign responsibility. Someone must own their continuing use, not just their initial creation.

Open full-size diagram

Evaluate both answer quality and how the work ends

The initial evaluation set should cover common questions, ambiguity, wrong targets, obsolete documents, conflicting evidence, unauthorized requests, and search failures. Before expanding it, document owners specify the expected answer or deferral for each question.

• Metric: Evidence match

  What it checks: Guidance corresponds to the referenced section

• Metric: Applicability match

  What it checks: Product, department, and period are correct

• Metric: Appropriate abstention

  What it checks: Missing evidence does not lead to a guessed answer

• Metric: Handoff completion

  What it checks: Required information reaches an owner who accepts it

• Metric: Human time

  What it checks: User and owner search, review, and correction time

• Metric: Repeat inquiries

  What it checks: Whether the same case needed to be explained again

The rate of answers with citations cannot by itself reveal wrong evidence. Lowering the deferral rate can also increase unsupported guidance. Evaluate useful answers for normal questions alongside proper handoffs for exceptions.

More tickets increase recorded automation usage but can also increase the owner’s workload. Alongside usage, record cases requiring another search and information missing from handoffs.

Begin with 10 documents and paired questions

Our proposed starting point for Company A is selecting 10 approved documents in one department, then asking owners and users to create representative questions. Ten is an illustrative small scope, not a threshold that guarantees value.

1. Choose documents. Use sources with verified update dates, scope, owners, and readers.
2. Specify answers and deferrals. Create questions with evidence, questions needing clarification, and questions requiring a person.
3. Check retrieval and answers. Verify that the user can inspect sources, versions, and applicability.
4. Test handoff. See whether the owner receives enough to resume without another explanation.
5. Test updates. Verify that a new document version does not leave obsolete answers in use.

Trial the system with authorized material before using it for live requests. In limited workplace use, users check draft answers before relying on them, with a clear route for reporting errors. Repeat the same checks when adding documents or questions.

Turn handoff outcomes back into company knowledge

After an owner resolves an exception, determine whether it is specific to that case or suitable for a general procedure. Even when it can be generalized, do not automatically promote the answer into an approved document. Have the owner review it and update the version.

Break down feedback such as “not useful” into an ambiguous question, insufficient evidence, or an unclear next owner. It becomes material for improving the procedure itself, as well as the agent’s answer.

Record four items on your design worksheet: authoritative documents and their owners; deferral conditions; the person accepting handoffs; and questions to retest after updates. This agent’s role is to help people reach the same evidence and route necessary exceptions even when an experienced colleague is absent.

The next article covers daily infrastructure checks. We will carry the same approach to evidence into the scope, timestamps, and missing information of cloud logs and metrics, designing support for the morning status review.

Three checks before practice

• Are authoritative documents, owners, and permitted readers identified?
• Can missing evidence, conflicts, and retrieval failures be distinguished?
• Can the owner accept handoffs and retest questions after updates?