One automation, from a sentence to a run.
Taken from a single build on Boundlane against a live model. Including the part where it was held back before release, and the part where it caught itself deciding two ways about the same invoice.
- 01
Somebody describes the process
One sentence, in the words the business already uses. No schema, no diagram, no configuration.
Typed into the builderInspect the evidence
“When an AP invoice arrives, compare its total to the purchase order total and hold anything more than two percent over for a human to approve.”
- 02
The agent designs it against what exists
It reads the connected systems, the other automations, and the rules this workspace has already established — so it reuses a definition rather than inventing a second one. Then it builds the automation.
40 steps, summarisedInspect the evidence
Read the connected systems, existing automations and workspace rules Recorded 6 requirements Connected the ERP and added a rules table Built 3 actions; set the trigger, policy and workflow Wrote 6 tests, recorded 2 decisions, raised 2 questions
- 03
It asks what it cannot know
Two questions were raised and marked blocking. A blocking question is not a prompt for a better guess — Boundlane will not release the automation until it has an answer, because guessing here changes the decision rather than the wording.
Held back before releaseInspect the evidence
Open question, marked blocking: “If the invoice currency differs from the PO currency, should the automation convert before comparing, escalate immediately as unmatchable, or is currency guaranteed to always match in this tenant’s data?” — Comparing raw totals across currencies without conversion would produce a wrong hold decision, not just a cosmetic difference.
- 04
The checks pass, and it is released
Answered, rebuilt, and checked again. Before release, Boundlane confirms the parts of the automation fit together, validates its configuration, analyses any generated code and runs every test — including one that proves the forbidden actions are never reached.
Checks passedInspect the evidence
Within tolerance: passes without a hold pass Over tolerance: held for approval pass Forbidden actions: never used pass
- 05
It starts in rehearsal, changing nothing
Release puts it into rehearsal, where it records what it would have done and changes nothing in any system. Widening is a decision someone makes later, on the runs it produced. Boundlane recommends how much evidence that takes, and widening on less requires a reason on the record.
- 06
And then it caught itself
Two invoices were run through it. Replaying both against the same version disagreed on one: an invoice 4% over its PO that the first run completed and the replay escalated. Same version, same input, two answers on a borderline case — found by the replay, before anyone relied on the automation, without anyone looking for it.
Replay against historyInspect the evidence
Replayed 2 past cases: 1 would now come out differently. Invoice 4% over its PO completed → escalated Nothing executed. Every response was replayed from the recording, so nothing changed in any system.
Verify the controls yourself.
Each of these is a behaviour rather than a promise, and each is checkable in the product in a single action.
It is on the recommended forbidden list. A forbidden action never runs, at any rollout stage, and no approval releases it. Build an automation that needs one and the checks before release name it.
Release anything and watch the run record what it would have done and change nothing. Widening on less evidence than recommended requires a reason on the record.
When the build agent marks one of its own questions blocking, release is refused until the question is answered.
Open any run. Each action carries the policy decision — executed, simulated or refused — and the reason, including the approval that authorised a write.
Press Replay on an automation. It reruns past cases from their recorded payloads and lists every one it would now decide differently. Nothing executes.
Verify the chain from the settings page. The head can be published outside the platform so a rewrite is provable.
The second door: an assistant on your business systems.
Gateway takes a different path from an automation. Your people work in the assistant they already use, and one engine governs what it may do in each business system. Oracle Fusion Cloud ERP is the first certified connector. These steps describe the design rather than a recorded run.
- 01
A person connects each system, once
They sign in to the system as themselves. The connector cell checks that the identity matches their email, and that the sign-in finishes in the browser that started it.
- 02
They ask in the assistant they already use
The assistant calls Boundlane. Boundlane signs a short-lived context token, valid for at most five minutes, and passes the call to your company’s connector cell for that system. The assistant’s own token never reaches the cell.
- 03
Your policy applies, then the system’s
The cell applies the grants for the person’s role: fields, business units, legal entities and ledgers on Oracle Fusion, or tools and their argument limits through the MCP connector. It calls the system with the person’s own credential, so the system’s own permissions apply too.
- 04
A change waits for a second person
The assistant can only propose the change. A different person with an approver role decides it in Boundlane Approvals, and the decision is bound to that exact proposal.
- 05
The requester runs it once
Exactly the approved change runs, once, and nothing is retried automatically. On Oracle Fusion, the record version is checked first and the record is read back afterwards.
- 06
Both sides keep the evidence
Every call is recorded in the cell’s hash-chained log. Boundlane records that log’s head in your tenant’s audit chain at least every 30 minutes, and entitlement reports show who could do what.
Build one against your own systems.
The free plan runs a real automation in rehearsal, with every control on.