Agentic Learning: Where the Behaviour Change Is Stored

Agentic learning is what happens when an AI agent's behaviour changes between one run and the next because of something it wrote down after the last run. Not retraining. A write to a store: a note, a summary, a rule, a saved "skill" that the agent will read back and act on tomorrow.

That definition sounds narrow. It is deliberately narrow, and it is the whole governance problem. Our position is simple: agentic learning is not a capability upgrade, it is an unversioned configuration change, performed by a non-human identity, with no change ticket, no reviewer, and in most deployments no rollback path. Everything else in this article follows from that one sentence.

A developer describing this on Hacker News in April 2026 put it more plainly than any vendor page has. Debugging why his coding agent had gone "squirrely," JohnMakin found its persistent memory file full of instructions that were wrong or self-contradicting. "The agent wrote down the wrong memory," he wrote, and he noted the deeper problem with the automated fix on offer: "you're kind of trusting it to audit its own memories."

The short answer: Before you deploy an agent that learns, you must be able to name every store its behaviour can be written to, who is allowed to write to each one, and how you revert a single bad write — because in current deployments, at least one of those three answers is usually missing.

Last updated: July 30, 2026.

The Write-Back Audit, applied to the five places an agent's behaviour is stored.

One honest disclosure before we start. We have not run a controlled experiment on any of the memory architectures below, and nothing in this article reports a first-hand LeapForce benchmark. Every measurement here is attributed to a published source you can open and check.

What Agentic Learning Actually Means

Agentic learning is the process by which an AI agent changes its own future behaviour from its own past experience, by writing to storage it will later read. The key word is writing. The model's weights do not move. What moves is the material the model reads on its next run — and that material is now partly authored by the agent itself.

The term arrives with baggage, because it already meant something else. In education research it describes human self-direction: Getting Smart's primer on agentic learning traces the term to the psychologist Albert Bandura and defines it as "self-directed actions aimed at personal growth and development based on self-chosen goals." That sense is decades older than the AI one, and it still occupies much of the first page of results for the phrase. Vendors then borrowed the word for software. Ema's version defines agentic learning as "a learning model where people and systems set goals, make decisions, and adapt through action instead of following fixed instructions," which merges the human and machine senses into one marketing frame.

Neither definition tells an operator anything actionable, because neither names a mechanism. The engineering literature does. A March 2026 survey, Memory for Autonomous LLM Agents, organises the field along three axes: temporal scope, representational substrate, and control policy. The first of those matters most for governance. It separates working memory ("whatever fits inside the current context window"), episodic memory (records of concrete experiences: individual tool calls, conversation turns, observations), semantic memory ("abstracted, de-contextualized knowledge"), and procedural memory ("reusable skills and executable plans").

Those four are what people mean by AI agent memory when they are being precise, and the last three are all long-term memory in the sense that matters: they outlive the session. Read that list as a governance list rather than a research one and something jumps out. Each of those four is a different physical place, with a different owner, a different retention policy, and a different answer to the question can we undo this. An agent that "learns" is an agent writing to at least one of them. If your architecture diagram does not distinguish them, your change-control process cannot either.

There is a fifth option the same survey covers separately: parametric memory, where experience is folded into the model's weights through fine-tuning or adapter modules. The survey is blunt about the trade-off. Parametric memory "offers seamless integration — the model just 'knows' things," but it "is hard to audit (where exactly in the weights is the user's birthday stored?), hard to delete from (machine unlearning is still immature), and expensive to update." Its conclusion is the practical one: "most deployed agents favor non-parametric, inspectable stores."

That is the ground truth behind almost every agentic learning claim you will be shown in a demo, and it is the most useful fact in this article for anyone evaluating agentic AI vendors. It is a row in a database, not a gradient step. Which is good news, because a row can be read, reviewed, dated, attributed and deleted. The bad news is that in most deployments nobody is doing any of those five things.

Vendor pages usually describe agentic learning through a list of traits rather than a list of stores — context awareness, goal-driven reasoning, memory that persists across tools, adaptive workflows, a feedback loop that changes behaviour. Those traits are real, and each one is a control surface once you ask where it is physically implemented. The translation is mechanical:

