APEX AI Agents: Convenience vs. Control

APEX AI Agents are compelling. They let you build agents using the tools you already know, without installing a separate agent framework.

But convenience comes with trade-offs.

Why APEX AI Agents

• Reuse existing views, PL/SQL, authentication, and authorization schemes, reducing additional code and future maintenance.
• Reference APEX session state to provide context.
• Build tools using SQL, PL/SQL, and JavaScript.
• Let APEX handle the agent loop, tool confirmations, and notifications.
• Use a ready-made chat UI.

That is a lot of infrastructure you do not have to build or maintain.

APEX AI Agents let you focus on what the agent does, rather than the plumbing.

In a PDF sales order ingestion app I built, I call the agent from PL/SQL, validate its output, and stage sales orders for users to review and import into EBS. APEX handles the agent loop; my application controls what happens to the result.

I still control the tools, business rules, and validation in PL/SQL. The trade-off is how much control I need over the framework running them.

Why Not APEX AI Agents

• You have less control over the agent framework and which AI provider features it exposes. Think the new decisions APIs.
• Framework bugs or missing features may leave you waiting for an Oracle fix or building a workaround.
• Agents that require built-in user confirmations or client-side tools must run in an APEX page.

Technology is a constant trade-off. For agents in APEX apps, I think APEX AI Agents should be the first choice.

The question is whether a specific limitation justifies the extra code and maintenance of building outside the framework.

What limitation would make you choose a different AI Agent framework?