What if a single platform could let you create AI agents, APIs, and integrations for JD Edwards, overcome some of Orchestrator’s known limitations, and modernize without replacing your ERP?

A few months ago, I was talking with a JD Edwards customer who had reached an important decision: they intended to stay on JD Edwards for at least another ten years.

Their ERP was stable, supported complex operations across several countries, and replacing it would require a substantial investment. They saw no compelling business reason to move to another platform.

But they certainly weren’t planning to stand still. They wanted to automate more processes, introduce AI, and improve connectivity between JD Edwards and other applications. One of their main challenges was the poor performance of several integrations with third-party applications and e-commerce platforms.

They were running EnterpriseOne 9.1 and planning to upgrade to 9.2, hoping that newer Orchestrator capabilities would help address those integration challenges. It was a reasonable expectation, although I wondered whether they were asking Orchestrator to solve problems that might require a different architectural approach.

Orchestrator Has Changed What JD Edwards Can Do

I have seen many organizations achieve significant improvements with Orchestrator. It has made JD Edwards more accessible, enabled automation across applications, and allowed companies to extend functionality that once required considerably more development effort. Many customers love it, and with good reason.

But after several years of implementations, we also know where its limitations can become apparent.

Complex orchestrations involving multiple form requests can introduce performance challenges. Application warnings and changes to underlying forms can complicate execution and troubleshooting. Certain integration scenarios require additional infrastructure or become difficult to maintain as complexity increases.

For customers running older JD Edwards releases, there is another consideration. Access to the latest Orchestrator capabilities depends on newer EnterpriseOne Tools releases, and Applications 9.1 customers cannot continue adopting those releases indefinitely.

Orchestrator remains a valuable technology, particularly for organizations that have already invested in it. But it doesn’t have to be the only architecture available for extending JD Edwards.

And this becomes even more relevant as AI enters the picture.

The AI Agent Conversation Is Just Beginning

At the annual INFOCUS conference, we saw partners from around the world introducing AI agents for JD Edwards, addressing processes ranging from invoice automation to procurement and financial operations. Oracle also offers AI capabilities through OCI.

It’s encouraging to see this level of innovation around a platform that some people still consider legacy.

These solutions can deliver real value, particularly when they address a specific business problem. But I think there is a bigger opportunity that deserves more attention.

A company planning to stay on JD Edwards for another decade will need far more than the AI agents available today. New business requirements will emerge, applications will change, and AI technologies will continue to evolve.

Buying individual agents may solve today’s priorities, but it doesn’t necessarily establish how the company will develop the next ten or fifty capabilities.

The interesting opportunity is to give IT teams the tools to build those capabilities themselves, using a common foundation rather than starting a new integration project every time.

And not every requirement needs AI. Sometimes an API or a traditional integration is the better solution. Other times, an AI agent can interpret documents, investigate exceptions, or help users interact with business information.

What matters is having the flexibility to choose the right approach without rebuilding the connection to JD Edwards for every new initiative.

There’s Another Way to Look at JD Edwards Modernization

Over the past months, I came across a solution that made me rethink how we could help our customers get more out of JD Edwards without replacing it. We started exploring the possibilities, and it gradually changed the way we think about JD Edwards modernization.

It starts with something relatively simple: making JD Edwards business functionality directly accessible through a modern, reusable integration layer.

Instead of relying exclusively on Orchestrator or AIS Server, developers can access a broad range of JD Edwards capabilities, including Business Functions (BSFN), embedded Business Services (BSSV), batch process execution and monitoring (UBE), event capture, and transaction management. These capabilities can be exposed through reusable APIs, supporting everything from traditional application integrations to sophisticated process automation.

And development can be remarkably fast. Once the connectivity is established, a simple API exposing JD Edwards information can be created in minutes, allowing IT teams to respond to new business requirements without launching a lengthy integration project.

The opportunity becomes even more interesting with AI. By exposing these same services through Model Context Protocol (MCP), different AI agents can interact with JD Edwards without requiring a separate integration for each one. An agent developed today and another introduced two years from now can reuse the same underlying business services, regardless of which AI technology powers them.

This changes the economics of modernization. Instead of building isolated integrations and purchasing disconnected AI solutions, organizations can progressively develop a library of reusable capabilities that becomes more valuable with every new application, automation, or agent.

There is another advantage that matters: technological independence. Organizations should be able to choose where their solutions run, which AI models they use, and how much they spend on infrastructure and AI consumption, without making every new initiative dependent on a particular cloud provider, AI vendor, or the latest JD Edwards Tools Release.

Introducing Atina: More Than Another AI Agent

This is the thinking behind Atina, the platform we are bringing to JD Edwards customers through ITCROSS.

Atina is not another predefined AI agent for a single JD Edwards process. It’s an integration and development platform that makes JD Edwards business capabilities accessible through APIs and MCP, allowing organizations to build integrations, automations, and AI agents on a common, reusable foundation.

And Atina is AI-agnostic. Customers can choose the AI models and providers that best fit their requirements, rather than being tied to a particular AI ecosystem. As technologies evolve, they can adopt new models or develop additional agents without rebuilding their JD Edwards integrations.

Together, we are developing JD Edwards-specific solutions for areas such as supplier invoice processing, bank statement imports, and other financial and operational processes. These provide practical starting points, but the more interesting opportunity is what customers can build beyond them.

A company could begin by automating supplier invoices, then develop an agent to investigate payment exceptions, followed by an integration with an e-commerce platform. Different requirements, different technologies, but the same underlying connectivity to JD Edwards.

For customers running EnterpriseOne 9.1 or 9.2, this creates another path to modernization without necessarily upgrading the ERP, replacing existing Orchestrator solutions, or adopting a specific cloud infrastructure.

We are looking forward to demonstrating what this approach makes possible, particularly how quickly new JD Edwards capabilities can be developed and reused across multiple applications and AI agents.

The Next Ten Years of JD Edwards

I keep thinking about that customer who decided to stay on JD Edwards for another ten years. Their decision wasn’t about resisting change. They simply recognized that replacing a reliable ERP wouldn’t necessarily deliver the improvements their business needed.

What they wanted was the freedom to modernize without having to reconsider their entire ERP strategy every time a new technology emerged.

I suspect many JD Edwards customers are in a similar position. They’ve invested years in systems that support complex operations, and they have good reasons to preserve that investment. At the same time, they know the next decade will bring business requirements and technologies that are difficult to anticipate today.

We’ve spent years discussing upgrades, cloud migrations, Orchestrator, and now AI agents. Each has a place in the roadmap, but perhaps we’ve been treating them as separate technology decisions when they should be part of a broader strategy for extending the life and value of JD Edwards.

The real opportunity is not only to add AI to JD Edwards, but to make JD Edwards a platform that the business can continue building on, without knowing today everything it will need tomorrow.

For a company planning to stay on JD Edwards for another ten years, that changes the meaning of modernization. The ERP remains, but the possibilities around it keep expanding.

And that’s the conversation I’m looking forward to having at Oracle AI World 2026.