Your fleet operations team,
made of software.
You hired engineers to build robots. They spend their week babysitting them. This is the ops layer that takes that week back — governed, audited, and stopping at every gate you set.
Where this actually stands
The platform underneath is in production today, running real businesses. The robotics ontology and the connectors are not — we build those with the first design partner, against a real fleet and real data rather than a demo.
We'd rather lose you here than in the demo. If you want the full picture of what exists, the feature list is public.
A specific company, not a category
Robotics companies with 50–500 units in the field and 20–150 people — past pilot, into the deployment scale where operational load is crushing a small team.
The problem
Every new site adds operational load, so the ops headcount grows in a straight line with the fleet.
What you do instead today
You hire a fleet operations or deployment engineering team that scales linearly with unit count. That headcount line is what this replaces.
A fleet operations engineer costs $150k–$220k fully loaded. That's the line this is priced against — not a per-seat software budget.
11 employees, each with one job
Every one produces an artifact you can check, and stops at a gate you set.
Fleet Watch
Adapts from what's builtWatches every deployed unit and catches the abnormal one before your customer does.
- What you get
- An incident with severity, affected units, suspected cause, and the log segments that support it.
- Where it stops
- Detects freely. Paging a human or contacting a customer needs approval.
Root Cause
Built with youPulls the logs, finds the failure, and writes the RCA.
- What you get
- A written RCA with the failure timeline, the exact log segment as evidence, and a confidence-scored cause.
- Where it stops
- Published as a draft. An engineer signs it before it reaches the customer.
Release Gate
Built with youReplays every policy or software update against your accumulated real-world failures before it reaches the fleet.
- What you get
- A pass/fail report with per-scenario deltas and a list of newly failing scenarios linked to the incidents they came from.
- Where it stops
- Blocks the release. A human can override, and the override is logged.
Data Curator
Built with youTurns what the fleet actually did into training and evaluation assets, without anyone deciding to do it.
- What you get
- Versioned datasets and scenarios, plus a weekly summary of what your fleet learned.
- Where it stops
- An engineer confirms a scenario before it can block a release.
Field Service Dispatcher
Adapts from what's builtGets a human to the robot with the right part already in transit.
- What you get
- A dispatched work order carrying the diagnosis, the shipped part, and the customer already notified.
- Where it stops
- Cost threshold on parts and travel.
Spares & Wear Forecaster
Adapts from what's builtPredicts which component fails next and pre-positions the inventory.
- What you get
- A ranked reorder list with predicted failure windows and stockout risk.
- Where it stops
- Purchase authorisation above your threshold.
Uptime & SLA
Adapts from what's builtTracks contractual performance per customer, computes credits, and warns you before a breach.
- What you get
- The monthly SLA report with every number traceable to the telemetry behind it.
- Where it stops
- Anything issuing a credit or touching an invoice.
Deployment Onboarding
Adapts from what's builtStands up a new site the same correct way every time.
- What you get
- A verified onboarding record with calibration proofs and a go-live sign-off.
- Where it stops
- Human sign-off on go-live.
Customer Front Desk
Running todayAnswers your customers 24/7 — status questions, incident reports, scheduling.
- What you get
- A triaged, logged interaction with the right internal action already taken.
- Where it stops
- Anything committing to a timeline or a cost.
Safety & Compliance
Adapts from what's builtLogs every safety-relevant event and keeps the record a regulator would accept.
- What you get
- The filed report with a complete, immutable evidence chain.
- Where it stops
- Everything. A human signs safety filings.
Margin & Unit Economics
Running todayComputes true cost per robot-hour, per site, per customer.
- What you get
- Unit economics that drill down to every underlying transaction.
- Where it stops
- None — it only reads.
The part that already exists
These six subsystems are in production. A vertical changes the objects in the graph and the tools the agents hold — not the engine.
The ontology
A typed graph of your business with row-level tenant isolation, PII classes masked from agents by default, and provenance on every fact.
The action engine
Every state change resolves, validates against a schema, passes an approval gate, checks a precondition, snapshots before and after, and writes exactly one audit row — including the denials.
Governance
A role × risk-tier matrix enforced in the engine rather than the UI, plus per-tenant and global kill switches.
The agent runtime
140 skills, 44 tools, crews that finish multi-step jobs, and delegation between agents with verification.
The front office
Voice, SMS, email, and web — answered 24/7, in over 100 languages, booking into a real calendar.
Cloud compute
The agent's own sandboxed computer for work that outlives a request, metered and capped per plan.
What breaks when agents do real work
These are the failures that only appear in production — and the reason a fleet or a constellation is a serious place to run this rather than a demo. Every one is shipped and tested, and none of it is vertical-specific.
Delegation that can't escalate
One agent hands work to another with a strict subset of its own authority — never more. The chain is depth-limited, cycle-free, and draws on one shared budget, so an agent can't delegate its way around a spend cap.
Cost per completed job
Every model call, tool call, and sandbox minute in a chain rolls up to the job a person actually asked for. The figure includes the attempts that failed, because a system that fails half the time at $0.40 a win really costs $0.80.
Outcome evals, not prompt evals
Success is asserted against the records, not the transcript. State is captured before and after, so the agent gets no credit for a booking that already existed — and a job that hit its goal but also messaged the wrong people is scored as a failure.
Memory that can be wrong
Contradictions are caught at write time. What a customer stated outranks what an agent inferred, regardless of which arrived later. Facts decay at a rate set by how fast that kind of fact actually changes, and corrections supersede rather than delete — so you can still reconstruct what was believed on the day a decision was made.
One customer, every channel
The same person across a phone, an email, and a web form resolves to one record. Deliberately cautious: a matching phone and name merges, a matching address and surname does not, because that's a household — and a wrong merge is a privacy incident, not a duplicate.
Lifecycle and offboarding
Dormant, unowned, and over-scoped agents surface without anyone maintaining a list. Retiring one revokes its access immediately, forces its in-flight work to be reassigned, and keeps the full record — an agent with live tasks and no successor cannot be retired at all.
Undo, described honestly
Every connector action declares what reverses it. Most things can only be offset, not undone: a refund is a second transaction the customer can see, and a sent email cannot be recalled at all. You're told which is which before you approve, not after.
Portability
Your agents, ontology, and memory export as a documented open format — including a statement of what it can't contain and why. Credentials never travel; they're the provider's, scoped to us, and exporting them would be a security failure rather than a feature.
The consequence gradient is why this matters more here than in a salon. A wrong invoice is embarrassing; a bad policy release reaches a machine, and a wrong command reaches something you cannot service. Anything at that end is built as a recommender that physically cannot execute.
What robotics looks like as a graph
Why every fact carries a time
“Which policy version was running on unit 14 when it failed, and what did we believe its calibration state was at the time?” is unanswerable without validity windows on every fact. Every RCA depends on that question — and so does every legal one.
What you'd be building against
The ontology API, the MCP endpoint, and the typed SDK are live and in production. Access is granted directly — there's no public signup for these verticals, so you talk to us and we issue the credentials.
Pipe your fleet telemetry in
Ontology API + typed SDKPush unit health, interventions, and task outcomes from whatever you already run — Grafana, a Postgres table, an S3 bucket of episode logs. Once it's in the graph, every agent can reason over it.
Wire an incident to a work order
Actions API + approval gateTrigger a dispatch when a unit crosses a wear threshold, with the part and the technician chosen from your own inventory and roster.
Give your engineers the fleet in chat
MCP + Slack/TeamsYour team asks “which units are running policy 4.2 and have intervened more than twice this week?” in Slack or Teams and gets an answer from live data.
Build an agent nobody here thought of
Agent runtimeDefine its prompt, hand it a scoped tool set, and give it a risk tier. It inherits the approval gates, the audit trail, and the kill switch without you writing any of that.
Put fleet answers in your own UI
Scoped API keysEmbed the answers in the dashboard your customers already log into, rather than sending them somewhere new.
REST API & SDK
Scoped keys, a typed client generated from your own schema, and OAuth for multi-tenant apps.
Read the docsMCP endpoint
Point Claude, Cursor, or your own agent at your workspace and let it query and act through the same governed path.
How it worksAgents & crews
Define your own agents and multi-step crews. They inherit the approval gates, audit trail, and kill switch for free.
See the runtimeHow you get access
Developer credentials are issued by us, not signed up for. Tell us what you're building and we'll scope the keys to it — read-only if that's all you need, action-invoking if you're automating something. It's a conversation, not a form, because at this stage every integration teaches us something about the robotics model.
Request developer accessWhat we do rather than you
Defining brand-new object types — a Robot, a Satellite, a Pass— runs through us. Type changes reshape a tenant's whole graph, so they go through an internal admin rather than a public endpoint. You query, act, and build agents against the model; the robotics schema itself is what the design partnership adds.
The questions you're about to ask
Is this available today?+
The platform is — the ontology, the action engine with approval gates and audit, the agent runtime, and the front office all run in production for existing customers. The robotics schema pack and the fleet connectors are not built yet. We build those with the first design partner, which is why we're looking for one rather than selling a signup.
Why would you build this if you sell to salons and contractors?+
Because it's the same architecture. A fleet of robots and a fleet of service vans are both instrumented assets producing events that need interpreting and acting on, with a human who stays accountable. The engine doesn't change — the objects in the graph and the tools the agents hold do.
Our engineers would just build this.+
They'd build one of these. Nobody builds eleven. The SLA reporter is a week; the eleven together with a shared ontology, an approval ladder, and an audit trail is a team-year — and it's the year your engineers weren't building robots.
What stops an agent from doing something dangerous?+
Every action runs through a policy engine before it executes, not after. Actions carry a risk tier, and the tiers map to who may invoke them. Anything that costs money or touches a robot sits behind an explicit gate, and there's a per-tenant and global kill switch. On the highest-consequence work we design the agent as a recommender that cannot execute at all.
What does a design partnership involve?+
You give us access to a real fleet's telemetry and one operational problem you'd otherwise hire for. We build the schema pack and the first three agents against your actual data, not a demo. You get them at a price that reflects the fact you're the one making them work.
We're looking for one robotics design partner.
Not ten. The first one shapes the schema pack and gets the agents built against their own data — at a price that reflects being the reason it works.
Start the conversationMost useful if you have 50+ units in the field.