Key takeaways
- The survey frames adaptation of agentic AI through post-training, memory, and skills.
- Prompts, tools, middleware, skills, and configuration can also adapt around a fixed model.
- Change manifests, attribution, and per-edit rollback make harness evolution inspectable.
Where can you read Adaptation of Agentic AI?
The primary record is the best place to start. Adaptation of Agentic AI: A Survey of Post-Training, Memory, and Skills was submitted on 18 December 2025 and last revised on 9 March 2026. The arXiv record also provides the paper's PDF.
Here is the compact access map:
- Full title: Adaptation of Agentic AI: A Survey of Post-Training, Memory, and Skills
- Record dates: submitted 18 December 2025; revised 9 March 2026
- PDF: open the current arXiv record and select the PDF
- GitHub: github.com/pat-jj/Awesome-Adaptation-of-Agentic-AI
- Stanford connection: Qizheng Zhang is marked with affiliation 2, which the paper identifies as Stanford
The paper's HTML header identifies the companion GitHub repository. That makes the repository a companion resource named by the paper, not a substitute for the paper itself. The same HTML version supplies the author-affiliation mapping behind the Stanford connection.
That distinction matters when locating the “Adaptation of Agentic AI paper Stanford” or its PDF. The supported Stanford fact concerns one author's marked affiliation. The paper record remains on arXiv, and the repository has its own address. Keeping those routes clear makes it easier to inspect the survey, the current revision, and the companion material without blending them into one source.
What makes agentic AI different?
The practical difference is action. Generative AI answers questions, while AI agents solve problems. An agentic system can also take actions on a user's behalf. That moves the engineering question beyond whether a model produced a good response. You also need to know what state, tools, and execution paths shaped the work.
This is why the adaptation question appears so quickly. Large language model agents are moving beyond prompting alone. A changed result might reflect a change in the model, a memory carried into the task, a reusable procedure, or a surrounding component. The output does not identify that location for you.
Our note on agentic AI and LLMs develops the model-versus-system boundary. For adaptation, that boundary becomes an inspection task: find what changed before deciding what the system learned.
For a design review, separate three questions. Can the system act, where did its current behavior come from, and will that source remain after the current execution? The first question identifies the agentic capability. The other two locate the adaptation and test its persistence. Keeping them separate prevents action capability from becoming a vague claim that the whole system has learned.
Locate the adaptation before judging it
Start with the change surface. The survey organizes adaptation around post-training, memory, and skills. Adjacent technical work adds another useful engineering surface: prompts, tools, middleware, skills, and configuration can change while the underlying model stays fixed.
| Mechanism | Change surface | Concrete form | Inspection focus |
|---|---|---|---|
| On-policy distillation | Training process | A student trains on samples from its evolving policy while a teacher supplies dense supervision | Identify the student samples and teacher supervision |
| Memory | Memory | The survey names memory as an adaptation category | Ask what is retained and where the boundary sits |
| Procedural skills | Skill instructions | A SKILL.md body can hold workflows, best practices, and guidance | Inspect the procedure the model receives |
| Fixed-model harness | Surrounding system | Prompts, tools, middleware, skills, and configuration | Inspect explicit components while the model remains fixed |
What does adaptive AI look like in practice?
A useful adaptation of agentic AI example names both the system and the mechanism. Four examples show why “it got better” is not specific enough.
DeepSeek: The survey describes an example in which on-policy reinforcement learning with verifiable rewards can improve reasoning and tool use. This is a post-training example. It does not establish a general architecture for every adaptive agent.
OpenClaw: The same paper presents OpenClaw as a direction in which agents accumulate persistent memory and reusable skills. Here, the named adaptation sits in memory and skills.
A-MEM: A-MEM is an agentic memory system for LLM agents that dynamically organizes memories. Its project rationale separates advanced memory organization from basic storage and retrieval. When historical experiences require advanced organization, storage and retrieval alone do not perform that organizing work. The example therefore concerns how memories are organized, not a claim that every stored item becomes a durable lesson.
A fixed-model harness: Prompts, tools, middleware, skills, and configuration can form a learnable surface around an unchanged model. In that pattern, experience can become an explicit harness edit rather than a hidden parameter update.
These examples do not collapse into one maturity ladder. They point to different objects that can change. If two agents produce a different result, the difference might sit in training, persistent memory, a reusable skill, or an explicit harness component. Naming that object is more useful than assigning the system a broad “adaptive” label.
For a separate worked system, our agentic AI example stays close to the components and execution path rather than treating agency as a single model feature.
Runtime behavior changes through context, routing, and plans
Not every useful runtime change becomes durable adaptation. A system can alter the current execution through context, routing, or a mutable plan, even before anything is carried into later work.
Context engineering curates what enters the model's limited attention budget at each step. Its goal is to use the smallest set of high-signal tokens that maximizes the likelihood of the desired outcome. This changes the information available for the current decision.
Routing changes who performs the work. Specialized agents can collaborate through handoffs, and the handoff description is used for routing. A changed description can therefore change the path through a multi-agent system.
Long-running execution introduces another surface. An execution plan can be a mutable runtime artifact that is restructured while preserving invariants against cycles, orphaned dependencies, and lost state. The plan changes, but those invariants constrain the change.
This separation helps when reading a trace. Different context may explain a changed response. A handoff description may explain a different specialist. A restructured plan may explain a different sequence of work. Our AI agent architecture guide provides a broader view of where these components sit. Persistence is the additional test that tells you whether any change reaches beyond this execution.
Persistence decides what the system carries forward
Persistence is not one property. It has several boundaries, and each boundary answers a different engineering question.
- Does the information last only for the current task? Short-term memory is transient information managed within the context window for a single task. If the information disappears with that task, the observed change belongs to current execution context.
- Does an explicit artifact transfer across tasks? Long-term memory is persistent information stored externally across tasks. Harness edits can also be accumulated, inspected, and transferred across tasks, which lets a coding agent externalize experience into explicit artifacts instead of relying only on hidden parameter updates. Test the transferred artifact itself. A new task is the boundary that distinguishes this result from short-term context.
- Does state survive requests, restarts, or execution on several machines? A documented session implementation can keep state and conversation history across requests, application restarts, and execution on several machines. In that implementation, state and message changes are persisted only during specific lifecycle events. The test therefore needs both an interruption boundary and the relevant persistence event. Observing state before that event does not establish that the same state will be restored afterward.
- Can work resume from a recorded failure boundary? Durable execution serializes complete execution state at significant boundaries. That allows a long-running autonomous process to resume from its failure point instead of restarting from scratch. The useful result identifies the significant boundary and confirms that execution resumes there. A restart that begins the whole process again has not demonstrated failure-point recovery.
The first two checks separate transient context from information or artifacts carried across tasks. The third checks whether session state crosses operational interruptions. The fourth checks recovery after failure. Passing one test does not state that the system passes the others.
Run the test against a specific change, not the agent in general. A memory record, skill edit, session update, and execution checkpoint can have different lifetimes inside the same system. Record the exact object and boundary you tested. That gives you a concrete persistence claim: this item lasted for one task, crossed tasks, survived a restart, or supported recovery from a recorded failure point.
Persistence mechanisms bring concrete implementation limits
Durable state creates more to inspect. A multi-agent session can hold orchestrator configuration, individual agent states and results, shared context, and execution-flow and node-transition history. Those fields make continuity possible in the documented implementation, but they also enlarge the state surface.
The retained fields answer different recovery questions. Orchestrator configuration describes the coordinating setup. Individual agent states and results preserve agent-level work. Shared context carries common information, while execution-flow and node-transition history record how work moved through the session. A recovery check can inspect each field it depends on instead of treating the presence of a session record as proof that all required state returned.
Concurrency is one limit. The documented session managers are not thread-safe and do not take a distributed lock. A design that expects concurrent access cannot infer coordination from the presence of session persistence.
Persistence and concurrency control are separate properties in this implementation. The session can retain state across interruptions while the manager still lacks thread safety and distributed locking. A system that needs both has to inspect both. The word “durable” answers neither locking question.
The storage boundary also matters. The documented SDK treats the session storage directory as trusted and does not block symlinks there. If an attacker with write access creates a symlink to another file, the SDK can load sensitive file contents into conversation history. That is a specific risk in this storage design, not a general statement about every memory system.
Skills have platform boundaries too. Current documentation says claude.ai can install npm and PyPI packages and pull from GitHub. The Claude API has no network access or runtime package installation. The same skill instructions can therefore encounter different execution constraints across those environments.
The engineering consequence is narrow but important: inspect the implementation that provides persistence or skills. State fields, lifecycle events, locking, storage trust, network access, and package installation are concrete properties. The label “memory” or “skill” does not answer them.
Trust adaptation only with tests, controls, attribution, and rollback
Treat adaptation as trusted only after you can inspect how the change behaves and how it can be constrained. Use these five checks.
- Evaluate every intended model. A skill's effectiveness depends on the underlying model, so the skill should be tested with every model intended for use. A passing result for one model does not test another.
- Match controls to the risk. Low-risk internal productivity work can use minimal logging. Customer-facing or operational-data work can use standard guardrails and audit trails. High-risk work involving personal information, finance, or regulated activity can use enhanced logging, human-in-the-loop review, and isolated environments. Classify the work before selecting the control level, since the three tiers call for different oversight.
- Constrain tool permissions. Adding a tool gives an agent a new capability with its own security considerations, while unrestricted tool access is a vulnerability in agent systems. Inspect which tools the agent can reach and which permissions those tools carry. Poorly constrained agents can leak private information or misinterpret instructions. Malicious prompts or poisoned data can also cause them to bypass safeguards or behave unpredictably, so tool permissions and hostile inputs deserve separate checks.
- Record what changed and attribute the result. An evidence-driven harness-evolution loop can record change manifests and use next-round attribution. The manifest identifies the edit, while attribution connects the next round of evidence to that change. This keeps an explicit harness modification inspectable instead of leaving it inside a general claim that the agent learned.
- Keep a per-edit rollback path. The same harness-evolution pattern constrains self-modification through per-edit rollback. The rollback unit is the recorded edit, which keeps reversal attached to the change being evaluated. Test the rollback path at that unit. A broad reset does not show whether one attributed edit can be reversed.
A policy-as-a-package pattern can centralize governance, allow policy updates without application-code changes, and support compliance audits across projects. That is one documented way to make controls explicit around several applications. It does not replace model-specific evaluation, permission boundaries, attribution, or rollback.
The required control level depends on the work. Our comparison of agentic workflows and AI agents can help clarify the execution pattern, but the immediate action is smaller: take one adaptation in your current agent and run the four persistence checks. Name the changed object, record which boundaries it crosses, and keep the result with the change record.