Atlas: the autonomous control tower and why “System of Action” replaces “System of Record”
Most logistics control towers stop at visibility. Atlas, Shipsy’s autonomous control tower, does the next thing — it acts. Atlas is the System of Action layer that binds Shipsy’s four agents (Clara, Nexa, Vera, Astra) to real operational decisions, with measurable autonomy thresholds and full auditability.
This deep-dive is for COOs and CIOs who already paid for visibility, own a supply-chain dashboard, and still spend Monday mornings on exception meetings.
Why we built this
Three generations of logistics software preceded Atlas. Systems of Record (ERP, TMS, WMS) captured what happened. Systems of Engagement (portals, apps) let people interact with what happened. Systems of Intelligence (control towers, analytics) told you what was about to happen.
None of them did the thing that actually costs money: the response. A delay detected at 09:14 still waits on a human to reroute, notify, and reassign at 10:30. A dispute flagged on Friday still waits on a shared-service analyst next Tuesday. Intelligence without action is expensive theatre.
Atlas was built to close the loop. It is the layer where decisions become execution, not just alerts.
How it works
Atlas has four components, each doing structural work.
1. The event spine
Atlas ingests events from every operational source — WMS scans, driver app pings, carrier EDI, IoT sensors, shipper order systems, CX tickets. Every event is normalized to a shared schema with a shipment or asset identifier, a location, a timestamp, and a confidence score. This spine is what lets agents reason across systems without human-brokered data reconciliation.
2. The decision graph
On top of the event spine, Atlas runs a decision graph — a network of rules, thresholds, and model-driven policies that map events to required actions. “ETA slipped by more than 20% on a pharma shipment” triggers a different decision path than “ETA slipped on a generic retail parcel.” The graph is configurable per shipper, per carrier, per vertical, and per SLA tier.
3. Agent action loops
When the decision graph identifies a required action, it invokes the right agent. Astra reroutes. Clara notifies. Nexa flags an invoice. Vera opens a dispute. Each agent executes its loop inside its guardrails and returns the outcome to Atlas, which updates the event spine. The next incoming event operates on a newly-consistent state of the world.
4. Autonomy thresholds and replay
Every action has a declared autonomy level — “act immediately,” “act and notify,” “propose and wait,” or “human-first.” Operators set these per agent, per action type, per tolerance window. Every autonomous action is logged with its triggering event, the agent responsible, and the outcome — so Atlas is fully replayable and auditable at any point.
Together, these four components are the difference between a dashboard and a working digital operations team.
The architecture looks like this:
Early results
Catalent: $675K saved in pharma shipment-visibility, 60% reduction in exceptions — Atlas-driven, with Clara handling proactive customer notifications and Astra re-planning when transit SLAs moved. European express couriers running Atlas across their depot networks consistently cut exception-meeting volume sharply because Atlas closes most of the exceptions before the meeting. Heineken’s $25M+ in autonomous dispute resolution — plus a 50% reduction in failed deliveries and 70%→90% route settlement automation — runs on Atlas’s agent coordination. Teleport (SEA) logs a 75% planning-time reduction on the same pattern.
The shared pattern: cost does not leave the business when visibility improves. It leaves when the action on that visibility is automated.
What’s next
Atlas is extending into inbound supplier operations and returns — both of which share the same event-spine-to-agent-action pattern, with new agent specialists. A shipper-facing Atlas control surface (for customers of Shipsy’s 3PL customers) is also in active development with design partners.