Enterprise AI Strategy: Build for Repeatable, Governed Work

What the CIO and CISO actually need to know

A pilot count is not a strategy. Neither is a model contract, a center of excellence, or a slide that says "AI-first." Each of those is an input. The strategy is the set of decisions that determine whether AI work still runs correctly, and can still be explained, eighteen months after the demo.

Here is the definition we use. An enterprise AI strategy is the set of choices about which work AI will take on, which parts of that work need model judgment, how access and action are controlled, and how results are measured and improved over the lifecycle. For agentic work, the choices that matter most are architectural. They decide whether an agent re-reasons every task on every run or hands the repeatable parts to software.

Four parts hold the strategy together:

1. Choose workflows. Start from the work, with named owners and systems of record, rather than from the model catalog.
2. Allocate judgment. Decide, step by step, what needs a model and what can run as code.
3. Govern access and action. Control credentials, permissions, and approvals at the point where the agent acts.
4. Measure and improve. Track outcomes and drift across the lifecycle, and feed what you learn back into the first three.

Model access is an input to all four and answers none of them. A team with the best model on the market still has to decide what it may touch, what it should never have to figure out twice, and who answers for the result.

What this article doesn't cover. It does not address portfolio prioritization, model evaluation, data governance, legal review, or workforce planning. Those are real parts of a strategy and each deserves its own piece. This one is about the execution layer, because that is where most agent strategies quietly fail.

The argument

Strategy begins with work

The unit of an enterprise AI strategy is a workflow with an owner, inputs, systems of record, and a definition of done. A workflow that crosses a billing system, a contract store, and a ticketing queue, and has to be explained to an auditor, is a strategy-sized object. "Use AI in finance" is a slogan.

Classify judgment and repeatable execution

Inside any workflow, some steps need judgment. Is this vendor name the same entity as that one? Does this clause permit the discount? Most steps do not. Matching a payment to an invoice on a reference number, writing a ledger entry, and sending a notification all behave the same way every time once someone has worked out the rule.

Most agents on the market re-reason both kinds of step on every run. That makes the repeatable work probabilistic, makes cost track usage, and leaves an audit trail made of model transcripts. The smartest agentic workflow uses the least AI to run. Spend the model on the steps that need it and move the rest into code.

The model still does real work under this design. It does less, and what it does is the part that deserves a model.

Govern agents where they act

A policy document and a system prompt are both statements of intent. Neither one stops an action. Governance has to live at the point where the agent touches a system: scoped credentials so the agent holds only the access the task needs, role-based permissions so the same rules apply to agents and people, and audit logs written by the system that performed the action. We make the longer case in governance at the point of action.

Make state and audit durable

A context window is a poor place to keep a workflow's memory. It is expensive to refill, it disappears when the conversation ends, and nobody can query it. State belongs in a database the workflow owns, with files in storage and a log of what happened. When state lives in an app, the work can pause for a human approval on Tuesday and resume on Thursday with nothing lost. Reconstructing what happened in March becomes a query rather than an archaeology project.

Scale through reusable apps

When an agent works out how to handle a repeatable step and builds an app for it, that app is available to the next workflow. The organization's library of governed software grows with use, and later work needs less reasoning. This is how the cost curve bends: front-loaded while the agent reasons through the step once, then flat as the app runs. The shape is structural. We are not claiming a percentage, and you should be wary of anyone who does without showing the workload. For the cost mechanics, see our notes on LLM cost management.

Where NIST fits, and where it stops

The NIST AI Risk Management Framework is the credible lifecycle reference for this work. NIST released AI RMF 1.0 on January 26, 2023, and describes it as intended for voluntary use (NIST overview; AI RMF 1.0 PDF). Its core is organized into four functions, and they map onto the strategy like this.

• Govern covers the policies, accountability, and culture that frame all other risk work. In our strategy, that is the owners, the approval rules, and the decision about who may grant an agent access.
• Map establishes context: what the system is for, who it affects, and what could go wrong. That is workflow selection and the judgment-versus-execution classification.
• Measure analyzes and tracks risk and performance. That is the logs, the exception rates, and the review of drift.
• Manage prioritizes and acts on the risks you found. That is escalation, rollback, and revising the app when the rule changes.

The AI RMF Playbook offers suggested actions for these outcomes and says of itself that it is "neither a checklist nor set of steps to be followed in its entirety." NIST also notes that AI RMF 1.0 is being revised, so check the current status before you cite a version to your board. Using the framework is not a certification, and it does not make an organization compliant with any law.

The distinction we want to hold is this. NIST describes what a risk-managed organization does. It does not tell you how to build an agent so that those outcomes are cheap to produce. The mapping above is our interpretation of how an app-layer architecture serves the framework. NIST has not endorsed it, and it has not endorsed Major.

What good looks like in practice

The following is an illustrative invoice-reconciliation workflow. It is a design walkthrough, not a customer deployment. Every figure and threshold is a placeholder for you to set.

