Analyze.
Engineer.
Deploy.

There is a pattern running through virtually every AI implementation I encounter. A team identifies a problem. Someone proposes AI as the solution. The conversation immediately jumps to which LLM to use, which API to call, and how to write the prompt. The result is a system that is expensive to run, unpredictable in its outputs, and entirely dependent on cloud infrastructure for tasks that have no business requiring it.

The Core Mistake

Large language models are genuinely remarkable tools — in the domains where they belong. Reasoning under ambiguity, synthesising unstructured information, generating natural language, handling tasks where the input space is too vast and variable for anything else. These are real and powerful capabilities.

The problem is that organisations are using LLMs as the default answer to every question. Classification tasks that would run in milliseconds on a decision tree get routed through a cloud inference endpoint. Routing logic that could be three lines of deterministic code becomes a prompt. Structured data extraction that a regex could handle in microseconds goes to GPT-4.

A conservative estimate: over 90% of LLM integrations built in the last two years should have been implemented with deterministic branching logic, classical ML models, or both — tools capable of running on-device, at the edge, with predictable outputs and zero per-token cost.

What The Right Tool Looks Like

Deterministic branching handles anything where the logic is knowable in advance. If the input matches condition A, do X. If it matches condition B, do Y. This is not a limitation — it is a feature. Predictable, auditable, fast, cheap.

Classical ML — logistic regression, gradient boosted trees, small neural networks — handles pattern recognition, classification, and prediction at a fraction of the cost and latency of LLM inference, and with far greater consistency. These models run on edge devices. They do not require an API call. They do not hallucinate.

LLMs belong at the top of the stack, in the narrow band of tasks where their generative and reasoning capabilities are genuinely irreplaceable. Treating them as the universal substrate for everything is like using a plasma cutter to open an envelope.

Somewhere in the gap between "we've deployed this new system" and "our team actually uses it" lives one of the most persistent and expensive problems in business. The technology works. The process makes sense on paper. And yet adoption is sluggish, compliance is patchy, and six months later the old workflow is still running in the background.

This is almost never a training problem. It is a design problem.

UX Is Not Optional For Internal Tools

There is a pervasive assumption in enterprise software that internal tools are exempt from the standards applied to consumer-facing products. The people using them are employees, the logic goes — they have to use it regardless of whether it's pleasant. This assumption is wrong, and it is costing organisations dearly in productivity, morale, and adoption rates.

Look at Meta's Business Manager ecosystem. Page Manager, Ad Manager, Commerce Manager, Business Suite — a constellation of overlapping, partially redundant interfaces that seem to reorganise themselves every few weeks. Experienced marketers waste hours navigating it. Enterprise teams build internal documentation just to find features. The tool has become the work.

Microsoft's admin and management panels follow a similar pattern: deeply nested menus, settings that exist in three different places with slightly different scopes, legacy interfaces sitting alongside newer ones with inconsistent design language. Working with it daily is an act of institutional memory, not intuitive operation.

Delight Is The Mechanism

People adopt technology when it solves a genuine pain point better than whatever they were doing before. They adopt it enthusiastically when it makes them feel capable and effective. They resist it when it adds friction, creates new confusion, or simply becomes another thing to manage.

Delight the user. This means removing steps they currently have to take. It means surfaces that feel considered and intentional. It means feedback that confirms action and reduces uncertainty. It means respecting the user's time at every interaction point.

When the technology becomes the work — when learning the tool is the primary cognitive task rather than the thing the tool is supposed to enable — the case for adoption collapses. Before deploying any new system internally, the honest question to ask is whether the people who will use it will experience it as a genuine improvement to their day. If the answer is uncertain, the design work is not finished.

When I say agentic agents, I am not talking about a chatbot with access to a couple of tools. I am talking about systems that operate with meaningful autonomy — AI that plans, takes action sequences, makes decisions, and executes tasks across extended horizons with minimal human intervention. Agents moving closer into the domain of autonomous AI employees.

At that level of capability, the failure modes are no longer hypothetical. They are operational. Anthropic's published research on agentic misalignment documents this clearly: agents pursue objectives in ways their designers did not intend, take actions outside their defined scope, and optimise for proxy measures that diverge from the actual goal. These are not edge cases. They are predictable outcomes of deploying powerful systems without adequate structural controls.

The Law of Instrumental Integrity

My research on purpose-bearing system failure — the Law of Instrumental Integrity — identifies the root cause: systems fail when the integrity of their goal structure erodes. The agent does not suddenly become misaligned. It was never designed with alignment as a hard architectural constraint. The failure is structural before it is behavioural.

The practical implication is direct: if your business does not have its mission, priorities, goals, expectations, SOPs, and documentation clearly defined and consistently maintained, deploying autonomous agents will amplify the existing disorder. Agents do not resolve organisational confusion. They execute at scale within it. The mess you have gets bigger, faster.

What Agents Actually Require

Every agent in a production system requires a clear and bounded scope — a defined set of capabilities, a defined set of contexts, and explicit limits on what it can and cannot initiate. Scope drift is a design failure, not a model failure.

Agents require current, maintained directives that reflect the actual state of the business. An agent operating on a six-month-old objective in a business that has pivoted is a liability. Directive management is operational infrastructure, and it needs to be treated as such.

The LLM powering an agent should be tightly bounded within a controlled orchestration framework with a clear identity, a defined purpose, and explicit alignment to the business's mission and values. The model's generative capability is a tool within that framework — not the framework itself.

Use Deterministic Systems First

Everything that can be controlled by deterministic hard-coded logic, predictable classical ML, or condition-driven decision trees should use those methods. Agentic processes carry inherent unpredictability. Reserving them for the tasks that genuinely require generative reasoning — and handling everything else with reliable, auditable, deterministic systems — is the architectural principle that keeps production agent deployments stable.