What is an agentic workflow?
An agentic workflow is software that starts when something happens in your systems, gathers the context it needs, and uses an AI model for the steps that need reading or judgement. It then takes a bounded action or asks a person to approve it. Limits and approvals stay in plain code.
- 07:48:02.114triggercarrier_feed.eta_changed MSKU4812 eta +2d
- 07:48:02.380contextorders.byShipment → PO-4471, customer tier A212 ms
- 07:48:02.611contextcarrierOptions → rail +1d €420, air +0d €3,100231 ms
- 07:48:03.902modelclassify → delay, severity high, confidence 0.931.29 s
- 07:48:03.905policyrebook €420 ≤ maxCost 500, approval by account_owner3 ms
- 07:48:04.470modeldraftUpdate → CustomerEmail, schema valid0.56 s
- 07:48:04.502actionapproval.request → Teams, petra.novak
- 08:31:17.020humanapproved with edits by petra.novak
- 08:31:17.410actionemail.send ok, carrier.rebook ok, tms.setStatus ok390 ms
Six parts, in the order a run passes through them.
Trigger
A webhook, mailbox, queue, schedule, or database change. One event starts one run.
In the shipment run: The carrier feed moves the ETA of container MSKU4812 by two days.
Context
Read-only queries to ERP, CRM, documents, and past cases. Only the fields the step needs.
In the shipment run: Order PO 4471 from a priority account, plus two ways to recover: rail for €420 or air for €3,100.
Model
An LLM call with typed tools. Output is validated against a schema before anything uses it.
In the shipment run: Classified as a high-severity delay, then a customer update drafted.
Policy
Thresholds, permissions, and approval rules in plain code. The model cannot override them.
In the shipment run: Rail at €420 is under the €500 limit, so it goes to the account owner for approval.
Action
An API write to your system, or an approval request in Teams, Slack, or email.
In the shipment run: Petra approves in Teams. The email goes out, the rail leg is booked, and the TMS status is updated.
Trace
Inputs, tool calls, outputs, and decisions are stored per run. Any run can be replayed.
In the shipment run: Nine events over 43 minutes, stored under run 7f3a2c.
Agentic workflow, fixed rule, or a person?
Most processes need all three. We decide per step, and a step only gets a model when a fixed rule cannot do the job.
| Approach | Use it when | Shipment example |
|---|---|---|
| Fixed rule or RPA script | The decision can be written as a condition and the input always arrives in the same structure. | Flag every shipment whose ETA moves by more than a day. |
| Agentic workflow | The input needs reading or judgement, such as a carrier email or a free-text reason, but the possible actions and their limits are known. | Read the carrier message, check the order behind it, and draft the customer update for approval. |
| A person | The decision is rare, high-stakes, or depends on a relationship the system cannot see. | Agree new delivery terms with a priority customer. |
Workflows / Shipment exceptions
Step permissions
Live · owner Petra Novák
- Auto
Read carrier updates
Carrier feed
Every ETA change
- Auto
Classify the delay
Model
Below 80% confidence, a person decides
- Auto
Update shipment status
TMS
Status field only
- Approve
Send customer update
Email
Account owner approves
- Approve
Rebook transport
Carrier portal
Up to €500 per shipment
- Recommend
Offer a credit
CRM
Account owner issues it
- Never
Change contract terms
Contracts
No access
Every run is recorded with its inputs, decisions, and approvals.
Autonomy is set per step.
The model handles the steps that need reading or drafting. Thresholds, permissions, and approvals are plain code the model cannot change.
- Auto
- Runs without review. Reads and reversible internal updates only.
- Approve
- Prepared by the workflow, executed after a named person approves.
- Recommend
- The workflow proposes. A person performs the action.
- Never
- Outside the workflow’s permissions. It has no credentials for it.
A step moves to a higher level only after its production numbers support it, for example drafts sent unedited for several weeks.
Failure handling.
Before launch we replay a few hundred historical cases and compare each decision with what your team actually did. In production, every failure has a defined path.
| Failure | What happens |
|---|---|
| Model output fails schema validation | Retried once with the validation error. If it fails again, the case goes to a person. |
| Confidence below the step threshold | The step drops to recommend. Nothing is written without a person. |
| Source system slow or down | The run waits and retries with backoff. After 15 minutes the owner is alerted. |
| Model provider outage | Runs are queued and your team works the manual process until it recovers. |
| Input the workflow has not seen before | Routed to a person and added to the evaluation set for the next release. |
Start with a conversation
Is there a step in your work like this?
Bring one process that costs your team time. We'll tell you which parts need code, which need a model, and which should stay with a person.
