Knowledge Agents Need to Know and Think
A practical framework for building knowledge agents that know when to look up facts, when to apply expertise, and when to combine both
Not every question needs the same kind of AI agent. Some questions need a trusted answer from a knowledge base. Some need expert reasoning through a defined workflow. Many real-world use cases need both.
This is the idea behind retrieval, intent, or both. A knowledge agent should not treat every user request as a generic chat prompt. It should first understand what kind of work the request requires, then choose the right path.
What Is Retrieval?
Retrieval is the agent's ability to find relevant, trusted knowledge before answering. The knowledge might be hotel policies, product documentation, HR benefits, internal procedures, personal notes, cooking stories, or past decisions.
The goal is simple: do not make the LLM guess what the system already knows. Retrieve the right knowledge first, then use that knowledge to answer accurately.
Example: Hotel Guest Support
A guest asks, "What time is breakfast?" This is a retrieval problem. The agent should look up the hotel's breakfast policy and return the answer. It does not need a deep reasoning process. It needs the correct fact.
Example: Personal Cooking Memory
A friend asks, "What was that lamb dish Alex made at the spring dinner?" The agent should retrieve the relevant cooking story, menu note, or recipe memory. Again, the value is in trusted recall.
Retrieval is best when the answer already exists somewhere in the knowledge base and the main challenge is finding the right piece of information.
What Is Intent?
Intent is different. Intent is not mainly about finding a stored answer. It is about applying a structured expert workflow to a user request.
In an intent-based agent, the system captures how an expert would think through a use case. It may define the steps, criteria, constraints, inputs, outputs, risk checks, and expected structure of the response. The LLM still does the language and reasoning work, but it is guided by an expert pattern instead of starting from a blank prompt.
Example: Review a Report for Risk
A manager asks, "Review this vendor report and identify risks." The answer is probably not sitting in a knowledge base. The agent needs to follow a review framework: summarize the report, identify operational risks, financial risks, compliance risks, missing information, and recommended next steps.
Example: Plan a Dinner Menu
A guest says, "Plan a dinner menu for six people, one vegetarian, with a lighter summer feeling." The agent may retrieve past menus and cooking preferences, but the core task is creative planning. It needs an intent workflow for menu design: season, balance, dietary constraints, pacing, prep complexity, and storytelling.
Intent is best when the user needs judgment, transformation, review, planning, or decision support. The answer is created through a process, not simply retrieved.
Why Do We Need Both?
If an agent only has retrieval, it can answer known questions but struggles with complex tasks. It can tell you what the policy says, but it may not know how to evaluate a case.
If an agent only has intent, it can generate polished reasoning but may miss the facts that make the reasoning trustworthy. It can sound smart while being disconnected from the real domain.
Real knowledge work often requires both. The agent needs the facts, but it also needs a way to apply those facts.
Retrieval Only
"What is the late checkout policy?" The agent retrieves the policy and answers directly.
Intent Only
"Draft a decision memo from these notes." The agent follows a memo-writing workflow and produces a structured output.
Retrieval + Intent
"Can we approve late checkout for this VIP guest?" The agent retrieves the policy, checks guest context and room constraints, applies service rules, and recommends a response.
Business Example: HR Assistant
An employee asks, "How many vacation days do I have?" That is mostly retrieval. The agent needs the employee's policy, tenure, location, and company rules.
Another employee asks, "I am moving from California to New York. What should I consider for benefits and payroll?" Now the agent needs more than one fact. It must retrieve relevant policies, identify affected areas, explain likely changes, and recommend who to contact. This is retrieval plus intent.
A manager asks, "Help me compare two candidates based on interview notes." That is primarily intent. The system should follow a fair evaluation framework, avoid unsupported claims, separate evidence from opinion, and produce a consistent comparison.
Personal Example: Cooking Agent
A personal cooking agent can use retrieval to remember past dishes, guest preferences, stories, ingredients, and lessons learned. If someone asks, "What did we serve at the May dinner?" retrieval is enough.
But if the question is, "Design a new set menu for four guests, inspired by that May dinner but lighter and more seasonal," retrieval alone is not enough. The agent should retrieve the May dinner context, then apply a menu-design intent: theme, progression, contrast, dietary fit, prep timing, and emotional tone.
That is where the agent starts to feel less like search and more like a collaborator.
How We Can Make It Work
The architecture does not need to be complicated at first. The important part is to separate the types of knowledge and the types of work.
1. Structure Knowledge for Retrieval
First, collect the facts the agent should be able to trust. These can include FAQs, policies, documents, notes, stories, product details, and prior decisions.
Then shape the knowledge so it can be retrieved cleanly. A good retrieval item should usually have a clear title, question or topic, answer or content, source, tags, and update history. The goal is not to store everything randomly. The goal is to make the right knowledge easy to find.
2. Capture Expert Intent for Workflows
Next, define the use cases where the agent needs to do more than answer a known question. These become intent workflows.
An intent workflow might define the goal, required inputs, thinking steps, evaluation criteria, constraints, output format, and fallback behavior. For example, a "risk review" intent should know what kinds of risks to look for and how to present them. A "menu planning" intent should know how to balance dishes and constraints.
3. Route the User Request
When a user asks something, the agent should decide what path to use:
- Use retrieval when the user needs a known fact or trusted answer.
- Use intent when the user needs a structured task, review, plan, or decision.
- Use both when the task requires trusted context and expert processing.
Routing can start simple. The system can classify the request into a few known categories, retrieve relevant context if needed, select an intent if needed, then pass the right package to the LLM.
4. Give the LLM a Clear Job
The LLM should not receive a vague prompt like "answer the user." It should receive a clear job: use this retrieved knowledge, follow this intent workflow, respect these constraints, and return this kind of output.
This is how the system becomes more consistent. The model is still flexible, but it is no longer improvising the entire process.
5. Review and Improve from Real Usage
A knowledge agent improves as people use it. Retrieval misses show where the knowledge base is weak. Poor responses show where an intent workflow is vague. Repeated questions reveal which answers should become structured knowledge. Repeated tasks reveal which workflows should become reusable intents.
Closing
Retrieval, intent, or both is a simple way to think about knowledge agent design. Some requests need memory. Some need judgment. The best systems know the difference.
For i80agent, this distinction matters because a real domain is not just a pile of documents. It contains facts, rules, stories, decisions, workflows, and expertise. Retrieval helps the agent remember the domain. Intent helps the agent act within it.