Read the right-hand column and the article's argument is already made. Every desirable trait resolves to a store, and every store resolves to a permission and a rollback question.

What Agentic Learning Is Not

Agentic learning is not model training, not fine-tuning, and not the same thing as an agent being good at its job. It is a specific mechanism, durable state written by the agent and read back by the agent, and conflating it with the other three is what makes vendor claims impossible to evaluate.

It is not machine learning in the classical sense. Machine learning changes parameters through an optimisation process over a dataset, offline, under version control, with a model card and an evaluation run. Agentic learning changes text in a store, online, mid-shift, with no evaluation run at all. The two have opposite operational properties: the first is slow, expensive and reviewable; the second is instant, cheap and invisible.

It is not the agent getting smarter. Nothing about a write-back loop guarantees the written material is correct. The Hacker News account above is the ordinary case, not an edge case: an agent recorded a rule, the rule was wrong, and the wrongness compounded quietly until behaviour degraded enough for a human to notice. The 2026 survey names the same failure at research scale — a whole open-challenge section on "trustworthy reflection," because an agent that generalises from three unrepresentative failures writes a confident, durable, wrong heuristic.

It is not memory in the human sense, and the analogy costs you. Human memory decays; agent memory is a persistent record with no natural half-life unless someone engineers one. The survey notes that of the current benchmark suites, "only MemoryAgentBench tests selective forgetting explicitly," and that of the systems evaluated, "most fail conspicuously on selective forgetting." Forgetting is the feature nobody ships and every compliance team assumes exists.

It is not the same as retrieval. Retrieval-augmented generation reads from a corpus humans curate. Agentic learning writes to a corpus the agent curates. Those are different governance problems with different owners, and we have treated the read side separately in our analysis of knowledge management governance for AI that retrieves. This article is about the write side.

It is not something the Model Context Protocol gives you. MCP standardises how an agent calls tools; it carries no durable state of its own, a point we have made at length in our earlier analysis of MCP as a tool protocol rather than a memory layer. If a vendor tells you memory comes with MCP support, that answer is wrong in a way that is easy to check.

Where the Behaviour Change Is Actually Stored

Agentic learning has five possible homes, and they differ on the only four properties an auditor cares about: who can write, whether the write survives the session, whether a human can read it, and whether a single bad entry can be reverted without destroying good ones.

Two rows deserve a warning label.

Semantic memory is where provenance dies. The survey gives a clean illustration: an episodic fact such as "the user corrected the date format on Jan 5, Jan 12, and Feb 1" may consolidate into the semantic record "user prefers DD/MM/YYYY." That consolidation is exactly what makes semantic memory useful, and it is also the step at which the three source events stop being attached to the conclusion. Once the summary is the only artifact, you cannot audit whether the generalisation was warranted. The same survey proposes tying reflections back to their evidence for precisely this reason — if a reflection such as "API X is unreliable" must point to three concrete failure instances, the agent is less likely to generate baseless generalisations, and a human reviewer inherits "an auditable trail."

Parametric memory is where deletion dies. If a customer exercises a deletion right and their data has already been folded into weights, external deletion is not enough. The survey states the position without hedging: machine unlearning "is the only path, and it remains far from production-ready," and calls the intersection of agent memory governance and machine unlearning "an urgent open problem."

There is a sixth place people forget, and it is the one that bites operationally: the surrounding configuration — prompt files, tool allowlists, connector scopes, approval thresholds. A June 2026 survey of always-on agents, Always-On Agents, makes this explicit by defining the operative system as including not just retrievable memories but "task ledgers, permissions, credentials, commitments, provenance and audit records, shared state, trigger conditions, and externally committed effects." Its authors coded 435 works and found that the literature "concentrates more heavily on accumulating and retrieving state than on governing, recovering, or relinquishing it."

That imbalance in the research mirrors the imbalance in most deployments exactly. Everyone builds the write path. Almost nobody builds the revert path.

The Write-Back Audit: Six Questions, One Sitting

