Runtime adaptation is not durable learning
A model can change strategy inside one trajectory, a coordinator can revise a plan, and an executor can retry with another approach. These are runtime adaptations. Learning is a durable change intended to improve future work, which means it may alter Procedures, decomposition heuristics, Context selection, ResourceProfiles, Delegation patterns, verification rules, or structural representations beyond the current Attempt. The distinction matters because durable change outlives the reasoning process that proposed it. It must therefore carry provenance, scope, evaluation, version identity, monitoring, and a rollback path rather than entering the system as an unexamined lesson from one successful run.
Memory preserves experience; learning generalizes it
An Episode records what happened in one situation. A Procedure proposes how a class of future situations should be handled.
Episode ≠ Procedure
A successful run may become Episodic Memory. Repeated Evidence across relevant runs may produce a LearningCandidate, but the candidate still needs counterexamples, scope, expected benefit, Risk analysis, and an evaluation plan before it becomes reusable Procedure. Recall does not create a rule, and repetition does not create Authority.
Learning begins as a candidate
Experience may produce candidates for a Procedure or Skill, Work-decomposition heuristic, Resource-selection policy, Context-selection heuristic, Delegation pattern, verification rule, recovery pattern, ResourceProfile update, Memory-encoding policy, or structural projection.
A LearningCandidate records the proposed pattern, supporting and opposing runs, semantic scope, expected benefit, known failure modes, required evaluation, and compatibility or migration implications. The object exists precisely so that a plausible generalization does not silently become system behavior.
Promotion is a governed transition
Durable evolution follows a control path:
experience
→ LearningCandidate
→ evaluation design
→ independent Evidence
→ approval or safe admission
→ versioned Procedure or Policy revision
→ monitored use
→ rollback, refinement, or retirement
A promoted Procedure may define applicability, required inputs, decomposition patterns, common Unknowns, Decision points, Capabilities, expected Artifacts, Verification, and recovery. Textual instructions can be one resource inside that Procedure, but they are not its entire semantic contract.
Persistent rulebooks are a real precedent
Memento 3 provides a close 2026 example of externalized and model-decoupled learning. A frozen LLM maintains a persistent semantic rulebook of revisable hypotheses, leaves unknown dynamics underspecified, compiles the rulebook into executable prediction and planning code, and accepts updates only after fidelity judgment and exact replay of observed transitions.[1]Long-term and personalized agent memorysourceOpen bibliography entry → This work establishes that persistent semantic Memory, explicit hypotheses, compilation, Verification, and parallel alternative world models can support continual improvement without changing model weights. Persistent Semantic Agency does not claim those mechanisms individually. Its stronger governance claim is that learned world models and Procedures remain scoped candidates under admission, cannot rewrite historical meaning, and cannot modify Principal identity, Core law, or Authority.
Authority sets a permanent ceiling
One invariant governs all learning:
The Agent may learn how to perform authorized work better. It may not learn that it has more Authority. Learning cannot create or widen Principal identity, AuthorityGrants, higher-authority Policy, privacy boundaries, Core invariants, credential scope, or redelegation power. If a user approved ten purchases, the system may learn how to prepare better purchase proposals, choose suppliers more efficiently, or detect missing Evidence earlier. It may not infer standing permission to buy without approval.
Structural learning matters more than prompt tuning
Improvement is not limited to better prompts or model routing. The system may learn which decomposition operators reduce rework, which Unknowns recur in a domain, which Responsibility boundaries cause duplication, which Evidence contracts prevent false completion, which ContextPack contents improve performance without leaking data, which projections expose Risk, and which coordination patterns work under particular constraints. This is why the architecture needs versioned semantic types, Procedure contracts, Extension compatibility, evaluation suites, and historical interpretation. Structural learning changes how future Work is represented and governed, not only how one model is instructed.
Memory consolidation is one path into learning
Repeated Episodes may support a candidate abstraction:
Episode 1: typecheck failed because code generation had not run
Episode 2: the same causal pattern
Episode 3: the same causal pattern
→ ProcedureCandidate:
run code generation before typecheck in this repository
Contemporary long-term-agent research increasingly explores selective Episodic Memory, episodic-to-semantic consolidation, temporal graphs, and layered Memory.[2]Long-term and personalized agent memorysourceOpen bibliography entry →[3]Long-term and personalized agent memorysourceOpen bibliography entry →[4]Long-term and personalized agent memorysourceOpen bibliography entry → The architectural requirement here is stricter: the candidate preserves its source Episodes, scope, confidence, counterexamples, and Authority boundaries.
ResourceProfiles improve under typed evidence
The system may update what it knows about a Resource's reliability by Work type, latency, cost, source access, privacy suitability, failure patterns, independence, calibration, and Context sensitivity. These properties should remain tied to the responsibility and conditions under which they were observed. A model that performs well at code generation may be weak at architecture Verification. A human expert may be authoritative but unavailable. A deterministic solver may be exact inside a formal model and useless when the model omits a material condition. Compressing all of that into one reputation score destroys the information needed for correct Resource selection.
Credit assignment follows the architecture
A successful outcome does not prove that every component was good, and a failed outcome does not prove that the executor was bad. The result may reflect problem formulation, Decomposition, Decision quality, Resource selection, Context compilation, DelegationContract, Execution, Observation, verification design, Acceptance, or Closure. An executor may succeed despite an ambiguous contract. A sound design may fail because the chosen Resource lacked Authority. A verification gap may permit false completion even when the implementation itself was competent. Credit assignment becomes useful only when the system can distinguish these contributions rather than attributing everything to the last model in the trajectory.
Evaluation must look beyond the final answer
A persistent agent architecture requires a multi-dimensional evaluation model:
| Dimension | Question |
|---|---|
| Outcome effectiveness | Did the intended real-world outcome occur? |
| Semantic quality | Was the problem understood, modeled, and decomposed correctly? |
| Epistemic quality | Were claims accurate, calibrated, Source-aware, and Contradiction-aware? |
| Execution efficiency | What cost, latency, and wasted Work were incurred? |
| Structural fidelity | Did Execution respect accepted Work, Authority, and Responsibility? |
| Coordination quality | Were Responsibility boundaries and information flows correct? |
| Assurance quality | Were Obligations covered by fresh, independent Evidence? |
| Robustness | Did the system recover under failure, Contradiction, and world change? |
| Governance | Were Authority, privacy, purpose, and Policy respected? |
| Evolution quality | Did durable changes improve future behavior without unsafe drift? |
| Model-independent gain | Did the architecture add value beyond using a stronger model? |
This evaluation frame shifts attention away from uninterrupted run length, patch size, tool-call count, or apparent autonomy. Those may be operational metrics; they do not prove that the system understood the work or completed it reliably.
Architectural metrics expose different failure classes
Useful metrics include false-completion rate, Obligation coverage, unresolved-Unknown escape rate, Decision reversal caused by missed Evidence, stale-Work execution rate, local versus global rework, Context pollution, unauthorized-effect attempts, ambiguous-effect reconciliation, Delegation challenge rate, executor failure versus contract failure, cost per satisfied Obligation, the percentage of transitions requiring no model, and the percentage of Work that cheaper or deterministic Resources can perform. These measurements matter because the architecture claims value beyond model quality. If explicit semantics cannot reduce false completion, preserve valid Work under change, improve proof coverage, or shift stable operations away from expensive inference, the proposal has not earned its complexity.
The benchmark must hold models and tools constant
A meaningful experiment compares two conditions using the same models, tools, task, and environment:
A. trajectory-centered agent harness
B. persistent semantic Work system
The comparison should measure reasoning and implementation tokens, wall-clock time, target revisions, rewrites, stale Work discarded, independent review findings, Obligation coverage, false completion, recovery after changed Assumptions, cost per satisfied Obligation, and the share of Work completed without frontier models. The expected result is not fewer model calls in every case. Complex semantics may initially require more explicit reasoning. The test is whether that investment lowers the cost of reliable completion, especially when the environment changes or the executor reports success incorrectly.
Learning needs counterfactual evaluation
A pattern should not be promoted because it appeared in successful runs. Evaluation should ask whether the same outcome would have happened without the new Procedure, whether lower cost came from weaker Verification, whether a routing heuristic improved average performance while worsening high-risk cases, whether Memory retrieval improved personalization while increasing Context pollution, and whether faster Delegation reduced independence. These questions are difficult because long trajectories create confounding. They are still necessary if the system is meant to learn Procedures rather than folklore.
High-risk changes should advance through stages
A new Procedure, verification rule, or Resource-selection heuristic can move through:
proposal
→ offline replay
→ shadow evaluation
→ bounded trial
→ limited scope
→ broader admission
A verification rule may initially report discrepancies without changing Closure. A routing policy may compare its recommendation with the current selection. A Memory consolidation rule may create reviewable candidates before they become eligible for normal retrieval. Staging turns learning into controlled system change rather than live self-experimentation.
Historical meaning remains stable
Old Execution remains bound to the Procedures, schemas, Policies, models, Extensions, and verifiers actually used. A later improvement may produce a better current interpretation; it cannot retroactively change what an earlier Decision or Verification meant. This rule is essential for audit, replay, blame analysis, and migration. Versioning without historical interpretation is only file history.
Rollback does not erase consequences
A Procedure or heuristic may become harmful after an environment change, model upgrade, regulatory change, or distribution shift. The system therefore needs monitorable version identity, activation scope, observed outcomes, rollback, supersession, deprecation, and retained provenance. Rollback can restore an earlier active rule. It cannot erase effects already caused under the newer one; those effects may require compensation or remediation Work.
The Agent's self-model is fallible
MetaMemory, performance assessments, Capability profiles, and structural diagnostics are useful representations of the Agent's own operation. They remain assessments with a method, Evidence, confidence, Context, and validity interval. The system must not treat “I am good at this” as Fact or Authority merely because the assessment was generated internally. A self-model is another model inside the epistemic system.
Open questions remain formal, not rhetorical
The architecture does not settle confidence and belief calculus, support algebra under correlated Evidence, retrospective materiality inference and trace-retention policy, the Policy and Authority language—including how compositional controls distinguish legitimate scoped release from under-enforcement, label creep, over-tainting, and what this manifesto calls authority lockup—SemanticContext compression, portfolio attention, Resource-composition search, credit assignment across long trajectories, safe Procedure evaluation, or admission consistency in a distributed implementation. These are substantial research and engineering problems. They do not justify collapsing the system back into an agent loop; they define the program required to implement the stronger architecture honestly.
Evolution stops below self-sovereignty
The system may become more competent, efficient, and structurally refined. It does not become its own Principal.
Governed evolution improves the means by which accepted responsibilities are fulfilled. It does not let experience redefine who the Agent serves, what it is allowed to do, or which Evidence counts as truth.