Knowledge-Based Agents

Unit 6: Knowledge-Based Agents and Inference — Section 6.1

Suppose you need an AI assistant to help doctors decide which antibiotic to prescribe. You could hard-code every possible symptom-to-drug path as if/elif chains in Python — but then every time medical guidelines change you’d need to rewrite the code. A better approach is to separate the knowledge (the medical facts and rules) from the reasoning algorithm (the code that draws conclusions). That separation is the core idea of a knowledge-based agent.

What Is a Knowledge-Based Agent?

A knowledge-based agent maintains an internal repository of facts and rules — its knowledge base — and uses an inference engine to derive new facts and choose actions. The agent interacts with its knowledge base through exactly two operations: TELL and ASK.

Knowledge Base (KB): A set of sentences in a formal language (typically propositional or first-order logic) that represents facts and rules about the agent’s world. Every sentence added to the KB is assumed to be true.

Inference Engine: The domain-independent component of a knowledge-based agent that applies logical reasoning rules to derive new facts from existing ones. The same inference engine works regardless of what domain knowledge is stored in the KB.

This separation is what makes knowledge-based AI powerful. Add a new rule about drug interactions and the inference engine automatically incorporates it into every future query — no code changes needed. Swap the medical KB for a tax-law KB and the exact same reasoning algorithm applies.

The knowledge level describes what an agent knows (the sentences in its KB). The implementation level describes how that knowledge is stored and processed. Newell’s knowledge-level hypothesis (1982) argues that intelligent behavior can often be fully predicted from the knowledge level alone, without knowing the implementation details.

The Tell-Ask Interface

Every knowledge base exposes two fundamental operations:

TELL(KB, sentence) — adds a new sentence to the knowledge base. The sentence can be a simple fact, a rule (implication), a constraint, or any logical formula the knowledge representation language supports.

ASK(KB, query) — asks whether a sentence is entailed by the knowledge base. The inference engine examines everything stored in the KB and uses inference rules to determine whether the query must be true. Unlike a database lookup, ASK does not require the query to be stored explicitly — it can derive answers through chains of reasoning.

A Simple Weather Knowledge Base

TELL(KB, "raining")
TELL(KB, "IF raining THEN ground_wet")
TELL(KB, "IF ground_wet THEN slippery")
TELL(KB, "IF slippery THEN drive_carefully")

Now the agent can answer:

ASK(KB, "ground_wet")      → TRUE  (inferred from raining + rule 1)
ASK(KB, "drive_carefully") → TRUE  (inferred through chain: raining → wet → slippery → careful)
ASK(KB, "sunny")           → UNKNOWN (nothing entails sunny)

None of the last three answers were stored directly — they were all derived by the inference engine.

Declarative Knowledge: Knowledge expressed as statements about what is true, rather than how to compute something. Rules in a knowledge base are declarative: fever ∧ cough → flu states a fact about the world, not a sequence of instructions.

Declarative vs. Procedural Knowledge

Traditional programs embed knowledge as procedural code — a fixed sequence of steps that must be rewritten whenever the domain changes. Knowledge-based systems use declarative representation: the agent states what is true, and the inference engine handles the reasoning.

Declarative (Knowledge Base) Procedural (Traditional Code)

Declarative (Knowledge Base)	Procedural (Traditional Code)
`rain → wet` `wet → slippery`	`if rain: wet = True` ` if wet: slippery = True`
Same rules answer any query	Hard-coded for specific queries
Add new rule without changing reasoner	Must rewrite code for new conditions
Reasoning is transparent	Logic buried in control flow

rain → wet
wet → slippery

if rain: wet = True
` if wet: slippery = True`

Same rules answer any query

Hard-coded for specific queries

Add new rule without changing reasoner

Must rewrite code for new conditions

Reasoning is transparent

Logic buried in control flow

The declarative approach has a deep advantage: you can ask questions the original programmer never anticipated. Given the rules above, ASK(KB, "slippery") returns TRUE even if no programmer ever wrote code to check for slippery conditions.

Real-World Example: Medical Diagnosis

The MYCIN expert system (Stanford, 1970s) used exactly this architecture. Doctors would TELL MYCIN the patient’s symptoms, lab results, and medical history. MYCIN’s inference engine would then ASK questions like "what organism is responsible?" and work through 600 if-then rules to reach a diagnosis and recommend an antibiotic.

MYCIN-Style Knowledge Base Interaction

TELL phase (entering patient data):

TELL(KB, "fever = HIGH")
TELL(KB, "cough = PRESENT")
TELL(KB, "fatigue = HIGH")
TELL(KB, "body_aches = PRESENT")

Rules in the KB:

R1: fever ∧ cough ∧ fatigue → influenza
R3: influenza → recommend_rest
R4: influenza → recommend_fluids
R5: influenza → antiviral_medication
R6: body_aches ∧ influenza → recommend_pain_reliever

ASK phase (system queries):

ASK(KB, "influenza")              → TRUE  (via R1)
ASK(KB, "recommend_rest")         → TRUE  (via R3, because influenza is TRUE)
ASK(KB, "recommend_pain_reliever")→ TRUE  (via R6, because body_aches ∧ influenza)

The system derived the full treatment plan — none of the recommendation facts were told explicitly.

A traditional database can only return facts that were explicitly stored. A knowledge base can derive facts that were never stored, as long as they logically follow from what is known.

Think of a domain you know well — a sport, a hobby, a field of study. Can you write five if-then rules that would let an inference engine answer questions a newcomer might ask? What makes some rules harder to express than others?

The Knowledge Base Agent Loop

A knowledge-based agent operates in a continuous perceive-reason-act loop:

KB Agent Cycle

Perceive: The agent receives a percept from the environment (e.g., sensor readings, user input).
TELL: The agent adds the percept to its knowledge base as a new fact.
ASK: The agent queries the KB for the best action given current knowledge.
Act: The agent executes the action returned by the KB.
Repeat: Return to step 1.

At each time step, the inference engine may draw on all facts accumulated since the agent was created. This means reasoning can span multiple interactions — the agent "remembers" everything it has been told.

Advantages and Challenges

Advantages of knowledge-based agents:

Explainable: Every conclusion has a traceable proof — important for high-stakes domains.
Modular: Add new rules without changing the inference engine.
Small-data friendly: Encodes expert knowledge directly, no training data needed.
Guaranteed correctness: If the KB is correct and the inference rules are sound, every conclusion is provably true.

Challenges:

Knowledge acquisition bottleneck: Extracting and formalizing expert knowledge is slow and expensive.
Brittleness: Fails on situations not covered by the rule set.
Frame problem: Representing what changes and what stays the same after an action is surprisingly difficult (covered in Section 6.6).

Test your understanding of the tell-ask interface and the knowledge-based agent architecture.

Next: 6.2 Inference Rules →

Based on the UC Berkeley CS 188 Online Textbook by Nikhil Sharma, Josh Hug, Jacky Liang, and Henry Zhu, licensed under CC BY-SA 4.0.

This work is licensed under CC BY-SA 4.0.