The Write-Back Audit is a diagnostic you can run against any agent in an afternoon, without vendor cooperation and without instrumenting anything. It has six questions, and the useful output is not a score — it is the list of questions you could not answer.

1. Where does this agent write? Name every store from the table above that the agent can write to, by system name, not by category. "It has memory" is not an answer. "It writes to a Postgres table called agent_memories and a per-workspace NOTES.md" is. If the store belongs to a vendor and you cannot see inside it, that is itself the finding: write down "opaque, vendor-managed" and treat every later question in this audit as failed until the vendor answers it in writing.
2. Who authorises the write? For each store: does a human approve entries, does a rule filter them, or does the agent write unattended? Unattended writes are not automatically wrong — but they are configuration changes made by a non-human identity, and they should be recorded as such. We have argued elsewhere that every agent needs an owner, a scope and an expiry; the write path is where that ownership stops being theoretical.
3. Is the entry attributable? Can you look at any single memory and say which run produced it, from which input, on which date? If the answer is no, you cannot investigate an incident, only guess at one.
4. Can you revert one entry? Not "can you wipe memory" — anyone can wipe memory, and wiping is how you lose six months of legitimate learning to fix one bad row. Single-entry rollback is the real test.
5. What is the blast radius of a bad entry? A wrong preference in a drafting agent costs a re-write. A wrong approval threshold in a payments agent costs money. The store is the same; the exposure is not. This is the same question as the autonomy budget, asked about writes instead of actions.
6. Who reviews the delta? Somebody should be able to answer "what did this agent learn last month, and does any of it look wrong?" If nobody owns that question, learning is running without a reviewer.

Question four is the one that fails most often, and the reason is architectural rather than negligent. Most memory layers were designed as caches, and caches are built to be flushed, not to be diffed. Retrofitting per-entry versioning onto a vector index after the fact is real engineering work, which is why the honest answer for many teams is to run agents with append-only, human-reviewed procedural memory and no autonomous semantic consolidation at all until the revert path exists.

Question six is the one nobody has ever been asked. Try it on your own deployment: name the person whose job it is to read what your agents wrote last month. In most organisations that person does not exist, which means agentic learning is the only production configuration change with no reviewer at all.

Worked Example: The Expense Agent That Learned a Rule Nobody Wrote

Here is agentic learning failing, traced end to end. It is a constructed example built from the mechanisms above rather than a customer story, and it is written out fully because the abstract version of this argument persuades nobody.

Setup. A finance operations team deploys an agent that triages expense claims. It reads the claim, checks it against policy, and either routes it for approval or auto-approves it under a threshold. It has episodic memory of every claim it processed and a semantic-memory step that consolidates recurring patterns into short preference records it reads on every run.

Week 1. A regional controller manually overrides the agent three times, approving meal claims from one office slightly above the threshold, because that office's per-diem is set differently in a policy document the agent never had. Each override lands in episodic memory as an observation with a timestamp.

Week 3. Consolidation fires. Three episodic observations collapse into one semantic record of the form claims from this office under this amount are approved. That record is now nine words long, carries no reference to the three source events, and does not mention that the source of truth was a human exercising judgement rather than a written rule.

Week 4 onward. The agent applies the record. It auto-approves claims that policy does not permit. Each auto-approval is itself a correct-looking event that reinforces the pattern, because the agent has no signal distinguishing "nobody objected" from "this was right."

Week 11. An audit sampling finds the discrepancy. Now run the Write-Back Audit against this incident:

Four of six questions failed, and none of the four failures is about model quality. The model behaved correctly at every step: it observed a pattern, generalised it, and applied it. The defect was that a policy change was made by summarisation instead of by a person, and the system had no place to catch that.

The fix is not a better model. It is a rule that says semantic consolidation of anything touching an approval threshold requires a human sign-off, plus provenance pointers on every consolidated record, plus a monthly delta review. All three are ordinary change-management controls. None of them are novel. They are simply not applied to agent memory yet, because agent memory does not look like configuration to the people who own configuration.

If it helps, borrow the framing from our action ledger analysis, which asks what an agent did. The Write-Back Audit asks the adjacent question: what did the agent become, and who signed off on it.