| Workflow step | Model judgment needed? | App/code responsibility | Data/state held | Approval or audit control | |---|---|---|---|---| | Intake of invoice from email or portal | Rarely, only to extract fields from an unusual layout | Parse, validate required fields, create a record | Invoice record, original file in storage | Intake log with source and timestamp | | Match to purchase order and receipt | No | Deterministic match on PO number, amount, and vendor ID within a set tolerance | Match result and the rule version applied | Every match writes an entry attributing the rule and inputs | | Resolve an unmatched or ambiguous invoice | Yes | Assemble context: contract terms, prior invoices, vendor history; present to the model | Proposed resolution with the model's stated reasoning | Logged as a proposal, not a posting | | Post to the ledger | No | Write the entry with a credential scoped to that one action | Ledger entry ID linked to the invoice record | Scoped credential, role check, audit entry | | Escalate material or low-confidence cases | Only to draft the summary | Route by rule: amount above a set threshold, new vendor, or any exception the model flags | Approver, decision, and timestamp | A named person approves before posting |

Trace one invoice through it. A PDF arrives. The app extracts fields and creates a record. The match step compares the invoice to the purchase order and receipt in code, the same way for the ten-thousandth invoice as for the first. Most invoices end here with a ledger entry written under a credential that can write ledger entries and do nothing else.

One invoice does not match. The amount is off by a line item that looks like a freight charge. This is the only step where a model is worth its cost. The app gathers the contract terms and vendor history, the model reads them and proposes a resolution with its reasoning, and the app records the proposal. Because the invoice exceeds the approval threshold you set, the app routes it to a named approver. The person approves, the app posts the entry, and the log holds the whole chain: the tool inventory, the proposal, the approval, the side effect, and the credential used.

Escalation triggers should be written down before launch. Good candidates are amount above a threshold, a vendor with no history, a match tolerance exceeded, a model-flagged ambiguity, or any request to touch a system outside the workflow's scope. A person stays accountable for every consequential decision. The agent's job is to prepare the decision well.

If an auditor asks about March, the answer is a query against the app's database and logs, plus the version of the matching rule that ran. That is replayable. A transcript of a model's reasoning is not.

A first-90-days sequence we would suggest, offered as a plan and not as a benchmark:

1. Days 1 to 30: pick one bounded workflow with a clear owner. Map its systems, data, and risks. Classify each step as judgment or repeatable.
2. Days 31 to 60: build the repeatable steps as apps with scoped credentials and logging. Run the workflow alongside the existing process.
3. Days 61 to 90: review exceptions and escalation rates with the owner, tighten the controls, and decide what reusable apps the next workflow can start from.

Where vendors are getting this wrong today

Three habits show up in how enterprise AI strategy gets discussed. We have not audited the market, and several of the top-ranking pages for this topic were not fully readable to us, so we are describing patterns in framing and not accusing any named company.

The first habit is measuring strategy by model capability. A better model improves the judgment steps. It does nothing for the question of who may post to the ledger or how you prove what happened.

The second is measuring it by pilot count. A pilot that cannot be handed to another team, or that keeps its memory in a conversation, adds to the pile of things someone must eventually rebuild.

The third is autonomy rhetoric. Describing an agent as an autonomous coworker says how much freedom it has and says nothing about how anyone can inspect, replay, or restrict what it does. For a CISO, autonomy without an audit trail is the problem statement, not the pitch.

Each habit leaves out the execution layer. Our notes on AI agent architecture and AI workflow automation cover the mechanics, and the platform-level view is in our piece on the enterprise AI platform.

One more qualification. A workflow simple enough to live inside a single prompt does not need any of this. The argument gets stronger as workflows get longer, branch more, touch several systems of record, and have to be explained afterward.

What we're doing about this at Major

Our position: enterprise AI becomes dependable when intelligence decides and software executes the repeatable work. Major is the enterprise platform where agents build the software they run on. When an agent works out how to handle a repeatable step, it builds a deterministic app for it. The app carries a managed database, file storage, scoped permissions, and its own logs. From then on the agent runs the app instead of reasoning through the step again. Reason once. Run forever.

In the invoice workflow, that means the match, the ledger write, and the log entry are code. The model handles the freight-charge ambiguity, and a person approves what crosses your threshold. The same app is a control surface for the finance team and an execution layer for the agent, and IT governs both through one set of permissions.

We hold this position with limits. Major does not choose your portfolio, evaluate your models, replace legal review, or settle data governance. It does not remove model reasoning, and it does not remove the people who are accountable for the outcome. We might also be wrong about where the line between judgment and repeatable work falls for your workflow. The classification step exists so you can find out early and move the line.

If you are drafting a strategy now, see how Major turns an agent's repeatable work into a governed app.

Related articles

• LLM Observability: What to Instrument When the Work Is a Black Box
• LLM Evaluation: Methods, Judge Bias, and Shrinking the Surface
• AI Model Governance Can't See What Your Agent Did