Read-only by design — and why the safer answer is also the more useful one
One transmission a month. Plain text. Three things from the world of AI-orchestrated operations. No tracking pixels. No marketing automation.
1 From the field: every CIO asks the same question on the demo
In the conversations I've been having with operators, one question keeps surfacing — usually from the CIO or the head of supply chain, usually early:
"Will Major Tom act on its own?"
It is the right question. It is also the one most AI platforms answer badly. The OpsATC.AI answer is short: no — by design, permanently. Major Tom does not issue POs, reroute shipments, or post journals to your systems of record. He reads, reasons, cites, and recommends. The clicks belong to the operator.
That answer is usually heard as the weaker one — the platform that talks about the work instead of doing it. The rest of this issue argues the opposite: read-only against systems of record is the architecturally correct posture, not a stopgap. The safer answer is also the more useful one. Forward it freely.
2 The pattern: read-only by design
The agentic-AI literature collapses this question into one dial: advisory on the left, autonomous on the right, with the assumption that the right answer is somewhere in the middle and that any platform stuck on the left is confessing immaturity. OpsATC.AI's position is that advisory-only against systems of record is the architecturally correct answer, not a stopgap. Five reasons.
Audit is trivial. Every recommendation is read + cite + log. Nothing changes in the customer's systems until a human commits, which means the customer's own audit trail — the one their auditors and regulators already know how to read — captures every action that ever touched a system of record. There is no second audit log to reconcile.
Blast radius is zero. The agent cannot break anything in production. A misfire becomes a bad suggestion, not a bad transaction. The recovery from "Major Tom recommended the wrong vendor" is the operator not clicking the card. The recovery from "an autonomous agent issued a wrong PO" is a whole other category of incident.
Regulatory posture stays clean. There is never a question about who acted on the customer's ERP — it was always the operator, identifiable, logged, with the recommendation card archived alongside. Nothing about SOX, GxP, ITAR, or trade-compliance reviews gets harder because Major Tom is in the picture.
Operator agency is preserved. The platform is amplification, not replacement. Major Tom compresses the time between "something is wrong" and "the operator has the right three options sourced from the right three systems." The judgment call stays with the human who is accountable for it.
There is a carve-out — and it matters. Major Tom does write, but only to OpsATC.AI's own tenant: notes, scheduled prompts, configuration, and draft artifacts like an email body or a brief that the operator reviews and sends from their own system. Writes within OpsATC's tenant and writes against the customer's ERP are different things. The first lets the platform function. The second is what we refuse to build.
The two bad patterns in the market are easy to name. The fully autonomous AI ops platform requires a level of model and connector trust that no audit committee in regulated supply chain will underwrite this decade — and arguably should not. The advisory-only AI assistant that secretly wants to graduate is confessing that its model is wrong: it treats advisory as a stepping stone rather than the destination. OpsATC.AI is neither. Read-only against systems of record is the doctrine, permanently.
3 What we built this month
Two pieces of the read-only doctrine moved from design into code this month. Both are architected and implementation-complete; both deploy with the first design-partner pilot.
Write-gates registry. Every MCP adapter in the platform declares, at the protocol layer, what it can and cannot do against the target system. For every adapter against a customer system of record, the registered capability set is read-only — period. A CI lint runs on every commit and fails the build if any adapter tries to register a write call against a system of record. The carve-out for OpsATC.AI's own application data (notes, scheduled prompts, draft artifacts) is the only place writes are permitted, and it is registered separately. The architecture decision is captured in ADR-0020; the lint and the registry are implementation-complete and travel with the first pilot.
Recommendation Card component. The structured unit Major Tom returns to the operator. Every card carries the same shape: the context the agent observed, the cited sources from each system of record, the suggested action, and the call-to-action button — which reads "approve in your system", not "approve and execute." The wording is the doctrine: the operator commits in their own UI, against their own credentials, against their own audit log. The component is implementation-complete; the design-partner pilot is where we learn which fields operators read first, which they ignore, and where the card needs to compress further.
If you are at a distributor, contract manufacturer, or integration shop, the read-only-by-design framing is portable — borrow it for your own AI-governance conversations whether or not OpsATC.AI is on the shortlist. The reason it works is that it survives the audit-committee meeting, not the marketing slide. If you want to talk through how it applies to your own workflows — design partner or not — send a note to [email protected]. The design partners we sign are how we prove the doctrine holds in the field. No sales motion attached.
Tom out.