Does Agentic Learning Actually Work? What the Measurements Say

The measured picture is far less flattering than most agentic AI marketing, and the most important recent result argues that a good deal of published memory-module improvement disappears once you control for the tokens the modules consume.

That result comes from a June 2026 study, Are Online Skill and Memory Modules Always Worth Their Tokens?. The authors compared three widely cited agentic-learning approaches, AWM, ASI and ReasoningBank, against a plain baseline given the same total inference budget to spend on extra actor steps instead. Their finding, across three WebArena domains and three models: "the vanilla baseline matches or surpasses all three augmentation methods in aggregate success rate while often using fewer total tokens." They saw the same trend on WorkArena-L1, which they note "indicat[es] that the effect extends to enterprise knowledge-work tasks." Their conclusion is not that memory is useless. They allow that skills and workflow memory "can be useful in specific domains," but hold that "their apparent gains often vanish against a budget-matched actor."

That is the single most useful sentence a buyer can carry into a vendor meeting. When a demo shows an agent improving over ten runs, the question is not "did it improve" but "did it improve more than simply letting the plain agent think longer for the same money."

The same study adds a second warning that almost never appears in a vendor benchmark: "run-to-run variance materially affects outcomes and should be reported as a core evaluation criterion." A single before-and-after pair proves nothing about a stochastic system.

Set against that, the case for memory in the literature is real but narrower than advertised, and it is strongest for procedural memory. The 2026 memory survey cites the Voyager system, whose skill library was worth a 15.3× difference in tech-tree milestone speed in Minecraft. "The skill library was the performance," the survey says. It also cites the Generative Agents result, where removing the reflection component caused behaviour to "degenerate from coherent multi-day planning to repetitive, context-free responses within 48 simulated hours."

And the ceiling is measurable too. The survey reports that on MemoryArena, a 2026 benchmark of multi-session interdependent tasks, models that score near-perfectly on the older LoCoMo benchmark "drop to 40–60%." Near-saturation on a single-session recall benchmark predicts very little about performance when later work depends on what was learned earlier — which is exactly the enterprise case.

The Cost Line Nobody Prices: Memory Overhead Per Run

Memory is not free, and it is not a storage cost — it is a per-run inference cost, paid on every task, whether or not the memory helps. That is the finance framing missing from every agentic learning explainer we surveyed.

The mechanism is simple. Retrieved memories are injected into the prompt. Reflection and consolidation are themselves model calls. A memory-augmented agent therefore pays for (a) the retrieval call, (b) the retrieved tokens on every subsequent turn, and (c) the periodic consolidation pass. The budget-constrained study above describes this overhead as "consum[ing] test-time tokens, a cost rarely reported alongside the actor's inference cost," and its entire method exists because that cost is normally invisible.

The 2026 memory survey makes the same complaint about the research literature: "None of the current benchmarks systematically report efficiency metrics alongside effectiveness, making it difficult to assess whether reported gains are 'free' or come at significant operational expense." It also states the obvious trade-off plainly — a memory system that achieves 5% higher accuracy but triples latency and storage cost "may not be an improvement in practice."

Three practical consequences for anyone budgeting an agent programme:

Memory cost scales with traffic, not with team size. A memory store used by an agent handling 200 tickets a day is charged 200 times a day. Classic software licensing intuitions do not transfer.

The cost is unbounded by default. An adaptive multi-step agent has no natural ceiling on how many steps it takes or how much context it pulls in. Without a per-agent ceiling this becomes the finance surprise, which is why we argue budgets should be denominated in dollars per agent and per team rather than in tokens — the same argument we make about routing spend across models and about the cost lines that sit outside the licence.

The right control is a budget-matched pilot, not a benchmark. Run your agent with memory and without, on the same task mix, with the same total spend cap, and compare completion rates. That is a two-week exercise. It is also the only version of the question a CFO will accept.

