I was sitting with a friend who runs engineering at a healthtech startup, big name, redacted. PHI on the line, audit obligations, the kind of company where a wrong move means a press release no one wants to write. He had been working through the AI tooling market for a few weeks, evaluating what was available against what his organization actually needed. Each option solved a piece. None gave him a coherent answer for the whole.
When I asked him what he actually needed, he thought for a while and said: “I need somewhere to build it, somewhere to run it, a way to see what it’s doing, and a way to avoid it going off the rails.”
That sentence sketches the AI surface he needed. Four parts (Build, Run, Observe, Control) are the lifecycle stages of an AI app or agent inside an enterprise, in roughly the order they happen. Add a fifth stage, Secure, for the security-led audience (CISO at the board table, compliance officer facing the EU AI Act, defense customer facing classification requirements), and you have the full surface: BROCS.
This post is about why those five are the right stages, what each one looks like in production, and what happens when an enterprise tries to deploy AI with one of them missing.
Build
Somewhere the technical team builds AI apps and agents. The IDE for the developer is the obvious surface; the actual Build layer is much wider. It includes the analyst running queries against a data agent, the operations team assembling agentic workflows, the business user putting together an internal app in a no-code builder. The whole technical organization (and increasingly the rest of it) needs a Build layer that works for all of them.
The tool stack inside Build has expanded fast. IDEs, notebooks, app builders, agent builders, document automation, deep research, chat, terminal, data tools. Five years ago this was one product, the IDE, for one audience. Today it has to compose across many tools and many roles. An enterprise that has to integrate five separate vendors to get its people doing AI work spends the productivity gain on integration debt.
What happens in organizations without a Build layer is the case I see most often. The team needs to ship. The org has no sanctioned AI tooling yet, IT is somewhere in the middle of a Copilot pilot, the work cannot wait. So people sign up for personal accounts. They prototype, useful things get built, and shadow exposure accumulates underneath, the kind the security team will eventually spend a quarter cleaning up. An organization without a Build layer does not slow down. It routes around itself.
Run
The apps and agents have to execute somewhere. Agentic AI complicates this beyond a normal application runtime. Agents hold state, call into internal systems, run multi-step workflows, fail in ways that look nothing like a 500. Whatever they execute on has to absorb all of that inside the customer’s perimeter, against the customer’s data.
The current AI tooling market has mostly skipped this stage, on the assumption that the customer’s existing infrastructure will absorb whatever workload the AI tools produce. That works for a demo. Production breaks it. The first time a real agent has to write back into a real system inside an enterprise, the runtime question, the identity question, the network isolation question, and the failure-mode question all show up at once, and the vendor who only shipped the IDE has nothing useful to say.
Going all-in on a single vendor that does include a runtime is the inverse failure mode. Another company I have worked with tooled the entire AI lifecycle through one platform. Orchestration broke regularly. The vendor’s fixes did not stick, and there was no path to switch because nothing about the setup was portable. Their environment is two different public clouds and an on-prem datacenter, none of them connected to each other. The team spends real time jumping through hoops to move data between them and to run reports against the whole. Deploying an application across all three is not currently a serious topic of conversation.
Observe
Once an app or an agent is running, you need to see what it is doing. Logs and metrics from the runtime are table stakes. On top of that, the agent emits its own event stream of calls made, responses received, and decisions reached, and the audit chain over all of it has to hold up against tampering. That stream is the substrate Control acts on.
This is the stage that gets skipped most often, and the one that bites first when something goes wrong. An enterprise that cannot explain in writing what its AI did last Tuesday will be blocked from deploying it. The auditor blocks, then the CISO blocks, then the customer blocks. The audit chain is the price of admission to enterprise AI in 2027 and beyond.
Control
Now that you can see, you have to act. Policy enforcement, role-based and attribute-based access, compliance frameworks, incident handling. Control is the closed loop where the platform acts on what Observe surfaces. It sits in the request path between the agent and the LLM, between the user and the data, between the policy on paper and the outcome that lands in production. Anything that lives outside the request path is observability with a fancier name.
This is the stage the CISO cares about. It is also the stage most AI tooling claims to have. Most do not. They have telemetry and a settings page.
Secure
The S is for the security-led audience. Control is the day-to-day governance layer in the request path. Secure is the structural posture around the apps and agents in production: SOC 2, GDPR, HIPAA, EU AI Act, NIST AI RMF. The compliance pack the CISO hands the auditor. The risk register that survives counsel review. The incident response process the board can attest to.
Not every organization carries the same compliance weight, and not every conversation needs the S. For a healthy chunk of organizations, BROC is enough. For a CISO conversation, or any sale into a regulated industry, the S has to be present from the beginning.
Why these five and no other set
I get asked why these stages and not some other set, say Acquire, Train, Deploy, Operate. That second set is the vendor’s mental model. It maps to how AI products are built and sold internally. BROCS maps to how the operator thinks about the work. Nobody asks themselves whether they have a training pipeline. They ask whether, if they let this thing run inside their company, they will be able to see what it is doing, control it, and prove it to an auditor. The framework that wins adoption is the one that matches the operator’s mental model.
Kubernetes versus OpenStack is the canonical version of this. Kubernetes mapped to how operators think about their work (containers, services, deployments). OpenStack mapped to how vendors organized their product lines (compute, storage, networking). The framework that earned the operator’s language eventually ate the one that did not. Most AI tooling vendors are currently in OpenStack mode, pitching their product surface instead of the operator’s workflow.
What happens with a stage missing
Two recent public incidents at McDonald’s make two of the failure modes concrete. They are separate deployments and separate vendors, but both are AI agents put into production without the stage that would have caught the problem.
In mid-2025, security researchers Ian Carroll and Sam Curry reported that McHire, McDonald’s recruitment platform built on Paradox AI’s “Olivia” chatbot, had an admin login protected by the default password “123456” and an insecure direct object reference in an internal API. Personally identifiable information and chat histories for roughly 64 million job applicants were accessible. Paradox patched it within a day of disclosure. That is a Secure failure: the compliance posture and access controls a regulated customer expects were not present in the deployment of the agent. A password of “123456” on the admin path of a recruitment chatbot is not a finding from a deep audit. It is the first thing any structured SOC 2 readiness review would have caught.
Separately, McDonald’s customer-support chatbot was prompted with a technical request and obliged, producing output entirely outside its intended scope. The bot did not go rogue. It did exactly what it was structurally capable of doing. That is a Control failure: guardrails layered on after deployment cannot constrain an agent that was never scoped at architecture time. The request path between the agent and its capabilities had no gate. What looked like a customer-service bot was, functionally, a general-purpose model with a logo.
The other failure modes follow the same pattern. Without a Build layer, the technical organization at large never gets moving on AI apps and agents; everything stays a side project for a few senior people. Without Run, the pilots are stuck in notebooks and die on the way to production. Without Observe, nothing earns the trust to deploy in the first place.
The executive who funded the project then concludes that AI does not work for the enterprise. This is not the lesson the experience actually teaches.
The architectural shape
The five stages are independent and composable. Each one is useful on its own. The value compounds when they tile cleanly across the lifecycle.
That tiling is what the current market has not figured out. Most AI vendors ship a product that occupies one stage and pushes the other four onto “your infrastructure” or “your governance tooling.” The customer is then on the hook for integrating across three to five products, contracts, and audit processes. The integration cost usually equals the productivity gain that motivated the project. Net zero.
The other cost of multi-vendor delegation is splash damage. When you delegate Build, Run, or Secure to a third party, their bad days and bad decisions become yours. The following three incidents all happened in the last two months. Vercel’s April 2026 security incident started at a third-party AI tool used by one of their employees, propagated through Google Workspace into their internal systems, and ended with API keys and tokens exposed for a subset of Vercel customers. Lovable.dev published its own incident response for the downstream effect on its platform, because Lovable customers were affected through infrastructure they did not directly select. A month later, Railway suffered an eight-hour platform-wide outage after Google Cloud’s automation incorrectly suspended Railway’s production account. Railway took full responsibility for the architectural dependency, which is honest of them, but the trigger was a decision outside their control. The next variation of the Railway story is predictable: one platform customer hosts something that trips an upstream content or abuse policy, the platform’s account gets terminated by automated enforcement, and every other customer on that platform goes down as collateral. None of these vendors is incompetent. The pattern accelerates as more of the AI tooling stack depends on more upstream services, not the other way around. When the layer that matters lives outside a perimeter you actually control, you absorb every blast radius upstream of you.
The architecture that wins ships the full lifecycle as a composable system, designed to deploy inside the customer’s perimeter, with each stage useful standalone and each one stronger when used with the others. The future of enterprise AI is hybrid. Apps and agents will run across public clouds, private datacenters, and edge environments inside the same organization, and the platform has to absorb that natively rather than ship a separate product per environment. Structurally, that makes the platform an operating system. A foundation that apps, agents, and governance all run on. The OS underneath the AI surface.
Short version: own your data, own your cloud, and simplify how you operate inside both. Anything else triples the overhead of managing five different tools and inherits every upstream vendor’s incident along the way.
That is what BROCS describes, and that is what I am building toward at Calliope AI. Three products that tile the BROC lifecycle, with Secure as the structural posture for regulated customers. The framework stands on its own regardless of who builds it. If you are working on anything in enterprise AI right now, whether a vendor product, an internal platform, an integration project, or a buying decision, walk through the five stages in your design and check that each one is present and that they compose. If a stage is missing, you will know which one by the time the deployment is six months old.
More on each stage in the coming weeks. Build is up first, because that is where most of the current vendor noise is, and where the contrast is sharpest between the consumer-shaped tools that dominate the market today and the enterprise-shaped platform a regulated customer actually needs.
