Agent Architecture: Core Principles and On-Demand Methods
This is a reference and reading map, not another published essay or a new approval process. Core principles should be rare, durable and broadly useful. Engineering methods should be consulted when the relevant design problem arises. Actual security, authorization and effect requirements remain with their owning components.
Layer 1 · Eight core judgments
| Principle | What changes in how we think | Read more |
|---|---|---|
| 1. The model interprets meaning; the system owns objective facts. | A model can research and explain; a Host/Runtime records permissions, execution and receipts. A deterministic rule is not automatically a semantic judge. | Model understands, code authorizes · Model/Runtime boundaries, Chinese original |
| 2. Proposal, approval, execution and effect are different facts. | A tool call is not permission; a returned result is not proof of durable effect. Unknown outcomes cannot silently become “not executed.” | Memory effects · Publication, Chinese original |
| 3. Complexity belongs with its rightful owner. | Encapsulation consolidates decisions and knowledge, not merely files. A child agent or plugin must not invent a duplicate authority system. | Ownership boundaries, Chinese original |
| 4. A local failure must not become a global veto. | A module may reject its own protected effect, but not erase unrelated valid work or independently decide the entire run's fate. | Veto and termination, Chinese original |
| 5. Context is a workbench, not a fact database. | The current model view is bounded and lossy; persistent evidence, memory, tool receipts and history need independent custodians. | Keep results outside context · Main compaction |
| 6. Prefer the smallest sufficient mechanism. | Do not automatically replace the model's flexible research decisions with more planners, validators, hooks or state machines. | Entry simplification, Chinese original |
| 7. Capabilities should be easy to introduce, replace and retire. | A true upgrade lets a new structure replace an old one, without permanently spreading private contracts. This does not require hot-pluggable everything. | Architecture evolution, Chinese original |
| 8. Internal success is not user-task success. | Executing tools, generating text and saving files do not on their own prove that the user received a correct, useful result. | Task convergence · HTML delivery |
Do not add a ninth principle merely because a bug was fixed. A new core idea should genuinely change decisions across multiple systems and resist being explained by an existing principle.
Layer 2 · Six on-demand methods
| Design situation | Method to consult | Existing reading |
|---|---|---|
| Deciding whether to add a feature | The “five don'ts”: don't add mechanisms simply because you can; don't spread complexity; don't give local modules global vetoes; don't impose a normal-path tax; don't build abilities with no exit. | The five don'ts, Chinese original |
| Reviewing responsibilities and rejections | Ask about facts, authority, failure, and value. For a rejection, check ownership, effect scope and duplicate arbitration. | Ownership, Chinese original |
| Passing evidence through a research system | Distinguish stored results, model-visible projections, executed inputs, conservative lineage, and exact claim support. No transform magically upgrades authority. | Evidence chain, Chinese original |
| Planning a multi-phase delivery | Design broadly when needed, but implement along the shortest necessary path to a first usable deliverable; do not make optional infrastructure a hidden prerequisite. | Weekly review staged delivery · Spec and Evidence · Task convergence |
| Choosing verification and diagnosing failure | Infer deterministic invariants with focused contract checks; study uncertain model/user outcomes using proportionate empirical evidence. Locate the actual owner of a failure first. | Test and evaluation fidelity |
| Retiring mechanisms and retaining knowledge | Remove obsolete assumptions from code, specs, prompts, skills and tests without rewriting historical evidence; load long-term knowledge on demand. | Engineering context, memory and knowledge retirement |
These methods are not six new runtime gates. They help select questions and evidence without requiring every change to run the same experiment.
Further reading and forthcoming work
The weekly-review staged-delivery retrospective remains a separate case study. Knowledge retirement is now part of the engineering context and history article. Further topics still need distinct evidence before becoming standalone essays. See the writing roadmap.