Deterministic automation vs AI agents: reasoning can be probabilistic, execution can't

AWS moved its flagship agent product into maintenance mode on 30 July. Amazon Bedrock Agents, launched November 2023, is now Bedrock Agents Classic: closed to new customers, model catalog frozen as of that date, no new features planned. Existing users are fine and there’s no end-of-life date. The part worth reading twice is what AWS recommends instead. Not a better agent — a harness. And that word is the clearest public answer anyone has given on deterministic automation vs AI agents: the model reasons, and something deterministic does the work.

TL;DR: In ten weeks, three separate vendors converged on the same unit of deployment — not the agent, the harness around it. Gartner’s first Market Guide for Agentic NetOps Software (19 May 2026) names the pattern: probabilistic reasoning paired with deterministic implementation and policy-compliant guardrails. Microsoft’s security system MDASH is described in its own words as a harness. AWS’s replacement for Bedrock Agents is the AgentCore managed harness. The engineering conclusion underneath all three is unglamorous and correct: reasoning can be probabilistic, execution cannot. Most of what people call “agent reliability” is a question about which layer a given step belongs in — and most steps belong in the deterministic one.

Three vendors, one word, ten weeks

Gartner published its first Market Guide for Agentic NetOps Software on 19 May 2026 (Leibovitz, Lerner, Forest, Zimmerman), defining a market it calls disruptive and early-stage. The requirement it sets out is not model quality. It’s the machinery around the model: validation before an action runs, verification after, rollback authority, and autonomy you can dial from human-approved to fully autonomous. Vendors reading the guide back — Itential, named a Representative Vendor in five 2026 Gartner Market Guides on 28 July — summarize the requirement as an agentic harness: probabilistic reasoning combined with deterministic implementation and guardrails that comply with enterprise policy. The same guide projects that by 2030 AI agents will be the most common approach for executing network runtime activities, up from under 1% in early 2026.

Microsoft got there independently. When it announced MAI-Cyber-1-Flash and Project Perception on 27 July 2026, the model was the headline and the architecture was the story. Microsoft describes MDASH in its own materials as its multi-agent vulnerability identification and remediation harness — a system orchestrating more than 100 specialized agents across several models, in place since May. MAI-Cyber-1-Flash was built to handle up to 90% of tasks cheaply, with GPT-5.4 reserved for the hardest 10%, for a claimed 50% cost saving against Microsoft’s previous MDASH configuration and 95.95% on the CyberGym benchmark. Read that structure carefully. The model is a component inside the harness, swapped for cost. The harness is the durable thing.

Then AWS, three days later, with the least ambiguous version of all: the migration path from Bedrock Agents Classic is a config-based harness where you declare the model, the tools and the instructions, and AWS handles compute, environment, memory, identity, observability and gateway-enforced guardrails. There’s a CLI verb for it — agentcore add harness. The model became a flag you pass in, overridable per invocation without redeploying.

Three companies with no reason to coordinate picked the same noun. When that happens it usually means the category found its actual shape.

The distinction that does the work

A language model is probabilistic by construction. It weighs evidence and selects a likely path, which is precisely why it’s good at the things rules are bad at. It’s also why the same question at 2pm and 2am can return two different answers. In a diagnosis that’s a feature. In a change window, a payment run, or a record update, it’s a defect with a delay on it.

Production wants the same input to produce the same output, every time. So the design question isn’t whether to use AI. It’s which layer each step of your workflow belongs in.

Layer	Probabilistic or deterministic	What lives here	What it costs you to get wrong
Reading unstructured input	Probabilistic	Parsing an email, a PDF, a photo of a nameplate, a free-text note	A misread, caught by validation — cheap if the next layer checks
Classifying an ambiguous case	Probabilistic	Which exception bucket, which priority, which of five known paths	A wrong route; recoverable if a human sees the queue
Choosing a plan	Probabilistic	Sequencing known tools to reach a stated goal	Wasted calls and latency; contained if the tool list is scoped
Calling a system	Deterministic	The API call, the arguments, the scoped credential, the idempotency key	Duplicate payments, wrong record, no audit trail
Applying a rule	Deterministic	Thresholds, approvals, eligibility, state transitions	Inconsistent decisions nobody can reproduce or defend
Validating before and after	Deterministic	Preconditions, postconditions, reconciliation	Silent corruption — the worst outcome, because nothing fails loudly
Undoing	Deterministic	Rollback, compensating transaction, kill switch	An incident you can’t stop, only watch

Nothing in the right-hand column is new engineering. Idempotency keys, preconditions, scoped credentials, compensating transactions and reconciliation jobs predate transformers by decades. That’s the point that keeps getting missed: the hard part of shipping an agent is a body of ordinary systems work that has nothing to do with AI, and teams that already do it well ship agents easily.

