Your AI Agent Keeps Making the Same Mistakes - Sparsh Jain, CentralAgent AI

A senior executive at a hedge fund described a frustrating pattern to Sparsh Jain, Head of AI at CentralAgent AI. Someone would correct an agent and get the work back on track. In the next session, or when another team used the agent, it would make the same mistake. Each correction helped the person who made it. The next person still had to know enough to catch the error.

Jain’s team had worked with the same agent for two years and recognized the problem. Their early approach was to give the agent all the context they could gather and let it work out what mattered. That helped while the context was small. At enterprise scale, Jain reported that gathering and processing more facts took longer, cost more, and eventually reduced accuracy. The team needed a way to preserve the judgment an engineer had exercised when correcting the agent, then bring that judgment back when it applied.

CentralAgent AI distinguishes working memory, the material an agent uses during an active session, from long-term memory. Long-term memory has two parts. One holds facts. The other holds what the team learned by acting on those facts and seeing an outcome. A session can contribute both. The durable lesson is the part that could change how the agent approaches a later task.

Jain described three ways to keep a lesson. A case preserves the detailed situation and what the team learned from it. A strategy records what worked under particular circumstances, giving the agent an approach to try when those circumstances recur. A skill captures something the team can generalize well enough for repeated use. The distinction matters when deciding what to extract from a correction. If the circumstances explain why a decision worked, keeping them with the case gives a future agent the information it needs to judge whether the lesson transfers.

A useful strategy can go stale as data, systems, and operating conditions change. Jain’s team organized memory around three operations. Formation captures a new fact or experience. Updating revises an existing note, deactivates one that has lost its usefulness, or forgets material that has ceased to matter. Retrieval determines which of those records the agent sees for the task at hand.

Updating revealed a subtle failure. Suppose the agent keeps only the team’s latest judgment. It can reach the old judgment again because it has lost the history that led the team to revise it. The team’s solution was to keep superseded notes inactive. A routine lookup consults active notes. A deeper investigation can consult the inactive ones as well and trace how the judgment changed. That gives the investigator access to an earlier conclusion without presenting it as current guidance in every session.

Deactivation and forgetting serve different purposes. A superseded note can still explain a decision. Other accumulated material has little bearing on either the decision or its history. Keeping all of it in contention recreates the original context problem, with too many items competing for attention. The system therefore needs both a way to retain consequential history and a way to let irrelevant material go.

Jain illustrated the retrieval problem with a hypothetical trip home. He has a home in San Francisco and another in New York. As he leaves his San Francisco office, he asks his agent for directions home. Both addresses are correct, and both match the request. If the retriever surfaces the New York address, the agent can produce perfectly serviceable directions to the wrong coast. The circumstances of the request supply the distinction that the word “home” leaves out.

The same dependency holds for experiential memory. The team may already have recorded a relevant case, revised its strategy, and retired an obsolete conclusion. All that work benefits the next session only if the retriever surfaces the judgment that fits. Jain reported a concrete gain where the agent had gathered context before and knew what to gather again. In many such cases, context gathering fell from about 20 minutes to two. He also reported lower token use and better performance on long-running tasks. The timing figure applies specifically to that repeat context-gathering work.

Even after the team could form, update, and retrieve lessons, maintaining them was manual. Jain described adding observability around those operations, followed by a recurring evaluation loop. After a session or at the end of a day, the loop extracts lessons, identifies material to clean up, and revises which records deserve priority. It tests proposed changes independently before applying them to the live system. Jain calls these maintenance passes “dreaming cycles.”

The enabling change, in Jain’s account, was that a model could act as a verifier for work that had previously required a person to review each item. He outlined the order of operations but left the evaluation design and security guardrails for another talk. That distinction matters for implementation. A recurring job can propose memory edits. Deciding what evidence qualifies an edit for live use is a separate engineering decision.

For a shared agent, the payoff appears at the handoff between teammates. One engineer catches a mistake, the review loop extracts and checks the lesson, and another engineer encounters a similar situation. The practical test is whether the second session retrieves enough of the first engineer’s judgment to handle the task correctly. Counting stored sessions tells the team how much work it has recorded. Watching what happens at that handoff tells it whether the agent learned anything.