Upgrade Orchestrations from integration endpoints to reusable business actions.
JDE Orchestrator already gives EnterpriseOne a strong action boundary. The next step is to treat good Orchestrations as reusable capabilities that can serve applications, automation and AI without building a separate integration path for each consumer.
The Orchestration is the contract
A useful Orchestration should represent a recognisable business action: approve a purchase order, resolve an address-book entity, look up supplier exposure, update a controlled record, or execute another bounded operation.
That is exactly the shape an agent needs. The tool can advertise a name, description, required inputs and output shape; the agent does not need to know which forms, tables or service requests sit underneath.
What changes when AI becomes a consumer
| Traditional API thinking | Agent-ready thinking |
|---|---|
| Endpoint exists | Capability has a clear business name and description. |
| Developer knows the payload | Agent can discover the schema and required inputs. |
| Caller handles business context | Tool description explains when the action should be used. |
| Errors are technical | Errors are structured enough for the agent to explain or recover. |
| One integration consumes it | Applications, spreadsheets and agents can reuse the same action. |
Composer as the design layer
Composer is intended to make these reusable capabilities easier to design, organise, publish and govern. The important upgrade idea is not the product name; it is the shift from isolated one-purpose integrations to a library of named business capabilities.
MCP becomes the discovery and invocation surface
Once an Orchestration is well-defined, MCP can expose it as a tool to compatible AI clients. The agent can discover the tool, inspect the contract and invoke it without receiving unrestricted access to the underlying JDE estate.
Use the Orchestration as the boundary and let the AI operate one layer above it.