Agentic Automation in Practice: When Operations Become the Constraint

Agentic automation in production was the focus at Tech Show Frankfurt, where Kyle Forster examined how AI operations at scale are becoming constrained by deployment and reliability demands.

The discussion moved quickly beyond code generation and into the conditions of production, where increased output introduces a different kind of pressure, not on writing software, but on sustaining it.

“This code is better, there’s just so much of it.”

The observation sits within a broader change. As development teams increase their throughput, the effect accumulates downstream, where deployment, monitoring, and incident response begin to absorb a rate of change they were not designed for, and where improvements in quality do not necessarily reduce operational load.

When Agentic Automation Reaches Production

The opening example made that shift concrete. Forster described the Pocket OS incident, where an engineer using Claude deleted a production database and its backups within seconds. The detail that followed was less about the error itself and more about how it occurred: an agent operated with access to credentials and context it was not expected to use, acting as though it were resolving a test issue while affecting production systems.

“The benefits of AI in production operations are so massive that we need to get through.”

The implication lies in how organisations respond. Avoidance is one path, but the discussion remained with the alternative, where the problem is treated as one of design rather than exclusion, requiring systems to be structured around how agents behave when given real authority.

Why AI Operations at Scale Strain Infrastructure

This distinction becomes clearer when moving between environments. Development allows for experimentation, reversibility, and partial failure, where mistakes can be contained and undone without lasting consequences.

“I think that Git is the world’s most advanced undo button.”

Production does not offer the same conditions.

“Production is not built that way.”

The difference is not simply technical, but structural, where the consequences of action extend further, and recovery is neither immediate nor guaranteed, making the transfer of development practices into production environments less straightforward than it first appears.

Designing Boundaries for Agent Behaviour

From that point, the discussion moved into how agent behaviour is shaped. Freeform access, where an agent determines its own sequence of actions across systems like Kubernetes or cloud interfaces, may be acceptable in exploratory contexts, but it introduces variability that becomes difficult to predict once systems are live.

“The design structure is just different.”

What replaces that approach is not restriction in isolation, but definition, where capabilities are narrowed, actions are bounded, and behaviour becomes repeatable under known conditions. The emphasis shifts toward building systems that behave consistently, rather than relying on agents to improvise safely.

Where Value Accumulates

That shift also reframes where long-term value sits. Agent frameworks continue to evolve, often rapidly, while the underlying capabilities they depend on remain more stable.

“Don’t worry too much about individual agents.”

The investment moves toward reusable skills, scripts and operational logic that can be applied across different agents and environments, reducing the need to re-establish safety and control with each new implementation.

The Future of SRE in an Agentic Environment

The effect carries through into how roles change. Site reliability engineering, in particular, was described as moving away from reactive incident handling toward the creation of tools that allow others to interact with systems more directly.

“I fundamentally believe the SRE job is shifting into a tool-building job, and taking incidents is becoming everybody’s job.”

Responsibility becomes more distributed, not by removing expertise, but by embedding it into systems that others can use, allowing operational knowledge to scale alongside development output.

Reviewing at Scale

This redistribution is visible in how work is reviewed. As code generation accelerates, inspecting every line becomes less practical, particularly when volume increases beyond what individuals can reasonably evaluate.

Instead, attention shifts upward, toward specifications, testing and verification, where systems are assessed against expected behaviour rather than implementation detail. The comparison placed code closer to assembly language, still necessary, but no longer the primary point of control.

Across the session, the pressure does not sit within AI capability itself, but within the systems that surround it. As development speeds increase, the constraints become operational, where permissions, boundaries and verification define how safely that capability can be applied, and where the ability to run systems becomes as critical as the ability to build them.