Why Frontier AI Can Erode Your Competitive Advantage

I often get asked by people whether frontier AI can perform their work. I think that is the wrong question, or at least an incomplete one. The more interesting question is what happens to the company when it can.

Take a law firm. The law itself is not a competitive advantage. Other firms can read the same legislation and the same case law. The difference lies in the way the firm prepares a case: which facts an experienced lawyer notices, when a partner becomes involved, which argument is pressed, and when a particular risk is worth taking. That is the firm’s judgment in action.

The information may be widely available, but the process that turns information into a decision is particular to the organization. It contains habits, corrections, exceptions, lines of responsibility, and knowledge that may never have been written down. That process is often where the competitive advantage lives, most organizations work like this.

Now place a frontier model at the center of the work. To make the model useful, the company has to show it which information matters, how decisions are made, what an acceptable result looks like, and what should happen when the normal process breaks down. The company is not simply giving the model data; it is reconstructing its operating knowledge around the model.

The immediate benefit may be greater capability. The longer-term risk is that the system of judgment that made the company distinctive becomes dependent on a shared model and an external platform that the company does not control. That is how frontier AI can erode competitive advantage.

Competitive Advantage Lives in the Workflow

We tend to talk about workflows as though they were a row of boxes with arrows between them. But a real workflow is a record of how an organization exercises judgment. It tells us who may decide, which evidence counts, how an exception is handled, when approval is required, and who remains responsible for the outcome.

Return to the law firm. Its advantage does not come from possessing a better copy of the law. It comes from a working system that directs attention. Junior lawyers gather material, experienced lawyers notice what is unusual, partners intervene when the consequences justify it. The firm has learned where to look, what to ignore, and when the ordinary process is no longer enough.

The same is true in a factory dealing with a quality exception, in a bank assessing a borderline transaction, or in a security team deciding whether a vulnerability is genuinely urgent. Two organizations can receive the same input and reach different outcomes because they have different experience, responsibilities, and tolerance for risk.

This is institutional knowledge, but it is not merely a collection of documents. It lives in the relationship between people, information, tools, and authority. A database may contain the previous decisions. It does not, by itself, explain why one decision required an escalation, and another did not. In many cases, it is *tacit* institutional knowledge.

So when we automate the workflow, we have to be rather careful about what is being automated. We may think we are replacing a sequence of routine tasks. In fact, we may be displacing the mechanisms through which the organization understands its own work.

Putting AI Into the Workflow Delegates Authority

There is a theorem from 1970, due to Roger Conant and Ross Ashby, called the Good Regulator Theorem. In simple terms, if I am going to delegate authority, I need a good model of the entity to which I am delegating. I need some understanding of what it will do and, just as importantly, what it will not do.

If the lawyer asks an intern to please make them coffee, they have a reasonable sense of the task being delegated. They do not expect the intern to hack the NSA to obtain the optimal coffee recipe. If the coffee machine has run out, they expect the intern to come back and tell them. The intern also has a model of the lawyer and understands when the problem should be surfaced.

That relationship is more difficult with a general-purpose model whose possible behavior is too broad for the person responsible for the outcome to understand. A surprising route to the objective may look clever in a demonstration. But in an operational environment, it can be a failure to understand the role because capability is not deployability.

There is a second consequence. To make the delegation work, the company has to make its own authority legible to the system. It has to specify the permitted data, the available tools, the approval rules, the exceptions, and the points of escalation. In doing so, it exposes the structure of the workflow in which its judgment resides.

This conflates the control problem with a competitive advantage. The model needs the company’s system of authority in order to act usefully. But if that system is rebuilt around a shared external model, the organization may lose control of the process it is trying to improve.

How a Shared Model Erodes the Advantage

The first risk is dependency. A useful AI system accumulates more than prompts. It acquires integrations, corrections, examples, approval logic, exception handling, and a history of what the organization accepted or rejected. If all of that is organized around a provider’s model and platform, the business may still own its documents while becoming unable to perform or improve the workflow independently of the provider.

Imagine that the law firm gradually rebuilds case preparation around a frontier model. The model searches the evidence, proposes the arguments, identifies which cases deserve senior attention, and records the firm’s corrections. After several years, the firm may have a highly capable system. But if the reasoning process can no longer operate, evolve, or move without the provider’s platform, where does the firm’s capability now reside?

The second risk is commoditization. A frontier model is designed to provide the same broad capability to many customers. If competing firms place the same model at the center of the activity through which they once differentiated, they begin adapting their work to a common source of capability. The model becomes the clever part and the firms become sources of context around it.

