Where Knowledge Goes in Your Agent Harness

Give each kind of knowledge its place in the harness before the task starts, so the model’s best guess is the one you expect

Knowledge-Driven Agent Harness, Part 2 of 6

This story was written with the assistance of an AI writing program. The ideas, the design, and the outline are mine; the AI drafted the text and the figures, and I reviewed every section and directed each revision.

In Part 1, knowledge was one part of the agent harness. But an agent works with many kinds of knowledge, and if the harness doesn’t define what each kind is, where it goes, and how it’s handled, the model fills the gaps with guesses: where to look, whether a rule applies, whether a result is right, what to keep. A long task makes many of those guesses, and any of them can go wrong.

Picture Agent Smith from The Matrix (1999) with a pile of notes and no instructions for using them. Where is Neo right now? How should Smith follow him? Whose body may he take over? Is Cypher’s tip true? What should he remember? Each answer is a guess.

Figure 1. With nothing defined in advance, Smith has to guess at every step: where to look, how to follow, what’s allowed, what’s true, and what to keep. Image created with AI.

The fix is to give each kind of knowledge its place before the task starts: which part of the harness uses it, when, and in what form. For Smith, the map tells him where to look Neo up, a procedure tells him to plant a bug on Neo and follow its signal, and the Matrix itself decides whose body he can take over. A model always predicts; knowledge can’t stop that, but it can make the prediction the one you want. That’s the key idea of this article: give each kind of knowledge its place in the harness before the task starts, so the model’s best guess is the one you expect.

Figure 2. Each kind of knowledge gets its place in advance: the harness part that uses it, and when. Rules, verification, and the acquired knowledge policy run as deterministic checks. Image created with AI.

The rest of this article sorts knowledge into two levels, then shows how the harness handles each.

1. Sort Knowledge by How the Harness Uses It

There are already good ways to slice what an agent knows. CoALA (Sumers et al.) splits an agent’s memory into working, episodic, semantic, and procedural memory. “The Missing Knowledge Layer” (Michaël Roynard, 2026) separates knowledge, memory, wisdom, and intelligence by how long each lasts and how it changes. Birgitta Böckeler (2026) sorts harness controls into guides, which steer the agent before it acts, and sensors, which “observe after the agent acts.”

None of these answers the question a harness builder faces every day: where does this piece of knowledge go? So this series sorts knowledge by how the harness uses it, with three questions:

• Which part of the harness uses it? The model, context management, tools, permission control, verification, or memory.
• When? All the time, when a step needs it, before an action, after an action, or when the agent learns something new.
• In what form? Text the model reads, or a deterministic check the harness runs.

The form decides the force: text informs the model’s judgment, and a deterministic check decides the outcome, whatever the model believes.

Figure 3. Other taxonomies slice knowledge by how a mind stores it, how long it lasts, or when it steers. This series slices it by which harness part uses it, when, and in what form. Image created with AI.

2. Knowledge + State

Part 1 split prior knowledge, everything people give the agent before it starts, into two parts. They sit on two levels, and the idea is old. Knowledge about the world is first-order knowledge; knowledge about knowledge is second-order knowledge, or meta-knowledge. Expert systems put the split to work decades ago. Randall Davis and Bruce Buchanan defined meta-level knowledge in 1977, and Davis’s meta-rules (1980) didn’t solve the task themselves; they controlled which of the system’s rules to use.

Initial knowledge is first-order knowledge: knowledge about the task’s world. Here are the kinds this series uses so far, grouped by the question each one answers, with a real-agent example for each. Later articles may add kinds.

• What is it? Facts (who owns each service) and concepts (what a latency target means).
• How do I do it? Procedures (the rollback runbook).
• Should I? Rules (no production database changes without approval) and heuristics (if latency spikes after a deploy, roll back first).
• Is it right? Verification (recovered means response time under target for 10 minutes).
• What happened before? Past cases (last quarter’s incident reviews).
• Where is it? The map (which file holds what), an index of the rest. The map comes from OpenAI’s harness engineering post (Ryan Lopopolo, February 2026).

The acquired knowledge policy is second-order knowledge. It isn’t about the task’s world. It says what to do with anything the agent learns about that world: which kind a new finding is, and how to process it.

State isn’t knowledge at all. It’s where the task stands right now (step 4 of 7: waiting for approval). The harness updates it every turn, outside knowledge governance.

Figure 4. Initial knowledge is first-order: it’s about the task’s world. The acquired knowledge policy is second-order: knowledge about knowledge. State isn’t knowledge. Image created with AI.

Each kind is separate because the harness handles it differently: a rule is checked before an action, a heuristic is advice the model weighs, verification runs after an action, and the map is always in the context. Two kinds handled the same way would be one kind.

Sections 3 and 4 show how the harness handles each level. Both serve one aim:

Give each kind of knowledge its place in the harness before the task starts, so the model’s best guess is the one you expect.

3. Handling Initial Knowledge

Initial knowledge drives the task. The harness handles it with two principles: load only what each step needs, and check each result.

3.1 Load only what each step needs

Always in the context: the map, a short summary of the concepts, the names of the procedures, and the text of the rules. (Rules also go to permission control, which checks them before each action, as Part 1 showed. Smith lives under one: he can take over only people still plugged in to the Matrix.) The map matters most. It doesn’t hold knowledge; it says where knowledge is: about a page that lists where facts, concepts, procedures, past cases, and heuristics live, and when to use each. For Smith, it’s knowing which file to open for which target.

Figure 5. The map is about one page and always in the context. It points to everything else, which loads only when a step needs it. Image created with AI.

Loaded when a step needs it: facts come back as tool or search results, heuristics come in at a decision point, and past cases come in when a similar case comes up. Procedures, the bulkiest kind, load in three layers:

