Everyone can make agents now, thanks to LLMs. This includes small startups that are trying to build agentic automations to pre-existing and new use-cases, bigger enterprises trying to bring efficiency to their age-old workflows, and individuals trying to build agents to automate various digital tasks in their specific domain/work.
However, most agents are still static and stateless and for them to replace humans in long-term tasks would require them to have the ability to remember and learn from their experiences. Without the ability to learn from their own experiences, these agents would always be at day 1 (and not in a good way) at their job i.e. they would make the same kind of mistakes an inexperienced new employee would make on the first day and keep repeating it. Therefore, agents need memory to store their experiences, and not just memory, but the ability to learn from that memory of experiences. In addition, these agents should also share their learnings and experiences with other agents, so they can get better at their tasks, just like backend dev at a company might explain nuances of the API to the frontend engineers, so they can do their job without running into too many errors and bugs.
Once we have established that learning from memory is essential to have fully autonomous agents, we come to the next questions i.e. “can such a memory be created and maintained by the agent itself?”. We’ve more recently seen coding agents like claude-code and codex being able to use files as memory for agents, where agents regularly note down context inside text files and use those files to search for relevant context while doing subsequent tasks. While using files as “working” memory, along with bash tools like grep, has shown great promise, they’re not the equivalent of long-term memory due to lack of structure in the memory representation to enable fast and accurate evolution and retrieval. I’ve written about this topic in more detail in the blogpost titled “Why Files Are Not Enough as Memory for AI Agents”.
Having tackled the previous questions, we come to the next question i.e. what constitutes a memory and learning layer for an AI agent. An agentic memory and learning consists of 3 parts. 1) memory structure/representation, 2) evolution system, and 3) retrieval system. The structure is how the memory is stored i.e. knowledge graph, temporal knowledge graph, hierarchical tree, json-structured, tree structured, or a combination of some of the above etc. The evolution system decides how to add new knowledge to the memory and infer/record learnings from it. Lastly, the retrieval system controls what information to return when queried during a task. Any agentic task automation might require a combination of agents, each specialised in a specific type of task, and each such agent might require a different type of memory-structure and its corresponding evolution and retrieval systems. For example, a wild example of an agent trying to do marketing on instagram, would require a different memory to store images it creates and or retrieves from the internet, and a different memory to store the text that it considers would get more engagement on a particular topic based on past experiences. We haven’t even talked of how reinforcement learning can be used to evolve and retrieve the memory using either user/process supplied rewards or (LLMs as judge) generated rewards.
Having established what a memory and learning layer for an AI agent consists of, we can move to the last and final question of whether a company should build it in-house or buy it like a SaaS service. The short answer is “if you’re trying to build the absolute best agent for a specific task and are extremely sensitive to agent performance then you should build it in-house”.
In all other scenarios, you would be better off using an external system. This is not any different from using any saas services, that even though could be replaced with self-hosted open source software or built from scratch, is often not worth the headache of maintaining / optimising / upgrading etc.
One major challenge with multi-agentic systems is that each agent might require a different type of memory because of the nature of specialization expected from the agent. As an example, a multi-agentic system trying to generate photos, post them on twitter to do marketing, and simultaneously analysing the impact of such marketing on the bottom line, using different agents specialised for each of these tasks, would require a different kind of memory and learning for each of them. Building all those different types of memory and learning systems in-house would quickly make even simple multi-agentic systems bloated very quickly. An in-house system would also have to build the infrastructure to allow agents to continuously share each other’s learning and experiences, which would add further complexity to such a memory and learning layer. In more privacy-relaxed use cases, agents could even learn from similar agents built by other companies, and lead to improved performance, but this is not possible for agents built inside the security walls of an enterprise. Finally, as with any in-house software, the costs would fall solely on the company building it as opposed to shared across many other agents using the same memory and learning infrastructure.
Therefore, for all the above reasons, we believe in the vision for a company that can provide the memory and learning layer for the agents of the future. And that’s why we are building the technology for a memory and learning layer at versanovatech.com. Of course, we might turn out to be wrong and memory and learning layers might move in-house, but even in that eventuality, we would be left with a great technology that could be used to build state-of-the-art multi-agentic systems. We have already shown we can use versanova’s learning layer to build agentic applications such as novasheets.com and would continue to prove our tech on various benchmarks and real world agentic apps.
We would love to hear your feedback and whether you agree or disagree with us?