This does not mean every customer receives an identical answer. The context will differ. But the center of gravity has moved. Improvements in the underlying capability accrue to the platform, while the organization’s own ability to understand and improve the process can weaken. The company gains access to intelligence but loses practice in producing and governing the judgment that mattered.

Competitive advantage compounds when an organization learns from its decisions and carries that learning into the next decision. If the learning loop is controlled elsewhere, the advantage does not disappear overnight; it erodes gradually as the company becomes a user of someone else’s capability rather than the owner of its own.

The organization needs to decide where the learning should accumulate. If the model becomes the workflow, capability and learning accumulate with the provider. If the organization keeps control of the workflow, its own judgment and operating knowledge compound instead. So, we should build the system around the work and then choose the models that belong inside it.

Build Competitive Advantage Around the Work

Since companies run intelligence through responsibilities, boundaries, reporting structures, and exceptions, their system must know when the ordinary process has stopped being ordinary. Once the frontier model is treated as the center, everything else is described as scaffolding or harnessing. Permissions, monitoring, restricted tools, audit trails, and human review appear to be wrappers around the real intelligence. I think that gets the architecture backwards. The harness is the deployed system; it is what makes the model usable inside an accountable organization.

First, ask who is responsible for the outcome, what decisions they make, which information they need, which tools they are authorized to use, and what should happen when the expected process fails. Then decide where a model is useful. The resulting system may look rather untidy to someone who wants one model to do everything. There may be a frontier model for a difficult piece of analysis alongside smaller models for bounded tasks, a collection of conventional software tools, a database, restricted tools, and points where a person or another part of the organization takes responsibility. That is not a failure of AI. That is what a deployable system looks like.

This leads to an idea I call “the model minimization principle”. It says we should use the smallest model that does the job. I do not mean small as an aesthetic preference. I mean the smallest model whose relevant behavior can be understood, tested, and given a comprehensible role. Add capability when the work requires it, rather than beginning with every possible capability and trying to remove the dangerous parts afterwards.

A system built this way can still use frontier models. They are extraordinary tools for research, design, coding, and other work in which people can inspect the important decisions. But the organization keeps the workflow as the primary system. It controls the permissions, the context, the escalation paths, and the record of how its judgment develops.

That is how AI can strengthen competitive advantage rather than consume it. The model contributes capability, while the company continues to own the process that turns capability into useful action.

Security Makes the Problem Concrete

Cybersecurity is a particularly useful example here because the delegated authority can be dangerous, and the judgment is specific to each company. A vulnerability scanner may identify the same technical issue in two organizations. In one it is an emergency, but in the other it is isolated behind several controls and can wait for the normal release cycle.

Knowing the difference requires more than a severity score. It requires an understanding of the architecture, the exposed systems, the data involved, the compensating controls, the service owner, the accepted risks, and the consequences of making a change. Much of that knowledge belongs to the organization, and it has been accumulated through previous incidents and decisions.

Security teams particularly need AI because their volume of work is increasing and experienced engineers are already overwhelmed. But the answer cannot be to place an opaque general-purpose model in the security function and then ask the engineers to sign off whatever it does. Those engineers remain accountable, and the system must support their judgment and make the repeated parts of the work manageable.

That is the pattern we are building at Trent. Our AI Security Engineer works through the existing tools the organization already uses, gathers the context needed to interpret a finding, and automates repeated work within a defined security role. It does not ask the company to hand its security program to a universal model and hope for the best.

The distinction is in where the customer-specific intelligence lives and who controls it. The agent is specific to the customer, and the context it accumulates about architecture, ownership, policy, accepted risk, and previous decisions remains part of that customer’s operating system. The security team can extend its reach while continuing to own the judgment through which the program improves.

That matters because security is not improved by producing more alerts. It is improved by making better decisions and carrying what was learned into the next decision. AI should help that knowledge compound inside the organization, not relocate the learning loop to a shared platform.

Who Controls the Workflow

So, the central question for enterprise AI is not simply, ‘How intelligent is the model?’ It is, ‘Who controls the workflow?’

If the organization controls it, models can strengthen the knowledge and judgment that make the business distinctive. The company can choose where frontier capability is useful, where a smaller component is safer, and where human authority must remain visible. It can learn from its own decisions and keep improving the system for which it is accountable.

If the frontier model becomes the workflow, the organization may gain a great deal of capability. It may also become dependent on the same source of capability as every competitor, while losing the ability to understand and develop the process that once set it apart.

That is the choice. AI can help a company compound its expertise, or it can quietly turn that expertise into context for somebody else’s model. Competitive advantage depends on keeping the workflow, the judgment, and the authority under the organization’s control.