• A name and one line, always in the context, so the agent knows the procedure exists.
• The full steps, loaded when the step comes.
• Scripts, which the harness runs as tools instead of the model reading them.

A rollback runbook is one line in the map until a rollback starts; then its steps load, and a script performs it.

Figure 6. Only a procedure’s name and one line are always in the context. The steps load when needed, and scripts run instead of being read. Image created with AI.

Get Ning Xia’s stories in your inbox

Join Medium for free to get updates from this writer.

Remember me for faster sign in

This is progressive disclosure, the pattern behind Agent Skills, which I implemented with Google ADK in an earlier article. It only works if the map is current: a stale map sends the agent to the wrong place with confidence.

3.2 Check each result

Verification knowledge says what “right” looks like. After each action, the verification part checks the result against it, preferably with a deterministic check such as a test or a health check, not by asking the model whether it worked.

The result answers two questions. Was the action done right? If not, the agent fixes it and tries again. Was the knowledge behind it right? Say the service list names Team A as the owner of checkout. The agent pages Team A, and Team A replies: “Not ours anymore; Team B took it over last month.” The page went out as planned, so the action was right. The list was stale, so the knowledge was wrong. Fixing knowledge is the acquired knowledge policy’s job (section 4).

Figure 7. The definition of “right” is initial knowledge. When a result shows that the knowledge behind an action was wrong, the acquired knowledge policy fixes it. Image created with AI.

4. Handling the Acquired Knowledge Policy

The acquired knowledge policy is about knowledge itself, so the harness handles it differently.

It runs on every write. Every step brings acquired knowledge: tool results, observations, tips, and what each check revealed. Memory applies the policy, so nothing gets written down without passing it. It works best as a deterministic check, with a short summary in the context so the model knows it exists.

It works in two steps, both defined in advance:

1. Decide which kind it is: a new fact, a heuristic, a past case, state for this task, or an attempt to change a rule.
2. Process it with the rule defined for that kind: forget it, keep it for this task, verify it and save it as ai-verified, block it, or report it to people.

Five questions pick the rule:

1. Was it checked outside the model? A tool result or a test beats the model’s own conclusion.
2. Does it come from a trusted source? A claim from an unknown source is verified before it’s used.
3. Is it likely to be reused? A one-off result can be forgotten.
4. Is it sensitive? Personal data and secrets are never saved as knowledge.
5. Does it conflict with what we already know? Then it’s verified before it replaces anything; if the conflict can’t be settled, it’s reported.

Figure 8. The acquired knowledge policy decides which kind each new finding is, then processes it with that kind’s rule. It stops poison twice: at the door, and with a tombstone. Image created with AI.

It fixes what failed checks reveal. In section 3, “Team B owns checkout” is a new fact. The policy verifies it, for example against the on-call schedule, and saves it as ai-verified in place of the stale entry, so the next task pages the right team. People step in only when the policy can’t settle a case.

Only people change the acquired knowledge policy. The agent applies it but can’t rewrite it: anything that tries to change the policy or the rules is blocked. When the policy can’t settle a case, people decide whether it needs to change.

It guards against poison, twice. First, the check on every write blocks instructions hidden in data, disproved claims, and secrets. Second, when a saved item turns out to be wrong, its content is deleted and a short tombstone note stays, so the same claim is blocked if it shows up again. Poison already in the context has affected the current reasoning, though; remove it, or hand the work to a clean sub-agent. Forgetting on purpose is part of the policy too; I wrote about “strategic forgetting” in Beyond the Chat Loop.

5. What’s Next

Two last rules apply to every kind. Supply only what the model doesn’t know or gets wrong: it already knows what an HTTP 500 error is; it doesn’t know your approval rules. And knowledge goes stale at different speeds: rules change slowly, facts faster, state every turn. Stale knowledge is dangerous because the agent trusts it.

That’s the subject of Part 3: how knowledge is governed, with states, owners, and a lifecycle, so the agent can trust what it loads.

Knowledge-Driven Agent Harness

1. Your Agent Harness Runs on Knowledge
2. Where Knowledge Goes in Your Agent Harness (this article)
3. Governing Agent Knowledge (next)
4. Storing and Retrieving Knowledge
5. Evaluating Knowledge
6. Case Study: End to End

Related articles

• Build It: How I Implemented “Claude Agent Skills” with Google ADK
• Beyond the Chat Loop: Implementing “Progressive Disclosure” Architecture with Google ADK

References

• Theodore R. Sumers, Shunyu Yao, Karthik Narasimhan, Thomas L. Griffiths, “Cognitive Architectures for Language Agents,” TMLR. https://arxiv.org/abs/2309.02427
• Michaël Roynard, “The Missing Knowledge Layer in Cognitive Architectures for AI Agents,” 2026. https://arxiv.org/abs/2604.11364
• Birgitta Böckeler, “Harness engineering for coding agent users,” martinfowler.com, April 2, 2026. https://martinfowler.com/articles/harness-engineering.html
• Ryan Lopopolo, “Harness engineering: leveraging Codex in an agent-first world,” OpenAI, February 11, 2026. https://openai.com/index/harness-engineering/
• Wikipedia, “Metaknowledge.” https://en.wikipedia.org/wiki/Metaknowledge
• Randall Davis and Bruce G. Buchanan, “Meta-Level Knowledge: Overview and Applications,” IJCAI 1977, pp. 920–927. https://mlanthology.org/ijcai/1977/davis1977ijcai-meta
• Randall Davis, “Meta-Rules: Reasoning about Control,” Artificial Intelligence 15(3), 1980, pp. 179–222. https://dblp.org/rec/journals/ai/Davis80.html