Your Oracle Forms already contain your AI agents' rulebook
Every organization that wants AI agents in its operations runs into the same question: what stops the agent from doing something it should not? For Oracle Forms owners, most of the answer already exists. It sits in the triggers and PL/SQL of their forms, written and refined over decades.
The real question is whether your migration keeps those rules, or leaves them behind with the old screens.
Where your business rules actually live
Ask an Oracle Forms team where the business rules are and they will point at the database packages. Half of the answer is there. The other half is in the forms themselves:
- WHEN-VALIDATE-ITEM triggers that refuse a date outside the open period;
- PRE-INSERT triggers that derive a value the user never types;
- KEY-COMMIT triggers that call a package in a precise order;
- properties that make an item read-only once a record is posted.
A large application holds thousands of these, written over twenty years by people who have since retired. Nobody has a complete list. Together, they decide what a valid transaction is, who may change what, and when a posting is refused.
That is exactly what an AI agent needs in order to be trusted in a transactional system. Your forms already hold its rulebook.
Why a rewrite loses the rules an agent needs most
Every rewrite, whether by hand or with a code-generating AI, starts from a specification. That specification is written from the screens and the obvious workflows. The rules are discovered later, one incident at a time.
Take a form that refuses a posting date outside the accounting period currently open. The rewrite reproduces the screen, the lookup and the save, but not the trigger, because nobody asked for it.
- With a person at the keyboard, the error surfaces at month end and gets corrected.
- With an agent executing hundreds of postings a day, the same gap produces hundreds of entries in a closed period before anyone looks.
The rule the agent needed most is the one the rewrite dropped. Keeping the old screens and adding an AI assistant beside them does not solve it either: the assistant helps the operator type faster, but it does not change who does the work.
Migrate the rules, not the screens
ORMIT™-OpenJava does not reinterpret a form. It migrates it. Every trigger, validation and procedure becomes TypeScript that OFCS, the Oracle Forms Compatibility Service at the heart of ORMIT™-OpenJava, runs exactly where Oracle Forms ran it: in the browser as the user works, and on a Node.js validation server with no screen attached.
The conversion itself is deterministic. It is built on the form's abstract syntax tree, not generated by a model. AI works around it, for testing and for controlled repairs reviewed by people, never as the converter.
In numbers, OFCS reproduces 93 Oracle Forms trigger types, fired at the point where Forms fires them. It makes 232 built-ins available to the migrated code and supports 240 Oracle Forms properties. Every save is validated twice: in the browser, then on the validation server before the database. Package logic, constraints and grants stay in your Oracle database, and OFCS is delivered with its source code.
One rule, two callers: the employee and the agent
Here is the part that matters for agents. From the form's point of view, an AI agent is one more caller without a screen. The open connector (MCP) is designed so that the agent works the form the way an employee does: it reads the form's blocks and items, sets values in the form's navigation order so that each item's validation runs, presses the form's buttons and commits. Every one of those actions goes through OFCS.
Refuses a posting date outside the open accounting period.
Enforced before the Oracle database, the same for everyone.
When a trigger refuses an entry, the agent receives the form's own message and stops, as an employee would stop at the same message. Going around the screen does not go around the rules.
Safe by construction, under the same rules as employees
Because the agent goes through the form's rules, the controls come from how the migration is built. They are not instructions added to the agent afterwards:
- No path of its own. The agent reaches the database only through the connector and the form's rules, never around them.
- An identity of its own. Its own database account, with only the grants its process needs, never an employee's credentials.
- A record of every action. Each one is logged with the rule it went through, the agent that proposed it and the person who approved it.
- A person approves. The agent prepares, an employee approves: the separation of duties auditors expect stays in place.
No capability depends on the model being right: the model proposes, the rules decide, and a person approves. That matters, because Gartner expects over 40% of agentic AI projects to be cancelled by the end of 2027, citing escalating costs, unclear business value and inadequate risk controls (Gartner, June 25, 2025). Oracle Forms owners already have that control: the rules in their forms.
What this means for you
- Your forms are an asset. Their triggers and PL/SQL are the rulebook an AI agent needs.
- Choose a migration that keeps the rules executable. A rewrite written from the screens risks dropping the very rules agents depend on.
- One migration serves both. The application your employees use is the one any AI agent operates, yours, a platform vendor's or RENAPS's, without a second migration.
- Start with one process. Pick one with volume and clear rules, run the agent in observation first, and measure the results before going further.
- Already migrated with ORMIT™-OpenJava? Your application already runs on OFCS, with the same rules. The first step is choosing a process.
Our white paper, From Oracle Forms to AI Agents, goes further: the 2026 market shift, the rewrite trap, how OFCS keeps the rules executable, the two-tier offer, safe-by-construction controls and the first step, with a source for every figure and quotation.
Download the white paper From Oracle Forms to AI Agents
To see how the migration itself works, visit the ORMIT™-OpenJava product page.
Next in this series: why the rules matter more than the screens, how a single trigger becomes an agent tool, the guardrails that keep an agent within the rules, a practical roadmap, and the most common myths about Oracle Forms and AI agents.