Oracle puts the agent loop inside the database—but Dedicated customers still own the plumbing
Select AI’s new ADB-D capabilities collapse NL2SQL, feedback, memory and tool orchestration into database objects. The operational burden moves, not disappears.
Oracle’s latest Select AI roundup is less a single launch than a change in where an analytics-agent stack can live. On Autonomous AI Database on Dedicated Infrastructure (ADB-D), Oracle now documents AWS Bedrock as a model provider, in-database embedding models, persistent feedback for NL2SQL, multi-turn conversations, natural-language graph queries and an agent framework that can call SQL, RAG, REST services and PL/SQL tools. The common control point is an AI profile rather than a separate orchestration service. Oracle’s product-manager walkthrough lays out the ten capabilities and their deployment implications.
The useful NL2SQL change is retrieval, not retraining
Select AI Feedback stores positive examples and corrected SQL in a profile-specific vector index. Later prompts retrieve the closest examples—three by default in Oracle’s description—and add them to the augmented prompt. Oracle explicitly characterizes this as persistent, retrieval-based prompt engineering rather than fine-tuning, and scopes it to the runsql, showsql and explainsql actions. That makes the feedback portable with the database configuration and easier to revise as schemas change, but it also means teams should evaluate retrieval quality rather than assuming the model has learned a permanent rule. Oracle’s walkthrough explains the mechanism.
Metadata remains the cheaper first move. Select AI profiles can include table and column comments, annotations and constraints; the post argues that foreign keys reduce guessed join paths. Oracle’s ADB-D Select AI documentation confirms that the service supplements natural-language prompts with schema metadata before generating and optionally running SQL.
The database can now host the loop
The larger architectural step is DBMS_CLOUD_AI_AGENT. Oracle’s agent documentation describes agents that plan, call tools, inspect outcomes and retain short- and long-term memory inside Autonomous AI Database. Built-in tools include NL2SQL and RAG; custom tools can wrap PL/SQL or external REST services. Run histories are exposed through database views, giving operators an inspectable record of agent, task and tool execution.
This does not remove external dependencies. A Bedrock-backed profile still needs credentials, the correct regional runtime endpoint and a working network route. An access-control entry gives the database permission to call a host, but it does not create NAT or other VCN egress. In-database embeddings and parallel synthetic-data generation also consume the ECPUs provisioned for the database. Those are explicit caveats in Oracle’s ADB-D walkthrough.
Four checks before rollout
- Patch level: Select AI Agent requires Oracle Database 19c 19.29 or later, or 26ai 23.26 or later, according to Oracle’s agent documentation.
- Egress: verify the route as well as the network access-control entry for every external provider.
- Privileges: decide whether profiles are centrally curated or created per schema, then grant package execution and network access accordingly.
- Capacity: schedule initial embedding and synthetic-data jobs like other database batch workloads.
The practical takeaway is not that every agent belongs in Oracle. It is that data-centered workflows can now keep more orchestration, feedback and audit state beside the governed data—provided the database team treats model connectivity, privileges and compute as production infrastructure rather than demo setup.
sources
comments · 0