Constraint is the feature, not the compromise

The most honest document in this whole story is AWS’s own capability-comparison table, because it lists what the harness won’t do. Stage-specific prompt overrides from Bedrock Agents Classic are not directly replicated. Routing-mode multi-agent collaboration is “not straightforward today.” A custom orchestrator isn’t available through the harness at all — you drop to code-defined agents on the runtime for that. And AWS’s own recommendation is blunt: use the harness unless you have a specific reason to own the loop yourself.

A less expressive default, recommended over the more expressive one. That is a vendor saying out loud that most teams should not be writing their own agent loop, for the same reason most teams should not be writing their own retry logic or their own auth. The interesting design work moved from “what can the agent do” to “what is it structurally unable to do.”

This is the reversal worth internalizing if you’re deciding what to build this quarter. For two years the question was how much autonomy you could grant. The shipping systems are answering a different one: how little you can grant and still get the outcome. Scoped tools instead of a general integration. Return-of-control instead of a fully autonomous run. Gateway-enforced policy instead of a well-worded system prompt. The permissions question is a contract question, and it’s usually the one nobody wrote.

The harness is a configuration, and configuration needs an owner

Here’s where it stops being an architecture story.

A harness enforces boundaries. It does not invent them. Somebody has to say which actions are approved, what the approval threshold is, what a valid result looks like, and when to roll back — and those are business decisions with a name attached, not settings with a sensible default.

Deloitte’s State of AI in the Enterprise 2026, published 24 April 2026 from a survey of 3,235 IT and business leaders across 24 countries, found that only 21% of organizations have a mature governance model for agentic AI, while 74% expect to be using agents at least moderately by 2027. The report’s own framing is that agents are scaling faster than their guardrails. What it lists as missing is worth quoting almost in full, because it is a description of a harness: clear boundaries defining which decisions agents can make independently versus which require human approval, real-time monitoring that tracks agent behavior and flags anomalies, and audit trails.

Every one of those is a deterministic control. None of them is a model problem. And each one requires somebody to have written down how the work is actually done — which is the step most organizations discover they skipped.

Regulators are converging on the same layer from the other side. China’s Implementation Opinions on Intelligent Agent Governance, issued jointly by the Cyberspace Administration, the National Development and Reform Commission and the Ministry of Industry and Information Technology, came into force on 15 July 2026. It requires mandatory filing and compliance testing for agents deployed in sensitive sectors — healthcare, transportation, media, public safety — and makes product recall provisions available for higher-risk applications. Recall is a manufacturing word. To recall something you need a version you can identify, a behavior you can reproduce, and a mechanism to withdraw it. Those are properties of the harness. A model weight has none of them. Compliance deadlines keep landing on the legible layer rather than the clever one.

What this changes about the build

Start by counting how much of the target workflow is already known. In most operational processes I’ve taken apart, the overwhelming majority of steps have a correct answer that someone can state in a sentence — this status means that action, this amount over that threshold needs this approval, these two fields have to agree. Those steps do not want a model. A model there buys you latency, token cost, variance, and a decision you can’t reproduce for an auditor, in exchange for nothing.

What’s left is the genuinely ambiguous remainder: reading the unstructured input, classifying the odd case, drafting the response, deciding which of the known paths an exception belongs on. That remainder is real, it’s often where the labor actually goes, and it’s exactly what a model is good at. It’s also usually smaller than the pilot deck assumed.

So the build order inverts. Wire the deterministic execution first — the tools, the scoped credentials, the validation on both sides, the rollback, the trace. Get that running under a plain rules engine or a script, with no model in the loop at all, and see how far it gets you. Then put the model where the rules ran out. You’ll know exactly where that boundary is, because the deterministic version will have failed at it visibly. Most of that work is integration work, and it’s the part that survives a model swap — which, as Microsoft just demonstrated by routing 90% of its tasks to a cheaper model inside the same harness, is a thing that will happen to you repeatedly.

The version of this that goes wrong is the one that starts from the model and tries to add controls afterward, usually through a builder interface where nobody ends up owning the running system. By then the autonomy is load-bearing and taking it back reads as a downgrade.

Nothing about that sequence is exciting, and it’s roughly what the work looks like when someone does it properly: mapping the process, naming the owner, writing the contract between systems, and putting the model in the one place it earns its cost.

AWS didn’t retire Bedrock Agents because agents stopped working. It retired a product whose unit was the agent and replaced it with one whose unit is the harness. Same models underneath. Different thing being sold.