Part V AI Agents
This chapter provides information on creating, testing, deploying and monitoring agents in your workspace.
Agents are end-to-end agentic applications. Agents are defined through a graph of steps represented by nodes of different types (triggers, agents, guardrails, or tools). Agents can be defined through a no-code visual flow builder and through code via third-party libraries, such as LangGraph.
- Custom Tool: The Custom Code tool lets agent developers extend AI Data Platform with their own Python code. You package your tool implementation as a ZIP file, upload it to your workspace, and configure it. The agent calls your code as a tool, with parameters supplied by the LLM at runtime.
- HTTP: The HTTP Request tool lets your agent call any HTTPS REST API. You configure the request, including method, URL, headers, query parameters, request body, authentication, and optionally, a response optimization step. The agent then invokes the endpoint at runtime. The HTTP request tool is available in both the visual builder and the code builder. In the code builder, the tool is configured through the aidpUtils Python library.
- Prompt: The prompt tool allows the AI developer to define a parametrized prompt that can be issued to an LLM for their choice. Common use cases for a prompt tool include email drafting tasks, translation tasks, style conversion, git commit message, and code explanations.
- Remote MCP Server: Agent developers can connect their agents to remote model context protocol (MCP) servers using the Remote MCP Server tool.
- RAG: The RAG tool lets agents pull relevant external knowledge before generating a response. In AI Data Platform Workbench, the RAG tool queries a knowledge base (23ai Vector Search) and retrieves semantically relevant document chunks. Those chunks are then passed to the agent for response generation.
- SQL: The SQL tool enables agents to execute SQL queries against structured data sources registered via external catalogs, such as Oracle Autonomous AI Lakehouse, Oracle Autonomous AI Transaction Processing, or Oracle AI Database. The tool is intended for scenarios where the SQL queries are predefined and can be parametrized. The objective is to let an agent assign values to the parameters. This tool is not an NL2SQL tool that generates a SQL query based on a natural language prompt.
Note:
The SQL tool only performs queries against data in an external catalog. It does not support data stored in a standard catalog.
Note:
You must attach an AI Compute to your agent before you can test a system tool. If no compute is attached, the Test tab is disabled.Creating agents in AI Data Platform Workbench generates an agent artifact file (.aflow) in the workspace folder that you select. This file can’t be modified.
Part V Agent Memory
Agent memory is the part of an AI agent system that lets the agent retain and reuse information across turns, tasks, or sessions.
Unlike the model’s context window, which is temporary and limited to the current prompt, memory can persist facts, preferences, prior decisions, tool outputs, intermediate plans, or observations about the environment.
Agent Memory in AI Data Platform
AI Data Platform provides short-term memory that is limited to the duration of a session. You can configure what can be kept in memory in the Memory tab of your agent.
Single-Agent Memory Configuration
Memory configuration of a single agent system can be found in the Memory tab of the agent node.
| Memory Configuration | Description |
|---|---|
| Enable Agent Memory | This setting enables agent memory. When disabled, the agent is essentially a stateless system. Each turn is treated independently, and no follow up question can be asked. We recommend that memory is enabled. |
| Limit conversation history | When this selection is disabled, previous turns will fill up the memory until the model runs out of context and an error is returned. If short sessions are expected, it is ok to disable this setting. However, for most use cases we recommend limiting conversation history. |
| Truncation configuration | If you opt to limit the conversation history, you can decide to truncate the history by:
|
| Maximum Message Limits | If you elect to keep the last N messages, you can set a value of N. |
| Token budget | Alternatively, you can set an overall token budget. First tokens are eliminated to keep the most recent ones in memory. |
Multi-agent System Memory Configuration (Supervisor Pattern)
The memory of a multi-agent system is configured in the Memory tab of the supervisor agent.
Memory for a multi-agent system is enforced and cannot be disabled and the memory truncation options displayed in the supervisor agent node only applied to the supervisor agent memory. Each executor agent memory truncation policy can be configured in the executor node Memory tab based on the state isolation policy selected for the entire system.
The multi-agent system memory configuration also allows you to select the memory sharing policy of the executor agents. Three options are possible: Stateless, Private, and Shared. Note that the policy is applied to all executor agents.
| State Isolation for Executor Agents | Description |
|---|---|
| Stateless | Each executor agent sees only the task assigned by the supervisor. No history is carried over between calls. No follow up request can be made to the supervisor agent by the executor agent.
If stateless is selected, the memory of each executor agent is disabled. |
| Private | Each executor agent sees only its own past interactions.
It cannot see other executor agents or the original user conversation with the supervisor agent. |
| Shared | Executor agents can see the full conversation history across agents and user. All agents work from one shared context.
If shared is selected you can configure the memory truncation policy separately for each executor agent in each agent node Memory tab. |