How to build an order orchestration agent, from intake to dispatch

In 60 seconds: Build the agent around the ERP or order management system, which remains the source of truth for every order. Channels such as WhatsApp, Teams, and web forms provide requests; they do not become the order ledger. Give each action its own control level: reading can be broad, creating or materially updating an order starts with approval, verified status updates may become autonomous within a narrow policy, and cancellation stays controlled. Connect the agent to the ERP API, inventory, notifications, and an owned exception queue. Run a two-week pilot and measure orders completed without re-entry, blockers, and exception resolution time. If customer, product, tax, address, or inventory master data is unreliable, clean it before allowing writes.

An order often starts as an incomplete message and ends as work for the warehouse. Between those points, someone checks the customer, transcribes products, confirms tax data, asks about stock, reconciles payment, and tells several people what changed. An agent can coordinate those steps when the rules and records already exist.

This playbook covers the build of that coordinator. The broader WhatsApp-to-dispatch operations map explains the full journey through payment, warehouse, carrier, and invoice. Here the boundary is narrower: validated intake enters, an order is created or updated in the authorized system, inventory and dispatch states stay synchronized, and every unresolved case reaches a person.

It does not specify a complete WMS, fleet routing, or courier operations. The agent also does not set commercial policy, approve credit, or infer that a payment has settled.

Define the job and its stopping point

Write the objective as an observable state transition:

validated request -> authorized order -> stock or dispatch state -> recorded update

“Validated” means the request has a known customer or a controlled customer-creation path, recognized products and units, required tax fields, a serviceable address, and enough context to apply the commercial policy. A fluent message is not validation.

The agent finishes when it has either:

• written the permitted state to the ERP or OMS and stored the returned identifier; or
• placed a blocked case in the exception queue with a reason, owner, evidence, and explicit action needed.

This boundary prevents a stalled connector or missing field from disappearing inside a chat. It also gives operations a denominator: every eligible intake should end in a recorded order state or a visible exception.

Keep the ERP or OMS as the system of record

The channel supplies evidence and intent. The ERP or OMS owns the order number, lines, approved prices, tax treatment, customer link, and order state. If inventory is managed separately, the ERP or WMS owns available quantity, reservations, locations, and release status.

Record	Authoritative source	What the agent may do
Customer and tax profile	ERP or approved customer master	Find an exact match, validate required fields, or request review
Product, unit, and price	ERP catalog and approved price rules	Resolve stable IDs and reject ambiguous or expired values
Order	ERP or OMS	Create or update through an idempotent command and read back the result
Inventory	ERP or WMS	Read availability, request a reservation, and retain the returned state
Payment	Bank, provider, or approved reconciliation process	Read a verified result; never infer settlement from a receipt image
Dispatch	WMS, TMS, or carrier system	Read confirmed events and update the order through allowed transitions
Conversation	WhatsApp, Teams, or web channel	Preserve the source reference and communicate approved information
Exception	Shared operations queue	Assign the blocker, decision, evidence, and resolution

Avoid keeping a parallel “agent status” that can disagree with the ERP. The orchestration layer may retain correlation IDs, attempts, and audit events, but it reads the current business state before acting and writes the outcome back to the authoritative system.

Our guide to the cost of copying data between systems helps identify the handoffs where staff currently re-enter these records. Removing that re-entry is a more precise objective than “automating orders.”

Clean master data is a build dependency

The agent needs stable customer IDs, SKU codes, units of measure, warehouse locations, tax categories, currencies, address rules, and allowed state transitions. A product described as “the large blue one” may be clear to a salesperson and still be unsafe to send to an ERP API.

Before enabling writes, test recent orders for:

• duplicate or unmatched customers;
• inactive SKUs, aliases, packs, and inconsistent units;
• missing tax identifiers or conflicting fiscal profiles;
• addresses that cannot be checked against the delivery coverage rule;
• stock records that do not reflect reservations, holds, or the correct location; and
• order states with different meanings across sales, finance, and operations.

Assign an owner for each master. The agent can surface an uncertain match and prepare a correction, but it should not merge customers, invent a SKU mapping, or repair a tax profile on its own. When these failures dominate the sample, the first project is data cleanup and state definition.

Assign a control level to each action

Control belongs to the action, not to the agent as a whole. The framework in copilot or autopilot: five control levels provides the full method. A practical starting matrix for orders looks like this:

Action	Pilot control	Conditions for more autonomy
Read customer, catalog, order, and inventory	Read or recommend	Least-privilege scopes, field filters, and access logs are verified
Structure intake as an order draft	Draft	Every extracted value links to its source and uncertain fields remain empty
Create an order or change lines, quantity, price, tax, or address	Approved execution	Later autonomy is limited to a documented segment with valid master data, deterministic checks, idempotency, and tested recovery
Send a status update	Draft for ambiguous cases; bounded autonomy for verified events	The state comes from the system of record, the recipient and consent are valid, and the template makes no new promise
Reserve stock or release warehouse work	Approved execution	The release policy, payment or credit condition, location, quantity, and rollback are all machine-checkable
Substitute, split, or back-order a line	Approved execution	Keep approval whenever the choice changes price, date, product, or customer commitment
Cancel an order	Approved execution	Verify identity, cancellation window, shipment state, financial effects, and downstream reversal before the command

Approval must bind to the exact payload. If a person approves order version 3 and the address or lines change before execution, the approval expires. Read back every write from the ERP and store who or what performed it.

Give the agent four operational tools

The model should never receive a generic credential or unrestricted database access. Expose narrow tools with explicit schemas, permissions, timeouts, and audit fields.

