An action leaving an agent has somewhere to go. It can raise an event other systems listen for, open a task for people in a process workflow, call the published interface of the system that owns the data, write to a governed table, or leave a file for a system that reads files.
Five steps: ready, route, evidence, act, answer.
An action becomes ready in one of three ways: a named person approved it, the agent executed it inside your limits, or a person took the finding and asked for it. From that point the path is the same.
The route is a setting on the agent for that kind of action. A cancellation goes to the purchasing interface; a transfer request goes to a workflow; a scorecard goes to a file the reporting team already reads.
Whatever the route, the same evidence travels: the decision reference, the rule version, the approver where one signed, the limits that were checked and the moment the facts were read.
The target system then acts, and its answer comes back. A document number, a task identifier, a row count or a file receipt: each one is stored as returned, under the same decision reference.
Five routes cover the systems a supply chain runs on, from a modern service to a file at 06:00.
| Route | What Juno sends | Where it lands | Example |
|---|---|---|---|
| An event | A message with the decision reference and the facts behind it | Any system that listens for events in your estate | A cover breach is published, and the planning suite picks it up within the minute |
| A process workflow | A task with its evidence attached, routed to a role | SmartApps, where people work through queues together | A stock transfer from a rebalance role would wait for the plant lead and the logistics desk in turn |
| An interface call | A change through the published service of the owning system | SAP, Oracle, a planning suite, a warehouse system | A cancellation on a purchase order line, answered with a document number |
| A database write | Rows written to a governed table inside your estate | A warehouse, a lake, or a table your reporting reads | A supplier scorecard would be written each Sunday for the buyer dashboards |
| A file | A file in the layout the receiving system expects | A file store reached by secure file transfer | A weekly allocation split would be left at 06:00 for a partner system to collect |
One route per agent and per kind of action, and an action can take two where both are useful. Product. The cancellation examples are the agent in production; the transfer, scorecard and allocation examples are designed roles from the agent blueprint. Showcase estate. blueprint
The route follows the system that receives the action. A system with a published service takes an interface call. A system that reads files takes a file, on the schedule it already expects.
Events suit anything that has to be known quickly by more than one system. The message carries the reference, so a listener can read the whole case from the audit trail.
A database write suits results that many people read: scorecards, rankings, weekly measures. The table is governed like any other registered data set, and the rows carry the run that produced them.
Two routes at once is common. A cancellation goes to the purchasing interface and raises an event, so the planning suite sees the open quantity change in the same minute.
The workflow route suits work that several people carry, inside your company or across it.
SmartApps is where this work happens. In production today more than 200 business users work this way across engineering, supply and service, on warranty exceptions, supplier exceptions and production scheduling.
A workflow is the right route where a decision needs several people, a conversation, or a document that people add to as they go.
The handoff keeps the thread. The task holds the decision reference, so an agent that raised it can read what happened, and the outcome check reads the result when the workflow closes.
When the work finishes, the workflow can hand back to an agent: an approved transfer becomes an interface call, and the document number returns to the same record.
One reference, one rule version, one approver, the limits, the facts and the rights: the same six on every route.
| What travels | Why it travels | Where it is read again |
|---|---|---|
| The decision reference | One identifier joins every part of one decision | The audit trail, the workflow task, the event message |
| The rule and its version | The action traces to the sentence a person published | The audit trail and the versioning screen |
| The approver, where one signed | The action carries the name that stands behind it | The audit trail and the manager report |
| The limits that were checked | What held the action inside the boundaries you set | The audit trail and the observability screens |
| The facts as read | The values the decision rested on, with their systems | The audit trail, and any replay of that decision |
| The agent’s own rights | The action carries least privilege, and a rate you set | Your system’s own log, and the security screens |
This is what makes five routes readable as one thing. A file written at 06:00 and a purchase order change at 09:12 are both findable from the same reference, with the same evidence beside them.
It is also what makes a route interchangeable. Moving a result from a file to an event is a settings change; the record stays the same shape.
Rights travel with the action, which matters most on the routes that look informal. A file drop runs under the agent’s own account and its own rate limit, the same as an interface call.
Every route ends the same way: the answer is stored as returned, the outcome is checked against the objective, and the record joins the learning loop.
Showcase estate. The rebalance and scorecard roles are designed in the agent blueprint, yet to be built.
The eight approved cancellations went out as interface calls to SAP S/4HANA and came back with document numbers. Each one also raised an event, so the planning suite saw the open quantity change in the same minute.
A stock transfer from a rebalance role would take the workflow route: a task for the plant lead at Penang, then the logistics desk, with the freight cost and the lead time on the task. A supplier scorecard would be written to the reporting table on Sunday night, every week.
What Juno keeps from every accept, edit and override, and how the next cycle of recommendations is better for it.
You set it per agent and per kind of action, from what the receiving system supports. A system with a published service takes an interface call; a system that reads files takes a file.
Yes, and it often should. A cancellation goes to the purchasing interface and raises an event, so systems that plan against that order see the change at once.
They work where the task is: a SmartApps queue, a channel, or their own system. The task carries the evidence and the decision reference, so the record stays whole.
The action keeps its place in the queue with the answer beside it, retries run to the limit you set, and after that the item goes to the named desk for that queue.
Each one builds on the one before it.
Reads your rows in place.
Connect and move ↗One record per real thing.
Master and govern ↗Apps for every decision.
Operate and decide ↗Asks and acts, at your level.
Ask and act ↗Bring two systems and one decision your planners make every week. In the first week we register the data, confirm the mapping with your team, answer your questions in ChatLima and run the first agent at the level you choose.