Because we will not invent numbers, here is the arithmetic instead of an example bill. Monthly memory overhead equals (retrieved tokens injected per turn × turns per task × tasks per month) plus (consolidation passes per month × tokens per pass), multiplied by your model's input price. Every one of those five inputs is measurable from your own traces inside a week, and none of them is knowable from a vendor datasheet. Run it once for a single agent before you extrapolate a fleet.

We could not obtain vendor-published per-run memory overhead figures for any major agent platform while writing this — the numbers are not disclosed, and we will not estimate them. Treat any vendor unwilling to quote a per-run token overhead for their memory layer as quoting an unbounded one.

Learning Turns a Session Bug Into a Permanent One

This is the security argument, and it is the one that should decide whether agentic learning is allowed to run unattended at all: an agent that learns converts a temporary compromise into a durable one. A prompt injection that only affects one session is an incident. A prompt injection that gets written to memory is a policy change.

The canonical demonstration is public and old enough to be uncontroversial. In February 2025 security researcher Johann Rehberger showed that Gemini's long-term memory could be written by an attacker using a technique he calls delayed tool invocation. It was a consumer product rather than an enterprise agent, but the mechanism is the same one every agent vendor is now shipping. The attack runs like this: a poisoned document plants instructions plus a trigger word into the chat context, and when the user later replies with an innocuous "yes," the memory tool fires and the attacker's false facts are saved. As his write-up puts it, the result is "a persistent, attacker-controlled memory entry that can survive across multiple sessions." Google assessed the risk as low likelihood and low impact; Rehberger's counterpoint is that the impact on an individual user "can still be significant."

The pattern is now formalised. OWASP's Top 10 for Agentic Applications, released in December 2025, lists ASI06 – Memory & Context Poisoning as its own category, describing how "memory poisoning reshaped behaviour long after the initial interaction."

The most alarming numbers come from a June 2026 security analysis of self-evolving agent systems, Safety in Self-Evolving LLM Agent Systems. The authors decompose the attack surface into a five-by-five matrix of modules and lifecycle stages, and report that of the 25 resulting cells, "17 face critical threats for which no effective partial mitigation" exists. Comparing two open-source frameworks, they found that evolution-native design "activates 3.5× more attack surface cells and achieves a 100% attack persistence rate (40/40 payloads across all CIA+Privacy categories), while co-located security scanners block only 2.5% of attacks." Their summary sentence is the one to quote in a design review: self-evolution "converts every known attack category from session-bounded to lineage-persistent."

Read that alongside the write-path controls proposed in the SSGM governance framework, a March 2026 paper whose core architectural move is to "decouple memory evolution from execution" — enforcing consistency verification, temporal decay and dynamic access control before any memory consolidation, rather than after. That is the same shape as every mature change-control system: a gate between proposing a change and committing it.

The operational takeaway is unglamorous. If an agent can be reached by untrusted content, whether that is a shared inbox, a customer message, a scraped page or an uploaded document, then either its write path needs a gate, or its memory needs to be session-scoped. Those are the only two safe configurations, and "we'll monitor it" is not a third.

What Regulators Already Say About Systems That Keep Learning

Regulators anticipated agentic learning under a different name and wrote a specific rule for it, and the rule is more permissive than most people expect — but the permission is conditional on documentation you have to write in advance.

Under the EU AI Act, a substantial modification is defined in Article 3(23) as "a change to an AI system after its placing on the market or putting into service which is not foreseen or planned in the initial conformity assessment carried out by the provider" where it affects Chapter III Section 2 compliance or changes the assessed intended purpose. A substantial modification triggers a fresh conformity assessment.

Then comes the carve-out. Article 43(4) states that for high-risk AI systems "that continue to learn after being placed on the market or put into service, changes to the high-risk AI system and its performance that have been predetermined by the provider at the moment of the initial conformity assessment and are part of the information contained in the technical documentation" do not constitute a substantial modification.

Read those two provisions together and the compliance design falls out. Learning inside a pre-declared envelope is fine. Learning outside it is a modification with regulatory consequences. So the operative question for a high-risk deployment is not "may our agent learn" but "did we write down, in advance, the boundaries of what it may learn?" An agent with unbounded semantic consolidation across arbitrary content is very difficult to describe as a pre-determined change.

