The Juno Planner Agent turns a policy written in plain language into a reviewable planning table.
The language model drafts and explains; the published table is what runs.
A planner writes what the policy should do, in the words the team already uses. The Planner Agent reads that sentence through the language-model gateway, which calls a cloud model of your choice. The sentence, the ontology terms and your vocabulary cross that boundary; the order rows stay inside your estate.
The agent recognises the business objects in the sentence and the thresholds attached to them. Where a threshold is stated loosely, it asks one clarifying question, and it asks once. A planner answers in a line and the drafting carries on.
What comes back is a table. Each row names the task, the procedure that performs it, the data it fetches and the rule it evaluates. The rows use a constrained action vocabulary: the set of actions Juno supports against your mapped objects.
Your team adopts rows one at a time or together, edits the wording or the numbers, adds a row by hand, and simulates the whole plan on past data. Publishing writes the planning table to the versioned rule store, where the Lima Rules Engine reads it.
The policy sentence and the planning table are two views of one published version.
| Row | Field | Test | Value | Then |
|---|---|---|---|---|
| 01 | Projected excess | above | 8 weeks of demand | carry on |
| 02 | Cancellation window | open on | the run date | carry on |
| 03 | Supplier class | equals | standard | carry on |
| 04 | Line value | under | $25,000 | cancel the line |
| 05 | Line value | at or above | $25,000 | draft and ask the buyer |
The highlights mark the conditions, the values and the action. Showcase estate.
The sentence above is the whole policy, as L. Tan wrote it. The table below it is what the rules engine runs. Both stay on the same screen and stay in step: editing a row updates the sentence, and editing the sentence redrafts the rows.
The table is the handoff contract between design time and run time. It is also the object your auditors read: every write-back traces to one of these rows, in one numbered version, with the person who published it.
The exchange is short by design: one question, a table, a simulation, a version.
Juno asks a clarifying question where the intent leaves a real choice open, such as a threshold that carries the whole policy. It asks one question, offers the values it can see in your data, and carries on with the answer it receives.
The drafted rows arrive with a suggested value and the reason for it. A reviewer adopts a row as drafted, edits it, replaces it or adds a row of their own. The exclusion for allocation-bound suppliers in the trace above began as a hand-written row.
Simulation replays the plan against the period you choose. It reports how many lines matched, the value they carry, how many actions would have executed and how many would have waited for a person. A plan that behaves oddly on history is edited before anyone sees it in production.
Publishing takes a named owner. The version number, the owner, the approver and the level are written together, so the record answers who allowed what, and when.
A row states what to do, how, on which data and under which test; the action comes from a fixed list.
| Task | Procedure | Data to fetch | Rule to evaluate |
|---|---|---|---|
| Find candidate lines | Read open purchase order lines for the plants in scope | Purchase order, line, schedule line, plant, supplier | The line is open and carries a quantity still to deliver |
| Measure the excess | Compare coverage with forward demand per material and plant | Stock on hand, stock on order, forecast, sales orders | Projected excess is above eight weeks of demand |
| Check the window | Read the cancellation window agreed with the supplier | Cancellation window in days, order date, supplier terms | The window is open on the run date |
| Classify the supplier | Read the supplier class from the supplier record | Supplier, supplier class, allocation flag | The class is standard |
| Decide the action | Apply the value threshold to choose execute or draft | Line value, currency, daily action budget | Under $25,000 cancel the line; at or above, draft for the buyer |
| Action in the vocabulary | What it changes | Where it lands | Roles that would draw on it |
|---|---|---|---|
| Cancel a purchase order line | Closes the open quantity on the line | Purchasing | PO cancellation |
| Change a delivery date | Moves a schedule line earlier or later | Purchasing schedule lines | Expedite · De-expedite |
| Change an open quantity | Raises or lowers what is still to deliver | Purchasing | Excess stock |
| Update a planning parameter | Writes safety stock, lot size or planned delivery time | Material master at plant level | Safety stock · Lead time drift |
| Request a stock transfer | Asks for stock to move between sites | Supply orchestration | Stock rebalance |
| Confirm an allocation | Writes the agreed split back to the order | Order management | Allocation |
| Raise a task for a person | Opens a queue item with its evidence attached | Approval queues in SmartApps | All ten roles |
| Send a notice | Publishes an alert or a digest to a named role | Alerts and channels | All ten roles |
The vocabulary is fixed per object, so a drafted plan stays inside what Juno can carry out and audit. The PO cancellation agent draws on it today; the other roles named are designed in the agent blueprint, yet to be built. Product. blueprint
Metadata and intent may cross at design time; transaction rows stay where they are.
The gateway sends the external model what it needs to draft: the names of tables and columns, the ontology terms, your vocabulary and the sentence the planner wrote. Order rows, prices, supplier names and stock figures stay inside your estate.
A model link serves only after a live handshake confirms the model, the key held as a vault reference and the boundary rule. The token manager budgets and meters every call at design time, and model choice covers swapping one model for another.
Showcase estate.
L. Tan stated the cancellation policy as one sentence at 09:00 on Friday 18 September. Juno asked a single question, about what counts as demand, drafted five rows by 09:40, and attached the tables each row reads: version 1.
At 10:10 she adopted four rows and edited one, the excess check: version 2. The limits and the level were set at 11:00, the plan was simulated on last quarter at 11:30, and 184 matching lines worth $1.9M came back, with 31 routed to the buyer. J. Ridley published version 3 at 13:30 at A2 supervised, with D. Okafor named as approver. The 06:00 run on the Monday picked it up from the rule store.
How the published planning table is executed: the fact base, the rule builder, validation while authoring, and one run end to end.
It drafts and it explains. The published planning table decides, and the rules engine executes it. Identical facts and one rule version give one result.
Juno asks one clarifying question and offers the values it can see in your data. If the draft still misses the point, your team edits the rows or writes them by hand.
Yes. Rows can be written and edited directly in the rule builder, and a plan can start from a copy of an existing version.
In the showcase estate the sentence was stated at 09:00 and the five rows were drafted by 09:40; the review, the limits, the simulation and the release took until 13:30. Policies with more conditions take longer to review.
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.
