The operator of the Shippit workflow is changing from a human to an agent
Today the fulfilment workflow is run by people. A warehouse operator opens the New Orders page, eyeballs a quote, clicks allocate, clicks label, clicks manifest. A merchant's ops lead configures the Rules Engine by hand. A shopper reads a tracking page and raises a concern. All the actors are humans today.
Shippit sits downstream — we are already wired into our customers. The change is not who discovers us; it is who operates the workflow. Increasingly the merchant's agent will run it: receiving an instruction, choosing a carrier, booking, paying, tracking, and handling the return — and it will arrive with intent ("get this there cheapest by Tuesday") rather than a fully specified order, expecting Shippit to resolve and fulfil it.
Shippit was built as a UI for humans and a public API / integration layer for systems. Neither is an interface an agent can run a workflow through autonomously today.
Public API and Connect made Shippit readable to systems (Manhattan, Shopify, Cin7, NetSuite) — it moves structured orders in and shipment status out. An agent needs more: to resolve intent, reason about trade-offs, act under permission, pay, and prove what it did. Closing that gap on our existing workflows is the strategy.
Rebuild every shipping workflow agent-native
Rebuild every workflow agent-native before someone builds an agent-native one around you.
The chatter from a few thought leadersA market of billions of agents is coming — each with a wallet, each procuring services on behalf of a merchant or a shopper. For Shippit that means quoting, allocation, labelling, manifesting, tracking, and returns must each exist as a capability an agent can find, call, pay for, and trust.
That is different from a human using a UI, or a system calling our API.
The same jobs, run a different way
Today the fulfilment workflow is a sequence of human actions in the Demand UI. In the agentic version the same workflow is a sequence of tool calls the merchant's agent makes — driven by intent and bounded by policy.
Human workflow
The operator logs in, reads the New Orders page, eyeballs a quote, picks a carrier, clicks allocate, label, manifest, then watches the tracking page. Judgement and clicks, one order at a time.
Agent workflow
The merchant's agent receives intent, calls quote, allocates within guardrails, books and pays, subscribes to tracking events, and reconciles a signed receipt. No screen, at machine speed, across every order at once.
Everything Shippit optimises for the human path — UI clarity, screen layout, click flow — the agent skips. What it needs instead is the workflow exposed as typed, callable, policy-bounded capability.
The agent's per-shipment journey
This is the journey the merchant's agent takes through our platform for a single shipment. Every sub-action is infrastructure the human workflow never needed, because a person was doing it by hand.
- Find
- Needs a published, machine-readable capability surface to be discovered at all.
- Evaluate
- Needs Insights-grade data — on-time rates, exception rates per lane — exposed as something an agent can query, not a dashboard a human reads. Think EDD metadata.
- Trust
- The stage the human path hides. Before it spends, the agent must verify it is allowed and the action is safe. We have no machine-readable policy surface for an agent to check against.
- Transact
- Programmatic checkout, not a confirm button.
- Use
- The whole order lifecycle as callable tools, not screens.
- Recommend
- Agents recommending to agents. Ours is carrier reliability shared at machine speed. Reputation becomes a distribution channel we do not control and must earn.
Six building blocks
A human in Demand brings all six by default. An agent brings none — each is the question it must answer.
| Block | Shippit changes |
|---|---|
| Identity | Scoped agent credentials per merchant — extend Connect's OAuth / client-credential auth with granular scopes (quote-only, book-up-to-$X, returns-only). |
| Tools | Shippit MCP server: quote, allocate, label, manifest, track, return, rules-read — "Build to Us" becomes "Build for Agents". |
| Inbox | May sit with merchants, not ShippitAgent event inbox — tracking-state changes, SLA breaches, manifest confirmations, exceptions — delivered to a pull/push inbox the agent owns. |
| Memory | Merchant shipping profile the agent can read — preferred carriers, Rules Engine config, allocation settings, packaging defaults, cut-off times. |
| Wallet | May sit with merchants, not ShippitShipping wallet with per-agent spend caps — pays for labels, Transit Protection, duties & taxes (Zonos / Global-e), surcharges. |
| Receipts | May sit with merchants, not ShippitSigned booking / cost / manifest receipts — reconcilable by a finance agent; the audit trail Insights only renders for humans today. |
Merchants will trust an agent the way you trust a new employee — narrow at first, widening with proof. Identity, wallet, and receipts make the curve auditable.
These products already exist
The point of this section is proof, not prediction. Real companies are already building the six blocks for agents right now — in other categories. That is where logistics is heading.
An email inbox built for an AI agent instead of a person. The agent gets its own address and receives vendor replies, one-time codes, attachments, and threads programmatically.
A purchasing agent that can actually pay. Stripe's agent tooling issues spend caps, approval rules, shared / virtual payment tokens, and an audit trail — so software can buy software under controls a finance team trusts.
The interface an agent operates is the API itself — not a screen wrapped around it. The capability surface is the product.
A user's agent files the ticket itself: attaches logs, states the problem, asks for the refund, follows up, and escalates when ignored. Support becomes a thing one agent does to another, not a form a person fills.
The surface an existing customer's agent integrates and executes against
This is the integration surface for an agent that is already a Shippit customer. It is what lets the merchant's agent operate the workflows from section 03 safely: typed capability, readable policy, callable tools, scoped identity, payment, a sandbox, and proof. Build downward from a single entry point.
| Layer | Shippit build |
|---|---|
| /agents entry point | Shippit CLI — one place a customer's agent points at to operate Shippit, machine-first (an integration surface, not a marketing page). |
| Capability manifest | Machine-readable list of capabilities and per-carrier serviceability, weight / dim limits, lanes. |
| Schemas | Typed order, parcel, quote, shipment, return objects — JSON Schema, versioned; the same model the Bible describes for humans. |
| Policies | Cut-off times, serviceability, Rules Engine constraints exposed as readable policy so the agent reasons before it calls. |
| MCP tools | quote / allocate / label / manifest / track / return as invocable tools. |
| SDK + OAuth | Agent SDK extending the Build-to-Us SDK; scoped OAuth for agent identity. |
Six shifts: concrete workflow → agentic workflow
Shippit is downstream infrastructure, already wired into its customers. This is not about being discovered or "selling to agents" — merchants are already integrated. It is about the existing workflow changing under us: the same jobs stop being run by a human in Demand and start being run by the merchant's agent.
The happy path runs as tool calls made by the merchant's agent. The Demand UI does not disappear; it becomes the oversight and exception surface, not the place the work happens.
Today a human picks the service level and carrier. Tomorrow the agent sends intent — "cheapest to hit a Tuesday ETA" — and expects Shippit to decide and fulfil. We must accept and resolve intent, not just well-formed orders.
The Rules Engine and Allocation Settings shift from a human setting them once to an agent reading and tuning them per shipment, within guardrails. Our config must be agent-readable and agent-writable.
Agents act fast and at scale, so autonomy has to be safe. Sandboxes to dry-run, signed receipts for every action, and clean exception / undo paths stop being nice-to-haves.
CX content stops being a how-to an agent reads and becomes an action it invokes. "Reschedule delivery" is a tool call, not a help page.
Insights must track what agents did and why — which intents arrived, what they chose, when they overrode a rule — not only render charts for a person.
Where we can start building agents
These are just examples. Things can change based on our readiness and market demand.
- Carrier capacity exchange
- Carriers' agents publish spare capacity and price it dynamically; merchants' agents bid. Shippit is the clearing layer.
- Autonomous returns agent
- A shopper's assistant files, prints, and schedules a return with zero human steps, inside policy, paid from the merchant's wallet.
- Rules Engine copilot
- An agent that reads Insights and rewrites allocation rules nightly to chase cost and SLA, with receipts for every change.
- Lane reputation graph
- Carrier reliability per lane, queryable: the intelligence a fulfilment agent reads before it allocates. A decision input that makes our allocation smarter than a human's.
- Promise agent
- As shopping agents pick products partly on delivery, the merchant needs to be selectable on a real, serviceable promise. An agent at their checkout quoting a true per-cart promise from Shippit data — their AEO, powered by us.
The next phase of Shippit is built for agents as well as humans
The companies that win the agent era are the ones whose capabilities an agent can find, call, pay for, and trust without a human in the loop. Shippit already owns the hard part: the carrier network, the order lifecycle, the rules, the data. What we lack is the agent-facing surface over it.