Launchpad.
The agent layer. It reads one operational model of your business, decides within the limits you set, acts through the applications you run, and reports back.
Every application writes to one record of the operation.
A person is one record, whether the roster, the payroll or the events team is looking at it. A bottle is one record from the purchase order to the glass. A vehicle is one record from the maintenance window to the proof of delivery at the door.
That is what removes the integration project. There is nothing between the applications to keep in sync, because they are reading and writing the same thing. It is also what the agents reason over: one situation, seen whole, rather than six systems each reporting a fragment of it.
Sense, decide, act, report.
Launchpad runs one loop over the whole operation. What differs is how far you let it go on each capability.
Senses
A delivery lands, a shift is missed, a bottle sells out, an aircraft swaps. Each is a change to a record on the model, and Launchpad sees it the moment it is written.
Decides
It works out what should happen next against the rules you have set for that capability: approval limits, tolerances, duty hours, margin floors. A breach is an infeasible answer rather than a warning.
Acts
It acts through the application that owns the work: raises the order, re-solves the roster, holds the payment, drops the wine from the list. At the level of autonomy you chose.
Reports back
Whoever needs to know is told what happened and why, with the records attached. Every action is auditable, and every one can be undone by the person who owns it.
One short delivery, end to end.
An illustration of the mechanism, traced through the four steps. It is not a record of a real event.
A case arrives two bottles short
The receiving record is written at the dock with the count as it actually was. On the model that is a delivery, a purchase order, a supplier and a cellar that all just changed together.
Within tolerance, or not
The gap is checked against the tolerance you set for that supplier and that value. Below it, the stock simply adjusts. Above it, a discrepancy case is opened with the order and the delivery attached.
The supplier is told, payment is held
The dispute is raised through Procurement and the invoice is held to the received quantity. The list does not overstate the cellar, because the stock it reads is the count that was actually written.
The buyer sees a case, not a task
The buyer gets one message with the evidence and what was done. If the capability sits at “act, then tell me”, that is the end of it. If it sits at “suggest”, the same message asks for a decision.
You decide how much runs itself.
Every capability sits exactly where you put it, and moves when you are ready. Most groups start conservative and turn the dial up one capability at a time. Try it.
RosteringAutonomousIt runs the roster unattended, inside constraints it cannot break.
The spokes.
One application per team, one per operating function, and specialised applications built for a single trade. Each is a surface on the same model.
For teams
One application per team. Each is the place that team works from, and each reads the same operational model as the rest.
Rostering, HR, hiring and payroll on one record per person.
MarketingAudiences, campaigns and brand assets for the marketing team.
OperationsStandards, checklists, incidents and maintenance for the operations team.
FinanceCost, margin and close for the finance team, built from the operational record.
For operating functions
One application per function that moves money, stock or people through the operation every day.
Orders, receiving and landed cost, to the cent.
RecipesCosted recipes and menus, the same in every kitchen.
LoyaltyCRM and multi-brand loyalty across every outlet.
MessagingWhatsApp-first guest communications, one inbox for the group.
FleetDelivery operations for teams that run their own drivers.
EventsEvents, bookings and ticketing on the same record as the venue.
Specialised
Built for one trade or one sector, in the depth it needs. Grapestack for wine, OpenAir for aviation and OpenRail for rail.
Wine inventory, lists and allocations, tracked to the glass.
OpenAirThe aviation platform: crew, compliance and disruption as aviation-specific modules.
OpenRailThe rail platform: crews, rolling stock and timetables as rail-specific modules.
Built to orderA specialised application for your trade, on the platform.
Inside your perimeter.
Where the model lives, which systems it reads, and who does the work of getting it there.
On-premise
The platform and the models reasoning over it run in your own data centre. Nothing about your operation leaves a boundary you own.
Sovereign cloud
Run on a provider you already trust, in the jurisdiction your data has to stay in. We work inside your residency rules rather than around them.
Mission cloud
Hosted and run by us, for groups that want the outcome without the infrastructure. The same platform, the same model, the same autonomy controls.
- Connects to
- Point-of-sale, property management, payroll, telematics, accounting and scheduling systems already in place at each site
- Model vendors
- More than one, including models hosted inside your perimeter. Which one reasons over your operation is a deployment decision
- Data
- Yours. Exportable in full at any time, with the audit trail behind every action queryable for as long as you hold the deployment
- Engineers
- Forward-deployed. On site, learning the operation, building against the real workflow, and staying until it runs without them
- Governance
- We work within your security reviews, change control and procurement frameworks. Speed does not come at the cost of them
FAQ
It runs the loop. It senses what is happening across the operation from the model, decides what to do inside the limits you have set for that capability, acts through the relevant application, and tells the people who need to know. You choose how far it goes, capability by capability.
No. They work over whatever you have adopted. With one application they act on that application’s records. Each application you add widens what they can see and do, because it lands on the same model.
Point-of-sale, property management, payroll, telematics, accounting and the scheduling tools each site already runs. Mission reads from them and, where you allow it, writes back. Nothing has to be torn out on day one.
In your own data centre, on a sovereign provider you already trust, or on Mission’s infrastructure. The operational data and the models reasoning over it stay inside the boundary you choose.
No. The agent layer is built to run on more than one model provider, including models hosted inside your perimeter. Which one reasons over your operation is a deployment decision, and it can change.
The reporting surface over the operational model. Ask a question in plain language and it builds the report and keeps it current. It belongs to the platform rather than to any one application.