From ADF to Fusion AI Agents: what an ADF developer already knows

 It has been nine years since my last post here. Between 2007 and 2017 this blog collected 120 posts on Oracle ADF and JDeveloper, and more than half a million page views from developers solving the same problems I was. I'm bringing it back for one reason: if you spent those years building with ADF, you are better prepared for enterprise AI agents than you think.

This post is for the ADF developer who now works on Oracle Fusion Applications, or who keeps hearing "agentic AI" and wonders how much of it is new. My short answer: the hard part of enterprise agents is not the model. It is the same discipline ADF made us practice every day.

ADF already taught you the shape of an enterprise agent

An enterprise agent is a model that reads a request, decides which business operation to call, calls it with the user's permissions, checks the result, and moves to the next step. Strip away the model and that is a description of an ADF application: a page that knows its context, bindings that expose business operations, a task flow that decides what happens next, and a business layer that refuses bad data.

The difference is who makes the decision at each step. In ADF, you wrote the navigation rules and the method calls. With an agent, the model chooses among the operations you expose. Everything around that choice, what it can see, what it can call, and what it is allowed to change, is still yours to design.

The concept map

If you know the left column, you already understand most of the right one.

What you built in ADF	What it becomes in an agent	Why it carries over
Application module methods and data controls	Tools the agent can call	Both are a named, typed list of operations a caller may use. Narrow beats broad.
View objects and view criteria	Retrieval: the data an agent reads before it answers	Both decide which rows the caller sees, filtered and shaped for the task.
Entity object validation rules	Guardrails on every write	The business layer rejects bad data no matter who submits it, a person or a model.
Page definitions and bindings	The context passed to the model	A page only works with what is bound to it. An agent only reasons over what is in its context.
Bounded task flows	Multi-step agent workflows	Steps, transitions, a defined entry and a defined exit.
ADF security and data security policies	The agent acting with the user's own privileges	An agent should never see or change more than the person it works for.
The ADF lifecycle phases	The agent loop: read, decide, act, check	Both are a fixed sequence where each phase has a job and a place to fail safely.
Groovy expressions in declarative fields	Prompts and instructions	Small pieces of logic configured, not coded, that change behavior without a redeploy.

Three habits that carry over directly

1. Declare, don't hard-code. ADF pushed us to put behavior in metadata: validation in the entity object, navigation in the task flow, labels in resource bundles. Agents reward the same habit. The tools an agent can call, the data it may read and the rules it must follow are configuration you can review and change, not logic buried in a prompt.

2. The business layer is the source of truth. We learned not to put rules in the page, because the next page would skip them. The same mistake now is to trust the model to remember a rule. Keep the rule in the business object, so a wrong decision by the model fails exactly like a wrong click by a user.

3. Security travels with the user. ADF security and Fusion data security meant a manager saw their team and nothing else. An agent should run with that same identity. If you would not give a user a button for it, do not give the agent a tool for it.

What is genuinely new

Not everything maps. Three things will feel unfamiliar to an ADF developer, and they are where to spend your learning time.

• The same input can give a different answer. A task flow always takes the same path for the same outcome. A model may not. Design for that: keep each tool small, make writes confirmable, and let the business layer catch what slips through.
• Testing becomes measurement. You cannot unit-test every path, so you build a set of realistic requests and score the agent on them, again after every change. I wrote about this in How do I measure agent performance?
• Context is the new data model. What the agent knows at the moment it decides matters more than how clever the prompt is. Choosing that context is the closest thing to designing a page definition, and it deserves the same care. More on this in CX innovation needs both intelligence and context.

Where to start this week

1. Pick one process you already automated in ADF, such as an approval, a lookup or a data-entry form. List the operations it uses. That list is your first set of agent tools.
2. Write down the rules your entity objects enforce for that process. Those are the guardrails you must keep outside the model.
3. Read how Oracle exposes Fusion agents to outside callers in Consuming Oracle Fusion Agents aka Headless, then Taking Oracle AI Agents Beyond Oracle Applications.
4. Try the samples in the CX Innovations GitHub. I introduced it in Launching CX Innovations GitHub.
5. Build a small test set of ten real requests before you change anything, so you can tell whether each change helps.

What's next on this blog

Over the next few months I'll write one post a month here for ADF developers moving into this world: extending Fusion Applications today, calling Fusion agents from Java, and what ten years of ADF taught me about building AI that enterprises can trust. If there is an old ADF problem you would like revisited with today's tools, leave it in the comments.

I write weekly for a broader audience in Oracle's CX AI Innovation Corner. More about my work, patents and talks is at vivekkumar.ai.

The views expressed on this blog are my own and do not necessarily reflect the views of Oracle.