Agentic Automation in Operational Systems Design

Automation is often treated as a technical intervention in a fixed business process. Someone identifies work currently done by humans, builds an agent to perform it, and inserts the agent into the existing workflow to do the things people were doing.

This approach misses a larger opportunity to improve the business. The business process, the automation, and the interfaces between humans and machines form a single operational system, in which any component can be redesigned to accommodate enabling changes in the others.

This may involve changing the order of operations, dividing responsibilities differently, or altering the information each participant must supply. The interfaces between humans and agents are particularly important: they determine what information agents receive, what actions they can take, and what outputs they must produce.

An Example: Automated Bug Fixing

Consider a software development team's bug-fixing process.

Bug reports often vary considerably in quality. Some cont(thunder rumbling)ain precise reproduction steps; others provide little more than a description of unexpected behaviour. An agent asked to resolve these reports must first reconstruct missing context before it can even begin investigating.

We could instead redesign the reporting process to enforce a structured issue format, requiring expected behaviour, actual behaviour, reproduction conditions, and relevant environment details.

Instead of human-led triage, bug tickets have their structure automatically verified, and candidate issues are passed forward to an an agent attempting to reproduce the bug in an instrumented environment, collecting execution traces, logs, and application state.

These outputs then feed into static and dynamic analyses in subsequent steps to enable a classifier step to estimate the risk associated with the bug's scope, relevant dependencies, and potential blast radius.

Issues assessed as low-risk could be routed to an automated fixing agent, which prepares a patch and submits a pull request.

The pull request could trigger automated tests, static analysis, agentic code review, and perhaps also run in an instrumented environment to gather comparative information about the blast radius.

Changes satisfying predefined risk and verification criteria could be merged automatically. Changes determined too risky would be escalated for human judgment.

Each stage produces outputs in a form that enables subsequent stages to be automated. Structured reports enable reproduction; instrumentation enables analysis; analysis supports risk classification; and risk classification determines which actions can safely be delegated.

Complementary Strategies

There are two distinct ways to make a process more amenable to automation:

Reduce the ambiguity of the work. Structured inputs, explicit behavioural requirements, controlled scope, and well-defined interfaces reduce ambiguity. They narrow the range of decisions an agent must make and increase the likelihood of correct execution.

Reduce the consequences of failure. Constraint enforcement, independent verification, risk thresholds, and rollback mechanisms limit the damage an incorrect action can cause.

These strategies complement one another. Reducing task ambiguity increases reliability; limiting the consequences of failure makes residual uncertainty more tolerable.

The human elements of the work are moved towards the definition of initial and operating conditions. Human review and input can be introduced between any two steps in the process, but at the cost of degradation of automaticity.

Operational Systems Engineering

This suggests a different approach to automation.

Rather than beginning with a list of existing tasks and asking which an agent could replace, begin with the desired business outcome.

Consider whether the surrounding process can be changed to make the task tractable. Where failure remains costly, retain human oversight.

Decompose the process into actions, decisions, and information transfers. Identify what each stage needs to accomplish, what evidence it requires, and what outputs subsequent stages depend upon.

Then redesign the process and its interfaces around the complementary capabilities of humans, conventional software, and AI agents. Think about how work could be restructured such that deterministic software can handle well defined bulk cases, agents can handle low risk, well bounded ambiguity, and humans remain available for escalation and genuinely complex cases.

The Economics

In a business, things ultimately boil down to efficiency of resource usage: where should we invest time, money, computation, and human cognition?

An organisation might minimise human involvement and allow agents to explore solutions through repeated iteration. Alternatively, it might invest more human thought upfront in architecture, planning, and constraints, reducing the exploratory work agents must perform later.

Neither extreme is necessarily optimal.

High-risk decisions may justify extensive human attention before implementation, while routine, well-defined tasks may be more efficiently handled by inexpensive agents iterating within established guardrails.

The operational systems challenge is to identify where human judgment creates the greatest leverage, where deterministic systems offer the greatest value, and where agents can be used with acceptable error margin and cost.

Next
Next

LLMs as Probabilistic Decision Nodes