“Payables Agent.” “Buyer Agent.” “Order Entry Agent.” The naming suggests a single, indivisible piece of intelligence that has learned a job. Open one up — conceptually, since you will rarely be allowed to literally — and that is not what you find.

What is actually inside one

Strip the branding off any credible process agent and it decomposes into the same recurring parts:

  • Data acquisition — getting the numbers, documents and statuses the process runs on.
  • Entity resolution — working out which supplier, item, customer or document the user actually means.
  • Business-rule validation — the checks the ERP would insist on, applied before anything is committed.
  • Deterministic ERP operations — the parts that must behave identically every time, because they are accounting, not judgement.
  • Exception handling — what happens when the happy path is not available, reported honestly.
  • Approvals and confirmation — a human, in the loop, where the business says one belongs.
  • Monitoring and reporting — someone can see what the agent did, and when.
  • A conversational interface — the part the demo shows you.

The intelligence — the model — supplies judgement and language. Everything else in that list is packaged, deterministic plumbing. Which raises the question that should shape the buying decision: who owns the plumbing, and can anything else use it?

The monolith problem

Buy the process as a sealed agent and the answer is: the vendor owns it, and no. The Buyer Agent’s supplier resolution cannot serve your payables process. The Payables Agent’s document-status checks cannot serve your reporting. Each new process means commissioning another monolith — each with its own overlapping copy of the same eight parts, separately priced, separately integrated, and separately answering the question your security team asks about every one of them: what exactly can this thing do?

Three agents in, you are running a small zoo: overlapping capabilities, inconsistent behaviour where they overlap, and a governance surface that grows with every purchase instead of consolidating.

The alternative: a catalogue of reusable capabilities

Now invert the packaging. Suppose the eight parts are not sealed inside anyone’s agent, but exist as reusable, black-box capabilities in a governed catalogue: resolve this supplier; validate that combination; fetch this availability; check that document’s status; obtain this approval; complete that transaction.

A “Payables Agent” is then an assembly: the conversational layer plus the specific capabilities the payables process needs — most of which the buying process, the order-entry process and next quarter’s process need too. Built once. Reviewed once. Improved in one place, and every outcome that uses them improves together.

The question stops being “which agents have we bought?” and becomes “which capabilities do we govern?” — and the second question has a much better answer.

Capabilities come in the shapes real work comes in: answers from data, the ERP’s own business logic, whole transactions completed properly — and the JDE Orchestrations you have already built, joining the same catalogue as they are. Different building blocks, one governance model.

Governance that compounds instead of multiplying

Shared capabilities do not merely save building effort — they change what governance looks like. One catalogue, published to named groups by deliberate decision, visible on one screen, withdrawable in one act. When a capability is approved, every process entitled to it benefits; when one is withdrawn, it is gone everywhere at once. Compare that with re-answering the “what can it do?” question per sealed agent, per vendor, per renewal.

And the catalogue is not a ceiling. It arrives with packaged capabilities and grows with your own: each one you add is governed identically, and immediately available to every outcome that should have it. The platform is expandable; the packaging is the starting point, not the limit.

What to ask when someone demos an “agent”

  • Which of its parts could my other processes reuse — and may they?
  • When two of your agents resolve the same supplier, do they share one capability or duplicate two?
  • Where is the list of everything the agent can do — and who in my organisation approves changes to it?
  • Can a capability be withdrawn from every consumer at once?
  • When we build our own capability, does it join the same catalogue under the same governance — or is it another integration?

A sealed monolith struggles with every one of those. A governed catalogue answers them by construction.

Where this exists today

This is the model behind Composer: a governed, composable execution platform for JD Edwards and beyond, with an initial catalogue of packaged business capabilities — answers from data, the ERP’s own business logic, and complete transactions — assembled into whatever outcome the business asks for next, by an AI that was only ever handed what the business approved.