DEV Community

weiwuji
weiwuji

Posted on

Don't Give Your Agent a Knowledge Base — Give It the Path to Use Knowledge

#engineering #agents #ai

The Pain
You gave your agent the entire knowledge base. It read everything. And the report it produced still reads like an itemized ledger — conclusions with no reasoning, labels with no chain. Why does an agent that "learned all the material" still write like this? Why does the same knowledge base produce wildly different quality depending on how you hand it over?

What You'll Learn

  • Why "knowledge in the library" is not the same as "knowledge usable" — and why a self-learning agent may only use about 10% of what you give it
  • The three reasons self-learning fails: unreliable retrieval, inert knowledge, and the difference between labels and mechanism chains
  • The mechanism-chain injection method: pre-hook injection, structure constraints, and a verification gate, with concrete examples
  • Why this generalizes to any deep professional analysis — legal, medical, financial, engineering review

I recently ran a controlled experiment that deepened my understanding of Agent engineering. Same knowledge base, same chart-casting engine, same person being analyzed — two agents, two wildly different outputs:

Metric Agent A (self-learn) Agent B (injected)
Report lines 577 1,842
Character count 8,926 37,227
Subsections per § 1 table + a few lines 5-10 subsections
Decade-luck analysis 1 table 5 subsections per period
Nature of the content Label-sticking Mechanism analysis

The difference is not the model and not the knowledge volume — it is how the knowledge is given.

1. Knowledge in the library ≠ knowledge usable

Same knowledge base, same engine, same subject — Agent A vs Agent B

What Agent A did: let it learn on its own

Agent A was "taught" the entire body of BaZi knowledge — patterns, ten gods, favorable elements, decade luck — loaded into its knowledge base and skill files. Then it was told to write the report.

The result? A 577-line "label ledger": one table and a few sentences per section.

✕ wealth star 64 pts → very wealthy              (label)
✕ hurting officer in spouse palace → bad marriage (label)
Enter fullscreen mode Exit fullscreen mode

It clearly "learned" — it knows that a strong wealth star means wealth and that a hurting officer in the spouse palace is bad. But everything it wrote is a conclusion. There is no reasoning process anywhere.

What Agent B did: gave it the path to use the knowledge

For the same report, I changed the delivery. Instead of dumping the whole knowledge base at it, I wrote the reasoning chain of every key judgment directly into the task context:

✓ wealth star in month branch, indirect wealth 40 pts → opportunistic wealth
  → day master too weak to carry it → rich house, poor man
  → needs resource & peer luck to cash out → realized in the Ren-Zi decade at 51  (mechanism chain)

✓ hurting officer in spouse palace → brilliant but picky and harsh → marry late
  → needs an officer-star decade to trigger → manifested in the Geng-Xu period at 36 (mechanism chain)
Enter fullscreen mode Exit fullscreen mode

The result: 1,842 lines, 5-10 subsections per section, 5 subsections per decade-luck period — a full report of "because… so… therefore…" reasoning.

2. Why self-learning fails

Labels are endpoints of knowledge; mechanism chains are the paths

Reason 1: LLM retrieval is unreliable

Letting the LLM "load skills → retrieve rules → reason" on its own makes every step probabilistic:

  • It might load only 1 skill (and forget the other 6)
  • It might retrieve a rule and still not use it — knowing a rule and knowing how to reason with it are two different things
  • It might hit context-length limits and never reach the key knowledge

You hand it a knowledge base — it may only use 10% of it.

Reason 2: knowledge is inert

Knowledge lying in a library is inert — without a usage path, knowledge does not flow by itself. It is like memorizing an entire cookbook and still failing the dish, because you never learned whether to heat the pan or chop the vegetables first.

Reason 3: labels vs mechanism chains — the essential difference 

label:        wealth star strong → rich         (static conclusion)
mechanism:    wealth star → which kind → can it be carried
              → when does it cash out → which decade   (dynamic reasoning)
Enter fullscreen mode Exit fullscreen mode

A label is the endpoint of knowledge. A mechanism chain is the path of knowledge. Users want the path, not the endpoint.

3. How to do it: mechanism-chain injection

Mechanism-chain injection — three tactics with a verification gate

The core principle 

Do not give your Agent a knowledge base — give it the path to use that knowledge.
Write the key reasoning chains directly into the context (injected before the task starts).
Never expect the agent to retrieve them from the knowledge base on its own.
Enter fullscreen mode Exit fullscreen mode

Three tactics that work 

① Pre-hook injection of mechanism chains:
   before the task starts, write every key judgment's "because → so → therefore"
   into the context
   example: "wealth star in month branch → opportunistic wealth → day master too weak
            → rich house, poor man → needs resource luck to cash out"

② Structure constraints (what to write):
   21 fixed sections, each one must carry real substance
   "no data available" is forbidden — every § must contain a mechanism chain

③ Verification gate (write it complete):
   line-count floor (1,800+) · subsection count per section · mechanism-chain count
   (≥30 causal reasoning instances)
   not enough → rewrite. physical interception, not self-discipline
Enter fullscreen mode Exit fullscreen mode

Where this applies

This is not specific to BaZi reports — it applies to any scenario where you need an agent to do deep professional analysis:

  • Legal documents (give it the "statute → elements → application → conclusion" chain)
  • Medical diagnosis (give it the "symptoms → differential → diagnosis → plan" chain)
  • Financial analysis (give it the "data → ratios → risk → recommendation" chain)
  • Engineering review (give it the "requirements → constraints → solution → verification" chain)

Any scenario where "an expert can see the reasoning at a glance" needs reasoning-chain injection — not just a knowledge base.

4. Why this matters more than knowledge-base size

Three layers of agent engineering: rules, injection, verification

knowledge base = the raw-material warehouse
mechanism chain = the process flow
Enter fullscreen mode Exit fullscreen mode

No matter how many raw materials you stock, without a process flow there is no product. The key to Agent engineering is not "how much knowledge you fed it" — it is "how many paths to use that knowledge you gave it."

The three layers in our Agent engineering system:

  • Rules layer (deterministic): "what must be done" is written as code — it does not depend on the LLM
  • Injection layer (key reasoning): "how to think" is written into the context — it guides the LLM
  • Verification layer (result checking): "was it done right" is checked by gates — physical interception

Knowledge injection is the bridge between the rules layer and the verification layer — without it, deterministic rules cannot reach the LLM's reasoning process.

5. You, right now 

The next time you assign a task to an agent, ask yourself:
✕ Did I give it a knowledge base?   (not enough)
✓ Did I give it the path to use that knowledge?   (the key)

Knowledge in the library ≠ knowledge usable.
Don't give your Agent a knowledge base — give it the path to use that knowledge.
Enter fullscreen mode Exit fullscreen mode

About the author: Wu Ji (无记) — AI & digitalization practitioner focused on Agent engineering, Loop Engineering, and digital transformation. Practical, hands-on tutorials — follow along and it just works.

📖 Related reading (Practitioner's series)

Top comments (0)