Agents & memory
Agents represent a significant step beyond single-turn model interactions. Where a standard AI assistant responds to a query in a single model call, an agent reasons about what needs to be done, decides which tools or actions to use, executes those actions, evaluates the results, and continues reasoning until the task is complete. Memory extends this capability by giving agents and assistants access to information from prior interactions, enabling continuity and context-awareness across conversations, sessions, and long-running processes.
On GLBNXT Platform, the components needed to build agent systems and implement memory are available as managed services within your environment. This section explains how agents work, the memory patterns available on the platform, and how to design agent architectures that are reliable, controllable, and ready for production.
What Agents Are For
Agents are the right architectural choice when a task is too complex to complete in a single model interaction, requires access to external information or systems, involves multiple steps that depend on each other, or needs to adapt its approach based on intermediate results.
Common use cases for agent architectures include:
Research and analysis tasks that require retrieving information from multiple sources, synthesising findings, and producing a structured output
Technical support agents that diagnose issues by querying system data, running checks, and proposing or executing remediation steps
Financial and legal analysis agents that work through complex documents, cross-reference multiple sources, and produce annotated summaries or recommendations
Case management agents that gather information, apply reasoning to determine the appropriate course of action, and update downstream systems accordingly
Automated reporting agents that retrieve data, perform analysis, generate narrative content, and assemble complete reports without manual coordination of each step
If your use case requires AI to plan, act, observe, and adapt rather than simply respond, an agent architecture is the appropriate choice.
How Agents Work
An agent operates through a reasoning loop. At each step in the loop, the agent receives the current state of the task, reasons about what action to take next, executes that action using an available tool, observes the result, and then repeats the loop until the task is complete or a stopping condition is reached.
This loop is often described as a think-act-observe cycle. The agent thinks about what to do next based on the task goal and the information available to it. It acts by calling a tool, retrieving information, or generating an intermediate output. It observes the result of that action and uses it to inform the next iteration of reasoning.
The key difference between an agent and a standard model call is that the agent drives the process. It decides which tools to use, in what order, and when the task is sufficiently complete. The developer defines the tools available, the boundaries within which the agent operates, and the goal it is working toward. The agent determines how to get there.
Tools and Tool Use
Tools are the mechanism through which agents interact with the world outside the language model. A tool is a defined capability that the agent can invoke as part of its reasoning process. When the agent decides that a tool is needed, it generates a structured call to that tool with the appropriate inputs, the tool executes and returns a result, and the agent incorporates that result into its next reasoning step.
Tools available to agents on GLBNXT Platform can include:
Vector database search for retrieving relevant information from indexed knowledge sources
Database queries for accessing structured data in Postgres or other connected data stores
API calls to external services for retrieving live data or triggering actions in third-party systems
File operations for reading from and writing to object storage
Workflow triggers for initiating automated processes as part of an agent task
Custom functions developed by your team that encapsulate specific business logic or proprietary data access
The set of tools an agent has access to defines what it is capable of doing. Designing the right tool set for an agent is one of the most important decisions in agent architecture. Tools should be precise in what they do, well-documented in how they are called, and scoped to what the agent genuinely needs to accomplish its task. Giving an agent access to tools it does not need increases the risk of unintended actions and makes the agent's behaviour harder to predict and control.
Single-Agent vs. Multi-Agent Architectures
Single-Agent Systems
A single-agent system uses one agent with access to a defined set of tools to complete a task end-to-end. This is the right starting point for most agent use cases. Single-agent systems are simpler to design, easier to debug, and sufficient for a wide range of tasks that involve sequential reasoning and tool use without requiring coordination between multiple specialised capabilities.
Single agents work well when the task has a clear goal that can be pursued by one reasoning process, when the tools required are manageable in number and scope, and when the complexity of the task does not exceed what a single context window can handle effectively.
Multi-Agent Systems
Multi-agent systems coordinate multiple agents, each with a defined role and specialised set of tools, to complete tasks that are too complex or too large for a single agent to handle well. An orchestrator agent typically manages the overall task, delegating subtasks to specialist agents and synthesising their outputs into a final result.
Multi-agent architectures are appropriate when a task can be clearly decomposed into subtasks that benefit from specialised handling, when different parts of a task require different tool sets or reasoning approaches, when the total context required for the full task exceeds what can be managed in a single agent loop, or when parallel execution of independent subtasks would meaningfully reduce the time to completion.
Common multi-agent patterns on GLBNXT Platform include:
Orchestrator and worker: an orchestrator agent receives the top-level task, decomposes it into subtasks, delegates each subtask to a worker agent, collects the results, and produces the final output
Pipeline agents: agents arranged in sequence where the output of one agent becomes the input to the next, each applying a different kind of processing or reasoning to the data as it passes through
Parallel agents: independent agents working on different aspects of a task simultaneously, with results aggregated by an orchestrator once all agents have completed their work
Supervisor and specialist: a supervisor agent monitors the outputs of specialist agents and applies quality checks, routing, or escalation logic based on what the specialists produce
Multi-agent systems introduce additional complexity around coordination, state management, and error propagation. They should be introduced when there is a clear need for them, not as a default architecture for every agent use case.
Memory
Memory gives agents and assistants the ability to retain and recall information across interactions. Without memory, every conversation or agent execution starts from scratch, with no awareness of what has happened before. With memory, agents can build on prior context, maintain continuity across sessions, and adapt their behaviour based on accumulated information about a user, a task, or an environment.
On GLBNXT Platform, memory is implemented at the application layer using the storage services available in your environment. There is no single memory system that works for every use case. The right memory pattern depends on what information needs to be retained, for how long, and how it needs to be retrieved.
Session Memory
Session memory retains context within a single conversation or agent execution. It allows a conversational assistant to refer back to what was said earlier in the same exchange, or an agent to maintain awareness of the steps it has already taken within a single task execution, without storing that information beyond the end of the session.
Session memory is typically implemented by maintaining the conversation history or execution trace in the model's context window during an active session. When the session ends, the session memory is not retained. This is the simplest form of memory and is appropriate for use cases where continuity within a session is valuable but cross-session persistence is not required.
Persistent Memory
Persistent memory retains selected information across multiple sessions, giving agents and assistants access to context that accumulates over time. This might include facts about a user, the outcomes of previous tasks, preferences established in prior interactions, or the state of a long-running process that spans multiple sessions.
Persistent memory is implemented using Postgres for structured memory and vector databases for semantic memory. Structured memory stores discrete facts, preferences, or state as rows in a database that can be retrieved by key or queried by attribute. Semantic memory stores richer information as embeddings in a vector database, enabling the agent to retrieve relevant prior context through similarity search rather than exact lookup.
When implementing persistent memory, it is important to design what information is stored and what is discarded. Not everything that happens in a session is worth retaining. Storing too much creates noise that reduces the quality of retrieved context. Storing too little loses information that would have been genuinely useful in future interactions. Designing a thoughtful memory selection strategy is as important as the storage implementation itself.
External Memory and Knowledge
In addition to session and persistent memory, agents can access external knowledge through the retrieval patterns described in the RAG and Knowledge Systems section. The distinction between memory and retrieval is conceptual rather than technical: memory refers to information derived from the agent's own prior interactions and experiences, while retrieval refers to access to a broader knowledge base that exists independently of the agent's interaction history.
In practice, many production agent systems combine both. The agent retrieves relevant knowledge from an indexed knowledge base to ground its reasoning, and also draws on persistent memory of prior interactions to personalise or contextualise its responses.
Guardrails and Control
Agents that can take actions in external systems introduce risks that are not present in simpler AI applications. An agent that can write to a database, send API requests, or trigger workflows has the ability to cause real effects, and those effects may be difficult to reverse. Designing appropriate guardrails and control mechanisms is an essential part of building safe and reliable agent systems.
Key considerations for agent safety and control include:
Scope of tool access: agents should have access only to the tools they need for their defined task. Every additional tool is an additional surface area for unintended actions. Review tool permissions carefully and apply the principle of least privilege to agent tool access in the same way it is applied to user access controls.
Confirmation checkpoints: for agent actions that are irreversible or that affect external systems, consider building confirmation steps into the agent workflow that pause execution and present the proposed action to a human operator before proceeding. This is particularly important during the initial deployment of a new agent system before its behaviour is well understood in production conditions.
Output validation: validate agent outputs before they are acted upon or delivered to users. This can be implemented as an evaluation step in the agent loop or as a post-processing step that applies defined quality and safety criteria to the agent's final output.
Execution limits: define limits on the number of tool calls, loop iterations, or tokens consumed in a single agent execution. Without these limits, a poorly prompted agent or an unexpected input can cause an agent to run indefinitely, consuming compute resources and potentially taking repeated unintended actions.
Audit logging: all agent actions, tool calls, and intermediate outputs are logged by the platform as part of the audit trail. Review agent execution logs during development and initial production to build confidence in the agent's behaviour before reducing human oversight.
Getting Started
The recommended path to building your first agent on GLBNXT Platform is to start with a single-agent system with a small, well-defined tool set and a clear, bounded task. This gives you a working agent quickly and allows you to build understanding of how the agent behaves before introducing additional complexity.
A practical first agent build follows this sequence:
Define the task the agent needs to complete and the goal it should work toward
Identify the minimum set of tools the agent needs to complete that task and nothing more
Build and configure each tool, ensuring that each one is well-documented so the agent can use it effectively
Configure the agent with its system prompt, tool set, and any relevant memory
Test the agent with representative task inputs, reviewing execution traces to understand how the agent reasons and where it makes suboptimal decisions
Refine the system prompt, tool definitions, and memory configuration based on what testing reveals
Add guardrails appropriate to the tools available and the context in which the agent will operate
Deploy to production and monitor execution logs closely during the initial production period
For use cases that require multiple coordinating agents, begin by building and validating each agent individually before introducing orchestration. A multi-agent system whose individual agents are not yet reliable will be significantly harder to debug and improve than a system built on validated components.
For guidance on connecting agent systems to conversational interfaces, see the AI Assistants and Chat Interfaces section. For guidance on incorporating retrieval into agent tool sets, see the RAG and Knowledge Systems section.
Last updated
Was this helpful?