1. ERP or OMS API. Search by stable identifiers, validate the current version, create or update with an idempotency key, and return the canonical order ID and state. Separate read commands from writes.
2. Inventory interface. Read available-to-promise stock by SKU, unit, location, and time; request a reservation only when policy permits; return shortages and partial availability as structured results.
3. Notification service. Send an approved template to an eligible recipient or create an internal alert. It receives confirmed facts rather than free-form claims about stock, payment, or delivery.
4. Exception queue. Create and update cases using reason codes, priority rules, owner, supporting references, required decision, and timestamps. A reply in Teams is useful only when the resolution returns to this queue and the order record.

Place deterministic checks between the model and every side effect. The command layer verifies required fields, allowed transitions, version, permission scope, and idempotency key. The agent may decide which approved tool to request; the tool decides whether the request satisfies the contract.

Build the happy path as a state machine

A compact state vocabulary might include received, needs_data, draft, pending_approval, confirmed, stock_exception, ready_for_dispatch, dispatched, manual_hold, and cancelled. Use the states already supported by the ERP where possible and document every allowed transition.

The happy path follows seven steps:

1. The channel adapter records the source message or form ID, time, channel, and authorized business context.
2. The agent structures customer, lines, units, quantities, requested address, and any supplied tax fields. Validation reports missing and ambiguous values without filling them by guesswork.
3. The integration resolves stable customer and product IDs, reads current policy and order state, then creates an idempotency key for the proposed action.
4. A person approves the exact payload during the pilot. The ERP or OMS creates or updates the order and returns its canonical ID, version, and state.
5. The inventory tool checks the correct location and requests a reservation or warehouse release only when the order, payment or credit condition, and stock policy allow it.
6. Confirmed warehouse and dispatch events advance the order through permitted states. The notification tool communicates only the state that was read back from the authoritative source.
7. A reconciliation job compares eligible intake, ERP orders, reservations, and notifications. Missing or conflicting records become exceptions rather than silent gaps.

Retries reuse the original idempotency key. A timeout may justify a retry after checking the previous result. Invalid tax data, an address failure, or a stock shortage will not improve when repeated.

Route exceptions with enough context to act

The exception queue is part of the product, not an operational afterthought. Each case needs the canonical order or intake reference, a reason code, sanitized evidence links, current state, requested decision, owner, and time of entry. Keep customer PII in its authorized source and show only the minimum data needed for the assigned role.

Exception	Agent response	Human owner	Evidence required to resume
Insufficient stock	Hold release, show requested and available quantities by location, and propose allowed options without selecting one	Operations or sales	Approved partial order, substitution, new date, transfer, or cancellation
Missing tax data	Keep the order in needs_data and identify the missing field	Sales, customer service, or finance	Validated fiscal profile in the system of record
Unreconciled payment	Keep payment pending and block any policy-dependent release	Finance	Verified provider event or approved reconciliation linked to the order
Invalid address	Stop dispatch, identify the failed rule, and request correction	Customer service or logistics	Validated address and serviceability result

The same pattern applies to duplicate customers, stale prices, connector outages, and conflicting dispatch events. Set resolution expectations from the team’s existing operating commitments. The queue should make overdue cases visible without inventing a generic SLA.

Run a two-week pilot with a baseline

Choose one business line, one order type, one warehouse or location policy, and a clear owner group. Exclude unusual commercial terms until the ordinary path and its exceptions are observable.

During week one, replay recent anonymized cases in shadow mode and process new eligible intake with approval before every write. Record the existing re-entry steps and compare the agent’s proposed payload with the order actually accepted by operations. Fix schemas, master data, permission scopes, and reason codes as failures appear.

During week two, keep creation and material changes approved. Allow bounded automation only for low-impact actions that passed the first week, such as recording a verified internal state or sending an approved update from a confirmed event. Exercise duplicate delivery, delayed responses, stale versions, service outages, cancellation attempts, and every named business exception.

Define the measures before the pilot starts:

Measure	Definition for the pilot
Orders without re-entry	Eligible orders created or updated without staff copying the same fields into the ERP, divided by all eligible orders
Blocker rate	Exceptions divided by eligible intake, grouped by stock, tax data, payment, address, master data, policy, and technical failure
Exception MTTR	Time from queue entry to a recorded resolution or valid terminal decision; report the median and an upper percentile alongside unresolved age
Write quality	Orders corrected after the agent’s write, unauthorized transition attempts blocked, and duplicate writes prevented
State communication quality	Updates sent from a verified state, failed or repeated notifications, and updates corrected by staff
Review workload	Cases reviewed, approval changes, and time spent by approvers and exception owners

Report counts and denominators. Separate integration failures from bad master data and unresolved policy. Compare the two weeks with the documented baseline; do not extrapolate throughput or ROI from a small sample.

Pause the pilot if the agent can write outside its scope, the exception queue loses ownership, reconciliation cannot explain a missing order, or staff must repair hidden errors. Resume after the control or data issue has a tested fix.

When an order agent is the wrong next project

Do not enable this agent when customer and product masters have no reliable identifiers, physical stock regularly disagrees with the inventory system, or teams cannot agree what an order state means. It is also a poor fit when the ERP lacks a controlled write interface and the team cannot add idempotency, audit history, or reconciliation.

Keep the process manual when order volume does not justify maintaining the integration, exceptions dominate ordinary work, or nobody owns the queue. Fix policy first when pricing, credit, tax, cancellation, or release rules depend on undocumented judgment.

If the earlier problem is neglected demand rather than order execution, start with the sales follow-up agent. Once a buyer has confirmed the request, the order agent can take over at validated intake without mixing sales persuasion with operational authority.

Kiia can map the state machine, define the tool contracts, and run this pilot against your existing systems. Bring recent anonymized orders that include both routine cases and blockers; they are enough to identify the first safe boundary.