Deconstructing the Context System: How Agents Move from Finding Data to Reliable Action

What a Context System Is

Human conversations rely on implicit shared knowledge; when that knowledge is moved into an AI system it must become readable, judgeable, and verifiable . The author names the engineering framework that provides these capabilities the Context System , which extends a traditional knowledge base with the facts, rules, state, tools, and evidence needed for a task.

Knowledge bases remain the source of facts, while the Context System adds the steps that turn those facts into a completed, evidence‑backed result.

The Four Layers

Fact Layer – Deciding What Counts

Agents must ask, “When records conflict, which one decides?” Stable identifiers, provenance, and ownership are required so the system can automatically choose or pause for human confirmation. Ontology separates objects, relationships, states, and constraints, allowing the knowledge base and a database to store records while the ontology defines their meaning (e.g., candidate, approved, deployed versions).

Context Layer – Minimal Sufficient Work Set

The context window is the agent’s workbench. Only the information needed for the current step is loaded; old rules or unrelated logs stay out until required. The author cites Anthropic’s “continuous” context engineering and describes a “minimal sufficient work set” that keeps the window lean while still allowing the agent to pull additional data on demand.

Execution Layer – Model Decision, System Boundary

After the right facts and context are gathered, the agent selects an action, calls a tool, and follows the result. The model only handles a small prompt; the project, version, and environment must be explicitly supplied. Authorization, idempotency, timeout, and concurrency handling are enforced by the underlying system, not by the model’s self‑confidence.

Feedback Layer – Evidence First, Experience Later

When a task finishes, two streams are recorded: (1) runtime evidence that proves whether the task succeeded (e.g., Git commit ↔ artifact mapping, test results, environment health) and (2) candidate experience that may later become reusable process assets after verification and review. The OWASP Agent Memory Guard project is mentioned as a work‑in‑progress effort to protect persistent agent memory.

Running the Architecture on a Real Task

The author walks through a pre‑release verification task, showing how the four layers interact in five steps:

Clarify the exact version and pre‑release environment, confirming identifiers, approvals, and validity.

Refresh the context for each step (e.g., load logs only when an error occurs).

Perform a change preview, verify boundaries, and invoke authorized tools; illegal parameters or missing permissions cause immediate rejection.

Collect evidence from Git, artifact stores, test systems, deployment platforms, and monitoring to prove the result.

Store new findings as candidate experience, attaching source, applicable version, and reproduction steps for later review.

任务：预发布核验

必须读取：
 - 当前发布规则
 - 候选版本清单
 - 目标环境状态

按需读取：
 - 对应事故复盘
 - 深层日志和历史变更

停止条件：
 - 授权缺失
 - 候选版本不唯一
 - 必要检查未通过

验收证据：
 - 提交与制品对应关系
 - 构建和测试结果
 - 目标环境版本与健康状态

Incremental Adoption

Rather than building all four layers at once, the author suggests starting with a high‑frequency, low‑risk chain such as pre‑release verification. First draw a simple source map (where objects come from, who maintains them, conflict‑resolution rules). Then write a concise context recipe (required reads, stop conditions, evidence). Use YAML/JSON or existing workflow definitions; a full DSL is unnecessary initially.

Next, define tool contracts (input schema, permissions, timeout, rollback entry). Prepare failure samples (e.g., multiple candidate versions, expired approvals, successful deployment but failing health check) to test the system’s ability to halt and record evidence.

Metrics at this stage focus on source correctness, evidence completeness, and the ability to stop on conflict rather than raw speed. Once the read‑only chain is stable, gradually open write operations with review and rollback capabilities, then measure experience‑candidate pass rates.

Final Thoughts

A knowledge base alone is insufficient; agents need a runtime layer that validates applicability, executes actions, and verifies outcomes. The four layers—Fact, Context, Execution, Feedback—can be built incrementally, each revealing the next missing piece through real‑world tasks.

Knowledge accumulates over time, but for today’s agent systems the key is ensuring every action can be explained and audited.