Article 72 adds the monitoring duty. Providers must establish a post-market monitoring system that "actively and systematically collect[s], document[s] and analyse[s] relevant data … on the performance of high-risk AI systems throughout their lifetime," sufficient to evaluate "continuous compliance." The Commission was required to adopt an implementing act with a template for that plan by 2 February 2026. A learning agent whose behaviour deltas are not recorded cannot produce this evidence at all.

The American framework is voluntary but points the same way. NIST's AI Risk Management Framework 1.0 sets out subcategory MANAGE 4.1: "Post-deployment AI system monitoring plans are implemented, including mechanisms for capturing and evaluating input from users and other relevant AI actors, appeal and override, decommissioning, incident response, recovery, and change management." Appeal, override, recovery and change management are exactly the four things a memory store without per-entry rollback cannot support. The same document also warns that AI systems "may require more frequent maintenance and triggers for conducting corrective maintenance due to data, model, or concept drift."

None of this is exotic. It is the same evidence a change-advisory board has asked for since ITIL, applied to a component that happens to reconfigure itself. Our analysis of audit trails for agent actions covers the action side of that record; the learning side needs the same treatment.

A Change-Control Policy for Agents That Learn

Here is the agentic learning policy we would write on day one of an agent programme. Five rules, in order of how much they buy you per hour of work.

1. Classify every store before the agent ships. Use the five-row table above. For each store the agent can write to, record the system name, the owner, the retention period and the rollback mechanism. A store with no named rollback mechanism does not get autonomous writes. This is a one-page artifact and it prevents the single most common failure, which is discovering during an incident that nobody knew the agent had a second memory.

2. Gate consolidation, not observation. Episodic writes, the plain "this happened, at this time" kind, are cheap, attributable and safe to record. Let them run unattended. Semantic and procedural writes are where a new rule is created, and those get a gate: a human reviewer, an allowlist of permitted subjects, or both. This mirrors the SSGM design principle of separating memory evolution from execution, and it is far cheaper than reviewing everything.

One correction to that rule, because it is where the argument is most often over-simplified. Episodic writes are safe to record but not automatically safe to learn from: a poisoned document lands in episodic memory as an ordinary observation and only becomes dangerous when consolidation promotes it. So tag each episodic entry with the trust level of its origin: internal system, authenticated colleague, or untrusted external content. Then make consolidation ignore the untrusted tier by default. Without that tag, "gate consolidation" is a gate with no criteria to apply.

Episodic logs also carry a retention clock that nobody assigns them. A record of what a customer said, when, and what the agent did about it is personal data in most jurisdictions, and the fact that it lives in a memory store rather than a CRM does not exempt it. Give each store a retention period at classification time, not after a data-subject request arrives.

3. Require provenance on every consolidated record. Each semantic or procedural entry carries pointers to the source events that produced it, the date, and the agent identity that wrote it. Without this, incident investigation is guesswork; with it, the expense-agent scenario above resolves in minutes rather than days.

4. Schedule a learning delta review. Monthly is enough for most agents; weekly for anything with financial or customer-facing blast radius. The reviewer reads what was added since the last review and answers one question: does any of this look like a policy decision? Anything that does gets escalated to whoever owns that policy. Put the reviewer's name in the agent's record, next to the owner's.

The usual objection to rule 4 is that nobody has time, and it is a fair one — so size it honestly before you commit to it. The review reads consolidated records only, not the episodic log, and a single well-scoped agent typically produces a handful of those a month rather than thousands. If your agent generates more consolidated rules per month than a person can read in twenty minutes, that is not a reason to skip the review; it is a signal that consolidation is firing too eagerly and the allowlist from rule 2 is too wide.

5. Set the write path's blast radius explicitly. Agents that can be reached by untrusted content get session-scoped memory only, until a validated write gate exists. Agents whose learned rules can move money, grant access or contact customers get human approval on every semantic write, permanently — not as a pilot phase. Approval gates are a control, not a training-wheel, an argument we make in full in our piece on when human approval is genuinely the control.

