Abstract
Atlas PM is an operations platform for commercial moving and field-service businesses — walkthrough, quote, e-signature, job, invoice, warehouse, payroll — with an AI operator ("Atlas") embedded in every step. It was designed from field research inside a real commercial moving and logistics operation, built to ~62,000 lines of code, and validated end-to-end with realistic data. It has never run a live operation. This note is about the design question underneath it: how do you let an AI assistant act on data that costs money to get wrong — and what we found honest about the answer we shipped.
1. The question
Most "AI assistants" in business software are read-only: they summarize, they answer, they don't touch anything. The moment an assistant can write — create a job, issue an invoice, adjust payroll — it stops being a chatbot and becomes an operator, and the engineering question changes entirely: how does an AI earn permission to act on production data without becoming an operational risk?
Atlas is our attempt at an answer, in a domain where the mistakes are concrete: a wrong invoice, a double-booked crew, a payroll error.
2. What we built
A full field-service platform — multi-tenant from the ground up, every record scoped to a tenant_id — with an embedded assistant that does three distinct things:
It reads, within a boundary that holds by construction. Every tool Atlas can call is passed the authenticated user's tenant scope, and every database query filters on it. This matters more than it sounds: even if the model hallucinated the wrong company, the query underneath is already filtered — the boundary is enforced in the data layer, not in the model's good behavior.
It flags what needs attention, on its own. A proactive alert scanner runs real business rules against the live schema — overdue invoices (escalating to critical past a threshold), jobs pending confirmation today, unapproved draft timecards, quotes expiring within a week. Each alert carries its own severity and message. This is the "partner, not tool" thesis in its smallest useful form: the assistant surfaces the problem before you ask.
It acts — with a preview-then-confirm step. Write actions return a formatted preview first and execute only after explicit confirmation. Around that sits ordinary engineering discipline: a hard cap on the tool-calling loop, explicit handling for rate limits and permission errors, required-field and format validation before anything reaches the database.
3. The honest part
Here is the nuance we insist on stating, because it's the kind of thing marketing usually hides: the confirm step is enforced by instruction, not yet by an independent backend state machine. Each write tool tells the model, in its own description, to preview first and execute only on explicit confirmation — and in testing against fictional data it held consistently. But the safety of that flow currently depends on the model following its instructions. The stronger design — one we consider a prerequisite before any partner runs Atlas on live data — moves the gate server-side: the backend holds the preview and issues a confirmation token the human controls, so the model can never fabricate its own "confirmed." Designing the pattern is step one; hardening it to a state machine is step two, and we're saying out loud which step we're on.
4. What it hasn't had yet
The platform is built and validated end-to-end; what it has never had is a real operation stressing it under live conditions. That's not something a lab can manufacture on its own — it's the next test this research points to, and the honest reason the status below says "never run live" instead of something more flattering.
5. Findings
Graduated trust by operation type is a workable pattern: reads free within scope, writes gated by an explicit human step, the agent instructed never to skip it. Tenant isolation belongs in the data layer, not the prompt. Proactive alerting — business rules the assistant runs unprompted — turned out to be the feature that most makes an assistant feel like a colleague rather than a search box. And the limit above (confirm-by-prompt vs. confirm-by-state-machine) is the clearest next piece of research this project points to, applicable far beyond logistics: any domain where AI touches data that costs money to get wrong.
6. Status
Built and validated end-to-end against demonstration data; never run against a live operation. Its design came from field research inside a real commercial moving and logistics operation. What's next is the limit named in §3: hardening the confirm step from a prompt-level instruction into a backend state machine — that is the prerequisite before this runs on anything live.
Research home: blackicelabs.ca/research