The Pain: Your agent forgets to query the knowledge base. The same knowledge base, the same model — different orchestration produces wildly different outputs. Change one prompt line and everything breaks. Agents still "work by feel", and every fix is another manual patch that might break something else.
What You'll Learn: The full physicalization framework — 9 pillars that turn a probabilistic LLM into a deterministic business system: physicalized constraints (rules as code, gates as scripts, provenance markers), engineering away hallucinations, memory done right, error immunity, multi-agent boundaries, the evolution path from Prompt to Platform, Maker/Checker trust verification, knowledge injection, and ops reliability. Every pillar comes with its assumption, prerequisite, and boundary — and a 4-stage adoption path you can start tonight.
Zero: Core Idea — Determinism First, Probability Constrained
Why does an agent "forget" to query the knowledge base? Why does the same knowledge base, the same model, and different orchestration produce drastically different results? Why does changing one prompt line break the whole pipeline? — The answer to all three is in the word "engineering".
I have been doing agent engineering since OpenClaw launched (November 2025) — 273 days now, with plenty of pits stepped into along the way, and a "physicalized automation system" distilled from them. This article is the master overview: it strings the fragments scattered across the series into one complete system, and for each approach it states clearly: what is the assumption, what is the prerequisite, where is the boundary.
Assumption
LLM is a probabilistic system — the same input can produce different outputs; it hallucinates, forgets, and breaks instructions.
Corollary
If it can be deterministic, do not let the LLM decide (use code/rules/scripts)
What must be delegated to the LLM, wrap it in constraints (inject + verify + immunize)
Boundary
This way of thinking applies only when the task has a "correct standard" — verifiable format, rules, or facts. If the task is open-ended creativity (writing poetry, brainstorming), over-constraining hurts instead of helps.
One: Physicalized Constraint System (Pillar A)
1.1 Physicalized Rules (SOP Injection)
What to do: Write "how things must be done" into rule files, and physically inject them before every LLM call via a hook (pre_llm_call).
Assumption: The LLM will "forget" to read the rules — so you cannot rely on "remembering".
Prerequisite: The rule file exists and is lean (head -100, read in milliseconds).
Boundary: Only applies to hard-constraint knowledge (violating it = incident). Reference knowledge (customer preferences, historical data) is large and dynamic; full injection blows the context — that kind should be retrieved on demand by the LLM.
1.2 Gate Validation (Post-hook)
What to do: After output, validate with a script (line count / format / blocked words / links); if it does not pass, delivery is forbidden.
Assumption: Validation criteria can be codified.
Prerequisite: The script is actually mounted (pre-commit hook / mandatory run before publishing).
Boundary: A gate is "after-the-fact punishment". It guarantees "no garbage is shipped" but not "correct from the start" — it needs to work together with input constraints.
1.3 Provenance Marking
What to do: Outputs carry a "produced by the pipeline" marker; the gate checks the marker's existence.
Boundary: Suits scenarios with a "single canonical output path"; multi-entry tasks (e.g. an email system) do not fit a single marker.
Two: Engineering Away Hallucination (Pillar B)
2.1 Input Constraints (Mechanism-Chain Injection)
What to do: Write the critical reasoning chain directly into the context; do not let the LLM retrieve and assemble it itself.
Assumption: LLM self-retrieval is unreliable (may not get it, or not get all of it).
Prerequisite: The reasoning chain can be generated by deterministic code (derived from structured data).
Boundary: Suits professional scenarios where "an expert can see the reasoning in one glance"; not for large, dynamic reference knowledge (that should be retrieved).
2.2 Reasoning Constraints (SOP + Structure Template)
What to do: Fix the section structure, forbid "no data available" placeholders, require substantive content in every section.
2.3 Output Validation (Evals + Golden Dataset + LLM-as-Judge)
What to do:
- Trajectory evals: test the process, not just the final answer (a green answer with a broken process is still a failure)
- Golden Dataset: solidify past mistakes into a regression gate
- LLM-as-Judge: the judge itself must be calibrated (golden set → consistency → threshold)
2.4 Immunity Feedback (Error Ledger → Physicalized Rules)
What to do: Error → error-ledger → extract root cause → solidify rule (skill/script/gate) → never again.
Boundary: This chain requires errors to be attributable and rules to be formalizable — vague errors ("the answer was not good enough") are hard to physicalize.
Three: Memory and Context (Pillar C)
3.1 Index First, Then Feed (Lightweight RAG)
What to do: Do not feed the whole knowledge base to the LLM — build an index first, query the relevant fragments, and feed only what is relevant.
Assumption: The knowledge base has structure (nodes / distilled cards).
Boundary: Suits small-to-medium knowledge bases; large bases should move to vector retrieval.
3.2 The Context Budget
Boundary: Context is a scarce resource — full injection blows up (measured in production: Chroma retrieval dragged 3–11s per call, and the hook timed out and was dropped).
Four: Error Immunity System (Pillar D)
What to do: Incident → ledger → fix → re-inject rules (a four-step closed loop).
Assumption: An organization will step into the same pit repeatedly unless the system has immunity.
Boundary: Immunity = "it will not break the same way again"; a fix = "back to normal". They are different — immunity is the higher goal.
Five: Multi-Agent Collaboration (Pillar E)
What to do: MCP (tool protocol) + A2A (agent-to-agent protocol) + AG-UI (human-agent layer) + Supervisor (multi-agent management).
Boundary: More agents is not automatically better — you need them only when complexity goes up; otherwise a single agent with good context is more stable.
Six: The Engineering Evolution Path (Pillar F)
Evolution ladder: Prompt → Context → Loop → Graph → Platform.
Boundary: Do not skip layers — jumping straight to Graph while Context is not done means the graph is full of "amnesiac nodes".
Seven: Trust Verification (Pillar G)
What to do: Maker/Checker separation + automated validation (the sandwich) + physical gate orchestration.
Assumption: Self-produced and self-verified equals self-deception — the producer and the checker must be separated.
Eight: Knowledge Injection Methodology (Pillar H)
Core: What you give an agent is not a knowledge base — it is the path to use knowledge.
Routing: Hard constraints → inject; reference knowledge → retrieve; data → process with scripts.
Nine: Agent Ops and Reliability (Pillar I)
What to do: Health checks → auto-restart → anomaly alerts → log rotation (unattended); the observability trio (gate / audit / correction).
Boundary: Tool isolation and least privilege are the security baseline — the agent's behavioral boundary must be locked down.
Ten: How to Adopt It — A Path for Practitioners
Phase 1 (week 1): physicalize "hard constraints" — rule files + SOP injection + gate scripts
Phase 2 (week 2): build error immunity — error-ledger + correction sedimentation + re-injection
Phase 3 (week 3): knowledge injection — mechanism chains written into context, reference knowledge retrieved on demand
Phase 4 (ongoing): evolve — from single agent to multi-agent, from Loop to Graph
Prerequisite for every phase: first have a real business scenario (not a toy), first have a "correct standard" (verifiable), first have an error record (not a blank page).
Eleven: Boundaries and Limitations (The System's Assumptions, Costs, and Trade-offs)
| Assumption | Cost | Boundary |
|---|---|---|
| The task has a correct standard | Over-constraining limits creativity | Use fewer rules for open-ended tasks |
| Rules can be formalized | Maintenance cost (writing rules/scripts) | Vague errors are hard to physicalize |
| Validation can be codified | Gates may over-block | Needs manual spot-check calibration |
| Reasoning chains can be generated | Requires domain experts to distill | Hard to inject without experts |
| Knowledge has structure | Requires indexing/distillation | Structureless knowledge is hard to retrieve |
Twelve: Where You Are Now
LLM is probabilistic; business needs deterministic.
All of agent engineering is building a bridge between the two:
physicalized constraints (the piers), hallucination removal (the guardrails),
error immunity (the maintenance), knowledge injection (the deck).
This system is not theory — it is 273 days of running from OpenClaw
to a complete engineering system in real business scenarios:
rule injection is code, gates are scripts, error logging is files, immunity is a closed loop.
Every step has physical evidence; nothing depends on anyone's self-discipline.
If your agent is still "working by feel", it is time to give it a physicalized system.
Further Reading (Practitioner's Series)
- From Loop to Graph: Our 52-Day Agent Engineering Evolution — the evolution path
- Self-Improving Agents Are Not a Myth — error immunity
- Don't Give Your Agent a Knowledge Base — Give It the Path to Use Knowledge — knowledge injection
- Stop Testing Final Answers: Trajectory Evals Are the Truth About Agent Quality — removing hallucination
- From SOP to Immunity: The 4-Step Loop That Turns Every Incident into Organizational Capability — organizational immunity
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.
Top comments (0)