Sequencing matters as much as content, and here the rollout pattern we use for gateway deployments transfers cleanly: Observe first. Enforce second. Optimize third. Turn on the trace before you turn on the gate. A month of watching what your agents actually write will tell you which stores deserve enforcement, and it will almost certainly show you a store you did not know existed. Enforcing first, on guesses, produces gates in the wrong places and a team that routes around them.

If you do only one thing, do rule 1. The store inventory is the cheapest defensible position available: it costs an afternoon, it requires no engineering, and it converts "our agent has memory" from a marketing sentence into a list of named systems with named owners. Every other rule here is easier to argue for once that list exists, because the list is what makes the gaps visible to people who do not read AI research.

A prerequisite check before any of this. You need three things in place or rule 3 is unimplementable: an identity per agent (not a shared service account), a trace that captures writes and not only actions, and a store whose entries are individually addressable. If any of the three is missing, fix that first — the policy above assumes them.

Agentic Learning vs Machine Learning vs Fine-Tuning

These three get used interchangeably in vendor copy and they are operationally opposite. The distinction that matters is who authorises the change and how fast it takes effect.

The row that should shape your architecture is the last one. Non-parametric agentic learning is the only one of the three where a deletion request can be honoured by deleting something. That is a strong argument for keeping learned behaviour out of weights entirely in any system touching personal data — which is also the direction the research reports deployments already taking.

Where This Is Still Uncertain

Several parts of this argument about agentic learning rest on evidence that is thin, recent, or contested, and it would be dishonest to present the whole thing as settled.

The budget-matched result is one paper. The finding that memory modules' gains often vanish against a token-matched baseline comes from a single June 2026 study covering three WebArena domains, WorkArena-L1 and three models. It is a careful study and its method is the right one, but it has not yet been replicated across other benchmark families or production workloads. We treat it as the strongest available evidence rather than as a settled result, and we would change this article if a well-designed replication went the other way.

Benchmarks are not your workload. WebArena and MemoryArena are research environments. An agent that fails on interdependent multi-session tasks in a benchmark may do fine on your narrow, well-specified process, and vice versa. Nothing here substitutes for a budget-matched pilot on your own task mix.

The regulatory reading is ours, not a regulator's. The Article 43(4) carve-out has not, as far as we can find, been tested by a supervisory authority against an LLM agent with semantic memory. Reading "pre-determined changes" to cover a declared learning envelope is a reasonable interpretation, not a confirmed one. If your deployment is high-risk under Annex III, take actual legal advice rather than a blog's reading.

We have not tested any of these platforms. This article contains no first-hand benchmark, no LeapForce-run experiment, and no customer telemetry. Every number is attributed to a published source. Where we could not verify something, vendor per-run memory overhead being the clearest case, we have said so rather than estimated.

Provenance-on-consolidation may cost more than we imply. Attaching source pointers to every consolidated record adds storage and write latency, and the survey we lean on describes it as an open research direction rather than a solved engineering pattern. Teams should pilot it on one agent before mandating it across a fleet.

Some sources a reader would expect are missing. Gartner's widely quoted prediction on agentic AI project cancellations was unreachable from this machine at every fetch tier, so it is excluded rather than cited second-hand. Vendor per-run memory pricing is not published by any major platform we checked.

Where LeapForce Fits

LeapForce does not sell a memory layer, a vector database, or an agent framework, and nothing above should be read as a pitch for one. What we build is the governed layer those things run inside: one controlled endpoint for every AI tool, connector, model and agent, so that identity, policy, cost and audit are enforced on the call rather than promised in a wiki. In the language of this article on agentic learning, that is where the answers to Write-Back Audit questions 2, 3, 5 and 6 physically live — the agent has its own non-human identity with an owner and an expiry, its connector scopes are set at action level, its spend is bounded per agent in dollars, and its activity is traced. Per our published build status, gateway enforcement, tracing and SSO are live today, while several adjacent capabilities are still in development; we label them that way on the product pages rather than in retrospect.

Ready to Govern Your AI?

Talk to LeapForce — one controlled layer for every AI tool, connector, model, and agent.