Beyond simple prompt-response paradigms. We are building the foundational architecture for agents that compute context, construct memories, and learn dynamically over time.
Agents are expected to be able to learn. This is accomplished by “automatically” updating an agent’s knowledge base.
First, what is an agent’s knowledge base? This is the set of “data” objects the agent can access. This could be data on the organization level to which the agent has been granted access or data that is added directly to the agent. Each data item has an ID with which event handlers (like LLM-based message processors) can fetch the data content and make it available to whatever LLM or system they choose.
To implement “learning” on an agent, we have to “automatically” update its data objects. We do this by creating data objects that represent different kinds of memories. These data objects are created using data providers that are designed to create different kinds of memories from conversations agents are having. These data objects are also configured to be updated regularly.
Human-like recall requires more than text search. We engineered five specialized memory structures, constantly synthesizing and abstracting.
This is information that is temporarily stored during a single session or conversation. To achieve this, we simply provide the current conversation (with its messages) to the message processors. A message processor is most likely an LLM with a generous context window.
This is memory that persists across sessions or conversations. To achieve this we simply provide data to the agent and make said data available to message processors. A message processor is most likely an LLM to which files can be uploaded. Each data of the agent can be uploaded as a file to the LLM or added as an attachment to the conversation with the LLM. For LLMs that have no such feature, the message processor can create embeddings from the agent data and store them in vector data stores.
This memory stores time-based events. To achieve this, we extract time-related information from the last few conversations of the agent and compare/combine that with the existing episodic memory to produce a new episodic memory. This has to be done automatically by using a data provider that runs on schedule.
This memory stores learned knowledge, facts, or summaries about users and topics over time. To achieve this, we extract information that is worth remembering from the last few conversations of the agent and compare/combine that with the existing semantic memory to produce a new semantic memory. This has to be done automatically by using a data provider that runs on schedule.
This memory stores shared information among agents. To achieve this, the data object for the consensus memory should be created on the organization, and not on a particular agent. Every agent in that organization can then be granted access to this data object. The data object is created by a data provider that can access the last few conversations of every agent in that organization and extract relevant pieces of information from the conversations.
Note: When creating memories, consider if it’s a personal assistant or a public assistant; memories are typically more relevant to personal assistants.
const agent = createAgent({
id: "hr-assistant-lagos",
knowledgeBase: [
"org://policies/handbook-2025",
"org://hr/leave-schedule",
"personal://user-semantic-memory"
],
memory: {
shortTerm: true, // live session
longTerm: "vector-store", // embeddings
episodic: "cron:0 2 * * *",
semantic: "cron:0 3 * * 1",
consensus: "org://shared"
},
priming: {
instructions: [
"Be concise and action-oriented",
"Escalate blockers proactively",
"Localise responses for Lagos office"
]
},
channels: ["slack", "whatsapp", "teams"]
});Priming is a powerful tool to guide the language model's output, allowing users to customize the generated content based on specific requirements or preferences. It helps to fine-tune the model's responses for a more controlled and tailored interaction.
Priming is achieved by adding instructions to the message. These instructions will be sent as system messages to the LLM.
A thought is a transient piece of information shared in a conversation. A thought is not targeted at any participant in the conversation and, as such, is unavailable to event handlers in an agent. Apps or components displaying a conversation do not need to display thoughts. You can imagine thoughts to be the console.log of agents; they are mostly for diagnostic purposes.
The scientific brilliance of the ProteusAI research lab, materialized into an Enterprise-ready autonomous workforce.
OnBuddy instantly recognizes returning users, referencing past workflows precisely via our unified Episodic and Semantic pipelines. It feels like working with a colleague who never forgets.
When deployed as a public assistant, OnBuddy pools non-sensitive truths into a Consensus Memory object, granting your entire workspace a synchronized, highly intelligent assistant core.
Tailored natively for specific enterprise functions. An OnBuddy in HR acts, reasons, and "thinks" fundamentally differently than an OnBuddy deployed for DevOps, guided by dynamic system prompting.