AI shouldn't replace your operators.
It should make them ten times stronger.
Six things OpsATC.AI commits to, in the architecture and in the design-partner contract. If any one is broken on day one, we want to hear about it before you sign.
Two right decisions can still cost you a customer.
Two buyers at the same contract manufacturer. The same customer build. Different supplier portfolios, and no signal between them. One $14,000 expedite that solves nothing. The story explains why orchestration has to read across portfolios, not just inside them.
It wasn't my portfolio.
Both buyers, asked separately, after the variance landed.
Designed to make your team stronger. Never to make it smaller.
OpsATC.AI's objective is never to reduce headcount. The objective is to take the operators you have (the planner who knows the H100 line, the buyer who knows the supplier, the customer-ops lead who's been on the account for nine years) and connect them more directly to the ecosystem they already run.
The Captain doesn't replace the analyst. She gives the analyst a Monday morning where the data is already gathered, the exceptions already surfaced, the response options already drafted, so the analyst spends the day on judgment, relationships, and the work AI cannot do. That's a ten-times-stronger operator. That's the company that wins the next decade.
What OpsATC.AI does for your team
- ✓ Eliminates the swivel-chair tax: no more 40-tab Mondays
- ✓Surfaces the exception before it becomes an escalation
- ✓ Drafts the response so your analyst can refine, not author
- ✓ Connects the field tech, the planner, and the CFO to the same source of truth
- ✓ Makes tribal knowledge visible and shareable
What it never does
- ✗ Pretend to have your nine-year planner's judgment
- ✗ Act on a system of record without a human in the loop
- ✗ Get measured on headcount reduction in the design-partner contract
This is what "compress decisions" means in practice: three to five items per persona per day, ranked by impact. Everything else is visible on demand, never pushed. The agent is tuned to reduce notifications, not multiply them.
The state of the build, in numbers, and what's next on the calendar.
Honest-stage means publishing the math, not the marketing. Here's what's scaffolded today, what's production-shape, and the dates we're driving toward.
Accepted ADRs, each tracing a design choice to its constraint and trade-off.
Platform adapters across the supply chain stack. 141 are built to our Tier-1 rubric, including SAP S/4HANA, Oracle Fusion ERP, and Manhattan Active WMS. The rest are architecture-ready scaffolds that activate per customer, plus 8 generic adapters. Search the full catalog →
Write-gate registry entries, default-deny with an audit trail. The Captain is read-only by default, and every system-of-record write is gated (per ADR-0020).
Forward-only database migrations on the multi-tenant Postgres schema. Tenant isolation is enforced with row-level security and tested under multi-tenant fixtures. See Data Governance below.
The library is a factory, not a catalog. The 30-adapter foundation is the customer-pull anchor; the codegen pipeline is the production line; parallel implementer waves are the volume engine. Together they make the 695-catalog defensible as throughput rather than as inventory.
30 platforms · foundation tier
Production-Shape Foundation. The systems we expect most enterprise operators in our 6 supported verticals to run. Today: 5 (SAP S/4HANA, SAP ECC, Oracle Fusion ERP, Manhattan Active WMS, Microsoft Dynamics 365 Business Central). Target: 30. Each one hand-crafted with normalized domain reads, validated against fixtures synthesized from the vendor's published API documentation. These are not recordings of a live system, and vendor-sandbox validation is pending per adapter.
70 platforms · codegen-accelerated
Codegen-Accelerated Library. Vendors with well-formed public OpenAPI / OData / WSDL / GraphQL specs. Generated via the codegen CLI; senior implementers apply auth + mappers + fixtures via parallel implementer waves anchored in packages/mcp-codegen. Eight generic protocol adapters (JDBC, OData, OpenAPI, GraphQL, SFTP, SOAP, Webhook, X12) act as configuration-only multipliers. Many vendors drop in with no new package required.
~550 scaffolds · long tail
Just-In-Time Long Tail. The rest of the 695-directory catalog, every vendor not in Phases 1-2. Built by the customer's senior implementer using the codegen pipeline plus framework when the customer's specific stack reveals the need. Each is registry-discoverable with an auth strategy declared, and elevates to the Tier-1 rubric on customer signal rather than on a marketing calendar. This is how OpsATC covers an arbitrary stack on day one, without overstating depth.
Honest-stage framing: today's library is 141 connectors built to our Tier-1 rubric (each with a non-stub read path and replay fixtures written against the vendor's documented API contract, not recordings of a live system, and not yet exercised in CI) of 695 catalog directories. Live-sandbox validation is per-adapter onboarding work; SAP S/4HANA, New Relic, Confluence, and PagerDuty are proven live end-to-end today. The remainder are architecture-ready scaffolds: auth strategy declared, contract satisfied, registry-discoverable, OpenAPI-mappable. Scaffolds move to implementation-ready in 30-90 days at onboarding via the codegen pipeline. Breadth is not overstated as depth.
Q3 2026 (targeted)
Founding senior-engineer hire in progress (target July 2026). MVP in active development for the first design-partner pilot (Captain orchestrator, five production-shape adapters, full Trusted Advisor flow, audit trail, tenant isolation), not yet shipped to a customer.
January 1, 2027
Phase I production launch. SOC 2 Type I and an independent penetration test budgeted, not yet initiated; Type II observation window beyond the current planning horizon. EU residency targeted Q1 2027. Adapter library deepens just-in-time as pilots add platforms to their footprint.
5-day read · weeks to first outcome
5-day: design-partner accelerated track, available at pilot launch, read-credentialed and answering live operational questions inside one work week. Weeks, not months: the onboarding cadence to first measurable operational outcome: a missed cut prevented, an expedite held back, an exception triaged before escalation. The accelerated track is a design-partner commitment, not a current production offering.
Dates are commitments to design partners, tracked under the same ADR + change-control discipline that produces the architecture set above. Slip exposure is communicated to design partners in writing as soon as a dependency moves, not at the milestone date.
The Captain finds the dirt before it produces a wrong answer.
Every operation's data is dirty when we start. Stale records. Missing identifiers. Duplicate keys. Two source-of-truth systems disagreeing about the same SKU. The legacy answer is a six-month data-cleanup project before the tool produces its first useful output. The Captain's answer is different: she surfaces what she finds and lets your operators decide what to fix. The Data Quality Detection Layer (architected in ADR-0023, landed in migration 0015) is the operational mechanism behind the Improve pillar. On-demand checks run in the demo today; the continuous, inline, and scheduled modes are on the roadmap.
Stale records
A record that the system of record claims is current but whose last-touch timestamp falls outside the window your operators trust for that record type. PO status not updated in N days. Inventory snapshot older than the cycle-count cadence. Shipment milestone past its expected event.
Missing identifiers
Records present in one system but missing the linking key needed to join them to records in another. Order without a customer reference. Shipment without a PO. PO without a part number. The downstream effect is silent under-counting in every report that depends on the join.
Duplicate keys
A primary key that appears more than once where the schema declares it unique. Same SKU created twice with different units of measure. Same supplier with two vendor IDs. Same shipment booked under two carrier references. Recommendations split across the duplicates and look smaller than they are.
Source-of-truth contradiction
Two systems that should agree about a record do not. ERP says on-hand 240; WMS says 180. Shipment booked in TMS does not appear in the carrier portal. CRM lists the customer as terminated; ERP keeps shipping. The Captain presents both, names which she trusts and why, and routes the discrepancy to an operator.
Schema drift
Source-system fields rename, retype, or repurpose without notice. The adapter that fetched a string yesterday gets a numeric today; the field that meant unit-cost last quarter now means landed-cost. Detected at the MCP boundary and surfaced before it propagates into a recommendation that uses the wrong value.
Reference-data gaps
Lookups missing from the lookup tables. A carrier in the shipment feed not present in the carrier master. A cost center on a PO not present in the GL hierarchy. A part number used in production that has no entry in the item master. The Captain sees the gap in the same query that would have used it.
The four modes work together. Baseline scans run at MCP connect time to establish a known reference. Inline checks run on every read The Captain performs, catching drift as it happens. Scheduled scans run on a background cadence per record type, catching what inline missed. On-demand scans answer operator questions in real time. On-demand checks run in the demo today; baseline, inline, and scheduled are on the roadmap. No mode is sufficient alone; together they form a defense in depth.
At MCP connect time
The first read of each source system runs a full structural and statistical scan against the schema and record set. Establishes the reference cardinality, identifier coverage, and value distributions. This is the "what does normal look like for this tenant" snapshot. Future reads are scored against it.
On every query The Captain runs
Every tool call The Captain makes through MCP runs a lightweight quality check against the records the call returns. Counts compared to baseline. Identifier completeness checked. Value distributions sampled. A finding flagged inline is surfaced to the operator alongside the answer that depended on it, not hidden in a backend log.
Background cadence per record type
A cadence-aware background scanner runs targeted checks per record type: POs every six hours, inventory snapshots daily, supplier master weekly, customer hierarchy on demand. Catches the slow drift that inline checks miss because they only see what the operator asks about. Configured per tenant; defaults align with common operational rhythms.
Operator-triggered deep dive
When an operator wants to investigate a specific finding ("are we sure the PO count is right for supplier X?"), they can ask The Captain to run a deep targeted scan. Full identifier match across systems, full value reconciliation, full record-level pivot. Slower than the other modes, more thorough, scoped to the question.
Findings are surfaced through the Trusted Advisor card pattern (per ADR-0020). The Captain describes what she found, names the records affected, proposes the fix, and routes the decision to a named operator. She does not write back to source systems without human approval. Data Quality Detection raises the signal; the operator decides the response.
The Captain is not the girl who cried wolf.
A detection system that surfaces every minor anomaly trains operators to ignore it. The Data Quality Detection Layer is severity-graded: informational findings stay in the background, threshold-crossing findings surface inline with the answer they affect, and material findings escalate to a named owner. Operators can tune the thresholds per record type, per portal, per role. Trust is a function of signal-to-noise; the layer is engineered for that ratio.
Augmentation only works if your team knows what they're augmenting with.
The augment-not-replace principle requires operators who understand AI behavior at a working level. Without that literacy, the agent runs unsupervised (dangerous) or gets quietly ignored (waste). AI fluency is part of what we deliver.
Knowing what to give the agent and what to keep. The Captain is good at synthesizing, summarizing, structuring, and routing. She is bad at judgment under deep ambiguity, relationship work, and accountability. Operators learn the line.
Asking clearly. Vague prompts produce vague outputs. Operators learn to write prompts specific enough that another planner reading them cold could produce a similar response. Context goes in. Constraints go in. The output gets useful.
Evaluating outputs critically. Operators learn to spot hallucination patterns, recognize when an answer is fluent but wrong, and know which kinds of questions the model is unreliable on, before acting on the response.
Verifying and owning the result. AI does not absolve accountability. The operator who acts on a recommendation is the operator responsible for it. Diligence is the verification habit, built in.
Built on Anthropic's AI Fluency framework, adapted for operations contexts.
Persona-specific training tracks
Each role (Operations Directors, Supply Chain Analysts, Process Improvement Leads, Customer Ops, Field Service) gets a tailored curriculum and hands-on workshops with your actual operational data, not synthetic scenarios.
Anthropic's Claude AI Fluency course
The foundation model behind The Captain is Anthropic's Claude. Anthropic publishes free AI fluency training: short, well-produced, accessible to non-engineers. Every operator who interacts with The Captain should take it. We pay for the time.
Ongoing enablement, not one-time training
Monthly office hours. New-feature briefings as the platform evolves. A literacy assessment in the Admin Portal so leadership tracks fluency progress. Operators who can direct the agent get the value; operators who can't, don't. We pay for the time operators spend reading The Neuron, a plain-English daily AI newsletter.
Anthropic's AI Fluency framework and The Neuron newsletter are independently produced and freely available. We are building OpsATC.AI on top of Anthropic's Claude foundation models; we are not affiliated with Anthropic or The Neuron beyond our use of their API and our recommendation of their content. Both recommendations are editorial, not commercial.
Four reasons we built on Claude, and the seam we left for everything else.
When you stake a company on a foundation model partner, you choose with the same care you'd choose a co-founder. Buyers ask why Anthropic and not the alternatives. Here's the proactive answer, and the honest caveat at the end.
Safety as engineering discipline, not marketing.
Anthropic published Constitutional AI, the Responsible Scaling Policy, model cards with capability evaluations, and an interpretability research program before most labs admitted alignment was a real problem. OpsATC.AI ships into supply chain, a domain where a confident wrong answer can route a wafer shipment to the wrong country. We needed a foundation model partner that treats "the model said something wrong" as an engineering bug, not a PR event.
Anthropic's release cadence pulled our architecture forward.
Claude Opus and Sonnet have shipped at a release cadence that has moved production primitives (tool use, long-context retrieval, sub-agent orchestration, computer use) from preview to ready faster than this category typically allows. The Captain's architecture (the select-tools / tool-authz / write-gates chokepoint plus the Trusted Advisor doctrine) only became feasible at Anthropic's late-2025 tool-use reliability. We design to the leading edge and let Anthropic's roadmap pull us forward.
A procurement checkbox, not a six-month negotiation.
Default no-training-on-customer-data. Workspace isolation. SOC 2. Zero data retention available. Audit logs. The legal review for using Claude on regulated supply chain data is a checkbox, not a six-month negotiation. For a pre-revenue company landing its first design-partner pilot, that's the difference between getting through procurement and dying in it.
A partner building the rails, not just selling tokens.
Anthropic publishes prompt-engineering guidance, runs developer education, maintains the Model Context Protocol (MCP) standard we build adapters against, and ships the Claude Agent SDK we run sub-agents on. MCP is the reason OpsATC.AI's connector strategy is even possible. Without an open protocol, we'd be writing 695 bespoke integrations against 695 vendor schemas. They're building the rail; we're running cars on it.
We chose Anthropic because they lead on the four dimensions above. If that changes, we'll change.
Our MCP adapter layer is model-agnostic by design. Connector work isn't Claude-locked. The Captain routes every model call through a vendor-neutral LLMProvider seam that ships in the codebase today, so the foundation-model vendor is swappable, currently powered by Anthropic's Claude. We chose Anthropic because they lead on the four dimensions above; cross-model validation against alternate frontier models is on the roadmap at the point they reach the tool-use reliability our orchestrator depends on, and is a conversation we're prepared to have with design partners whose vendor-diversification posture requires it. We've made the seam explicit so the cost of changing course is known, not hidden. Customer outcomes come first; platform fidelity comes second. Today, Anthropic is the right partner, and the seam is there for the day that calculus changes.
A 7-state orchestrator with a read-only chokepoint. Zero autonomous writes.
CTOs scrutinizing the architecture ask the same question: how does the orchestrator actually work, per request? Architecturally The Captain orchestrator is a 7-state machine (ADR-0019) with a per-operation model router; its load-bearing control is the three-stage tool-governance chokepoint below, defended by ADR-0020 (Trusted Advisor doctrine) and implemented across packages/captain and packages/mcp-core. Three gates (select-tools, tool-authz, and write-gates) sit between the model's reasoning and any tool call, keeping write tools out of the model's tool list before it ever sees them.
select-tools
A role- and risk-tier tool filter. Adapters tag every tool read or write in their tools.ts; write tools are stripped from the model's tool list before it ever sees them (ADR-0020). The model can't choose a write tool because it never receives one.
tool-authz
A dispatch-time authorization gate. Before any handler runs, every tool the model tried to call is re-checked, rejecting anything unauthorized for the role, and any hallucinated tool name the model invented. Nothing reaches a handler unauthorized.
write-gates
The WRITE_REGISTRY classifies every declared high-risk write by risk tier (634 Tier-2, default-deny), the final backstop for the read-only doctrine. Recommendations exit as deep-linked RecommendationCards a human clicks; The Captain never writes to a customer system of record.
Three gates between the model and any tool call (select-tools → tool-authz → write-gates), every rejection audit-logged (ADR-0020).
Why the chokepoint matters.
A foundation model can call any tool it can reach. Without a chokepoint, "tool access" is an attack surface: a model that should be reasoning over read-only data invokes a write tool and updates a system of record. The three gates close that off. select-tools strips write tools from the model's tool list at selection time: adapters tag every tool read or write in their tools.ts, so the model never sees a write tool to pick. tool-authz re-checks every call at dispatch time and rejects anything unauthorized for the role, or any hallucinated tool name, before a handler runs. write-gates classify every declared high-risk write in the WRITE_REGISTRY and default-deny. Every rejection is audit-logged with its risk class.
Why there is no second path.
The doctrine is defense-in-depth, not a single check: a write would have to survive all three gates (be surfaced by select-tools, clear tool-authz, and pass the write-gates registry), and none of them permit it. There are no free-form agent loops; every request runs the same governed path from reasoning to a RecommendationCard, and The Captain writes only to OpsATC.AI's own tenant (notes, drafts, scheduled prompts), never to a customer system of record. (Distinct from OpsATC.AI's five-layer product architecture (Read, Reason, Analyze, Sync, Recommend) described on the Platform page; that describes the stack as a whole, the pipeline here governs what happens inside one Captain request.) Long-running multi-decision workflows (multi-stage approval chains with different decision-makers at each step) would require additional state and branching; those are on the post-GA roadmap, not in MVP scope.
Phase 1 versus Phase 2 enforcement.
The CTO due-diligence question is "what exactly enforces the no-autonomous-write doctrine?" Honest answer in two phases. Phase 1 (pilot scope, today): enforcement is runtime. The selectTools chokepoint filters write tools at tool-selection time; the write-gates registry in @opsatc/mcp-core holds ~634 high-risk adapter writes as defense-in-depth defaults-disabled entries (Tier 2); high-risk writes have no executable code path in their adapters (Tier 1); and a build-time CI lint (scripts/lint-write-gates.ts) refuses any PR that declares a high-risk write tool without registering it. Phase 2 (production hardening, pre-GA): cryptographic signature verification on RecommendationCard actions, single-use approval tokens that cannot be replayed, time-bound approval windows that expire automatically, and immutable cryptographically-signed audit-log entries. OpsATC.AI will not run against customer-production systems of record on Phase 1 enforcement alone. Phase 2 hardening is a pre-GA gate, named here so the timeline is on the calendar.
How The Captain learns your operation, without copying it.
Operators who have rolled out a forecasting tool, an integration platform, or a planning suite have heard this story before: "fourteen months to get it live, and it still doesn't have visibility into PLM." That timeline isn't an accident. It happens because the tool needs to copy your data before it can act on it. OpsATC.AI doesn't.
Six months before the first useful answer.
- Months 1-3: ETL pipeline build. Source-system extraction. Schema mapping. Data-quality cleanup.
- Months 4-6: Historical data load. Model training. Validation against known-good outcomes. Reconciliation reviews.
- Months 7-9: Pilot scope. Initial portal launch. Discovery of edge cases the model wasn't trained for. Re-training cycle.
- Months 10-18: Production rollout. Vendor-side support tickets when source systems drift away from the trained schema.
By the time the tool answers its first real question, your operation has changed underneath it.
Day 1 read-access. First measurable outcome in weeks, not months.
Based on projections and anticipated outcomes only; the actual timeline depends on individual customer circumstances and the level of access granted.
- Day 1: Read-only credentials on the systems you want orchestrated. The Captain can answer questions about live operational state immediately.
- Week 1-2: Field-mapping confirmation per connector. Sandbox validation. Operator training on the Trusted Advisor card interface.
- Week 2-3: First role-aware portal goes live with real users. Recommendations flow into operator queues. Adaptation happens on feedback, not retraining.
- Week 4+: First measurable operational outcome: a missed cut prevented, an expedite held back, an exception triaged before escalation.
The platform was useful from Day 1. The first defensible business outcome lands in the design-partner pilot window.
Pre-trained reasoning
The Captain brings general operational reasoning out of the box: supply chain, procurement, fulfillment, and exception-management vocabulary already understood. Your domain doesn't need to be taught.
Query in place
MCP is designed to let The Captain query your live systems on demand, the way an operator would open a tab. The history is already in your ERP. We don't need a copy of it.
Feedback-driven adaptation
Adaptation happens on operator feedback signals (accepted recommendations, overridden recommendations, the reasons given), not on retraining cycles. Your operation tunes the agent through use, not through preparation.
The same architectural truth is what makes the Buyer's Dilemma story possible: cross-portfolio visibility on the day The Captain is connected, not the day a six-month integration project finishes.
See it on your operation →Six commitments. They live below.
If a single one of them is broken on day one, OpsATC.AI isn't the platform you want, and we'd rather hear that early than later.
-
01 HITL
Human-in-the-loop, by doctrine
The Captain is advisory: she reads, reasons, cites, and recommends. She doesn't issue POs. She doesn't reroute shipments. She doesn't post journals. Those clicks belong to the operator. This is doctrinal, not a default. OpsATC.AI is not building write capability against customer systems of record. The clicks are yours, permanently.
-
02 No Data Training
No training on customer data, ever
Customer data is never used to train any foundation model. Anthropic's API terms forbid it. Our tenant-isolation architecture enforces it. Process improvements identified by the Process Intelligence Engine inside your tenant belong contractually and operationally to you.
-
03 Citation
Every fact cited. Every action logged.
The Captain doesn't say "operational health is 87/100." She says "operational health is 87/100, sourced from your ERP, your planning suite, and your WMS, computed at 6:00 AM." Every action is tied to a user, a role, a source system, and a timestamp. Phase 1 includes structured audit logging with write-gate enforcement. Phase 2 adds tamper-evident, cryptographically-signed persistent storage and exportability to regulated-industry audit formats.
-
04 Tenant Isolation
Tenant isolation: your data is yours
Per-customer data isolation enforced at every layer of the stack. No cross-tenant model fine-tuning. No "shared learnings" that leak one operator's IP into another's recommendations. Architecturally, your competitor's view never crosses your view, and your view never crosses theirs.
-
05 Augmentation
Workforce intent: amplify, never replace
Design-partner contracts explicitly do not include a headcount-savings clause. Outcomes we measure with you are cycle time, OTIF, exception MTTR, onboarding velocity, decision compression, never seats eliminated. The objective is to amplify the operators you have, not to enable their replacement. It is also designed to capture how your most experienced operators reach a decision, not just the record of what they decided, so that reasoning stays in the business when they retire.
-
06 Disclosure
What we don't yet know, and what we tell you up front
Foundation models hallucinate when they're asked to reason without grounded data. Long-running agent reasoning chains can fail in ways the agent can't self-detect. Compliance certifications take time. We tell you what we don't know, what we haven't built yet, and where the platform's edges are, before you sign anything.
A pilot fee, credited against year one. Three commitments you can hold us to.
OpsATC.AI is pre-revenue. The commercial shape below is honest framing: a posture and a pilot scope, not a firm price or a signed contract. Pricing is structured around your operation rather than your headcount: your vertical, your scale, the number of sites, and the number of connected systems. The design-partner posture below is offered consistently to the first three customers entering pilot before GA. Final terms are set per design partner in the SOW.
Materially-discounted rate, locked for the term.
Pilot customers lock their materially-discounted monthly subscription rate for the duration of their initial contract (1 year or 2 years, your choice). The rate stays flat through the term regardless of which length you choose. Commercial pricing post-design-partner is TBD and will be set against measured pilot economics; the pilot-discounted rate stays frozen through your contract whichever path you take.
Pilot fee, sized to your engagement.
Pilot fee: sized to the scope, scale, and complexity of your engagement, and quoted in your proposal. The fee is credited in full against your first-year subscription fees when you convert, applied ratably across the year so it offsets what you would otherwise owe. It covers the pilot engagement itself rather than sitting as a deposit, so it isn't returned separately. If you decide not to continue, the engagement simply ends: you keep the findings, the configuration, and a complete data export, and owe nothing further.
Marginal-pricing schedule, disclosed at kickoff.
Adding sites, integrations, or workflows during your contract term follows a marginal-pricing schedule documented in your pilot agreement at kickoff, not in a discretionary uplift conversation later. The cost of the next site, the next integration, the next workflow is in writing before you ever need it.
Materially-discounted monthly, locked
The pilot-discounted monthly rate stays locked for the full contract term (1 or 2 years, your choice) as a long-term benefit to customers who commit early.
Roadmap influence
Your KPI thresholds, persona library, and workflow shapes land in the shipped vertical configuration, not just inside your tenant. The platform you help shape is the platform that ships.
Direct founder access
On every recommendation The Captain produces against your data, every week of the pilot. Not a triage queue. Not a CSM proxy. Brian, in the loop, in writing.
Reference willingness optional
Optional, not contractual. Named design partners go public with their explicit written consent only, never as marketing. The first named partner will be a milestone, not an announcement.
Pilot duration: a focused window we scope with you, weeks not months, long enough to evaluate The Captain across a monthly close and a full exception and planning cycle.
Commercial pricing post-design-partner is TBD and will be set against measured pilot economics. We will not commit to commercial pricing numbers before they are measurable. The full as-deployed design-partner pricing detail lives in your pilot agreement. Reach out to [email protected] for a tailored estimate based on your vertical, scale, number of sites, and integration footprint.
A doctrine is not a business. Here is the compounding underneath it.
Three questions a serious operator asks before routing real work through us: what stops a frontier model plus MCP from doing this in eighteen months, how the economics compound, and how you will know it worked. Straight answers.
What a horizontal model can't cheaply copy
A frontier model plus MCP is the starting line, not the finish. The compounding asset is three things a general model does not have: governed, vertical-specific adapters hardened per system of record; a write-gate registry that classifies every action by risk tier; and the accumulated record of which recommendations your operators accepted, edited, or rejected, per tenant, never shared. The longer The Captain runs your operation, the more it is yours and the less a generic agent can stand in for it.
How the economics are designed to compound
A paid pilot fee, credited in full against a one- or two-year subscription. The pilot is a down payment on the contract, not a sunk cost. Land in one vertical; expand across sites and adjacent operator roles on the same tenant. Because The Captain reads read-only and cites rather than replicating your data, serving cost stays software-shaped, not data-warehouse-shaped. Retention is structural: the moat beside this is the reason year two is easier to keep than year one. Commercial numbers stay TBD until they are measurable. See the pricing posture above.
How you'll know it worked, and why we don't lead with a number
We won't lead with an outcome we haven't earned. The first design-partner pilot is instrumented against your own baseline on four operator metrics, cycle time, OTIF, exception MTTR, and onboarding velocity, measured before The Captain connects and again at pilot end, with the measurement method shown rather than asserted. The first published result will be a measured one, from a named partner, with their written consent. Until then this is the method, not a claim.
From "something's wrong" to a cited cause, in minutes.
An exception fires. An order is going to miss its cut, an ASN doesn't match the receipt, an OTIF number slips. Before anyone can decide whether to expedite, split, or hold, someone has to work out the probable cause and point to the exact record it rests on. That first stretch, from the alert to a cited cause, is where the morning goes.
The clock starts when the exception is flagged in your ERP or WMS. It stops at the first cause statement that cites a real source signal, the specific order line, carrier event, supplier ASN, or PLM note behind it. It ends at a cited cause, before anyone commits a fix. We measure the part The Captain actually affects.
The operator chases it across the ERP, the WMS, the carrier portal, and email, often half a dozen tools, and it can take a good part of a shift to reach a cause you can defend. (A practitioner's reality, not a benchmark.)
The Captain reads the linked records, reasons across them, and surfaces the probable cause with the citation attached, in one pass instead of a manual hunt. Direction and order of magnitude, not false precision.
A baseline window with The Captain off and a treatment window with her on, same exceptions, same systems. A blind reviewer scores both whether the cause is right and whether the citation holds, because a fast wrong answer is not a win. We publish the before and after, the accuracy, the citation rate, the sample size, and the dates.
The same read-reason-cite loop already runs against live systems today. The Captain issues a real read against a live vendor account and answers only from what she reads, read-only, with the returned data, not her wording, deciding whether the answer is grounded. It is the exact loop this card describes, exercised end to end.
Illustrative. "Today" is a practitioner observation. "Designed to deliver" is what the loop is built to do, to be proven in a pilot.
If you disagree with any of this, that's the call I want.
The principles above are settled in the architecture and the design-partner contract. They're not settled in my head. Pushback from an operator who has actually run an operation is the most valuable input the platform gets. Thirty minutes, direct with me.