From GitOps to AI agents : Building Automation for Critical Infrastructure

In 1924, Sakichi Toyoda developed a loom capable of stopping automatically when a thread broke. The innovation was not simply that the machine could operate faster or with less supervision, but that it could detect when something was wrong and ask for human intervention only when it was needed. One operator could therefore supervise multiple machines without giving up control over the quality of their output.

This principle became known as Jidoka: automation with a human touch. A century later, it provides a useful way to think about automation in payment infrastructure, where the objective should not simply be to remove manual tasks, but to determine which actions can be safely automated, which decisions require human judgement, and where the system itself should be capable of stopping when something does not look right.

At Estreem, our approach to automation is built around a clear principle: we use technology, including AI, to increase our capabilities while keeping people responsible and in control of critical decisions. This is the approach we are developing within Estreem's Service Reliability Engineering practice. At a recent event hosted with one of our partners, we demonstrated it through two concrete use cases: the first on Estreem One Core, our data center infrastructure, and the second on Estreem One Cloud, where an AI agent prepared an application deployment. The tools were different, but the underlying principle was the same: automation should increase operational capacity without weakening control.

Automation starts with a reliable source of truth

Infrastructure teams have been automating repetitive work for years, but automating individual tasks does not necessarily create an automated operating model. Scripts, runbooks and scheduled jobs can reduce manual effort locally while progressively creating another form of complexity, particularly when the actual state of the platform is distributed between consoles, documentation and the knowledge of individual engineers.

The issue becomes particularly important in payment infrastructure. When systems are expected to operate continuously and support critical banking services, engineers need to know not only what has been deployed, but why it has been deployed, what changed, who approved it and whether the actual state of the infrastructure still corresponds to the intended one. Automation therefore depends first on establishing a reliable and machine-readable source of truth.

At Estreem, this is one of the principles behind our GitOps approach:infrastructure configuration is expressed as code, versioned and managed through Git. A change is proposed through a merge request, automatically validated and tested, reviewed, and only then deployed through a controlled pipeline. The objective is not simply to accelerate infrastructure changes, but to make them reproducible, traceable and reviewable.

The first example of use case showed how this works on Estreem One Core, the physical backbone of our platform. Despite involving datacenters, networks, firewalls, switches and storage, changes to this infrastructure can follow the same software-driven lifecycle. An engineer creates a branch in GitLab, commits the requested change and opens a merge request. This triggers automated validations and tests. Once reviewed and merged, a deployment pipeline executes a Terraform plan and, after the required controls, applies the change. Credentials are retrieved directly from Vault, avoiding the need for engineers to manipulate production secrets during the operation.

What matters here is less the individual tools than the operating model they create.The intended configuration is versioned, changes become explicit and auditable, and differences between the expected and actual state can be identified rather than remaining hidden. Most importantly, the pipeline itself becomes a control mechanism: automation is allowed to execute what has been validated, but it can also refuse a change when predefined conditions are not met.

For a payment processor, this distinction matters. Reliability does not come from assuming that every change will succeed; it comes from designing systems capable of detecting when a change should not proceed.

From infrastructure as code to AI-assisted operations

Once infrastructure is described in a structured and machine-readable way, a second possibility emerges: machines can begin not only to execute predefined actions, but also to reason about proposed changes.

Our second example of use case started with an ordinary operational request: deploying an application component to UAT, the shared test environment used with our customers. Instead of asking an engineer to manually interpret the Jira ticket, inspect the repository, identify the required changes and prepare the deployment, we gave the request to an AI agent operating with Estreem's own SRE skills.

The agent read the ticket and the repository, compared the requested state with the existing configuration and produced a gap analysis. It documented the design decisions it proposed and the reasoning behind them. During that analysis, it also identified that a database required by the deployment did not exist and explicitly raised the issue rather than attempting to infer or create a plausible configuration.

But the most important part of the use case was what happened next: the agent stopped and handed control back to an engineer.

It did not deploy the application directly. Instead, it produced a documented GitLab merge request following the same standards expected from an engineer and submitted it for human review. In approximately five to ten minutes, the request had moved from a Jira ticket to a structured technical proposal, but the decision to approve and execute the change remained with the engineer. Once approved, deployment followed exactly the same pipeline and controls as any other contribution.

The order of these two use cases is important because the AI use case depends on the GitOps foundation established before it. An agent can only reason reliably about an environment if that environment is described in a form it can inspect and compare. If the actual state of a platform exists partly in consoles, partly in outdated documentation and partly in engineers' heads, the agent is forced to operate with incomplete information.

GitOps provides both the context and the control point. The repository gives the agent a structured representation of the intended state, while the merge request creates a mandatory checkpoint before execution. We therefore did not need to invent a separate governance mechanism specifically for AI. The agent operates within the same peer-review model already used for human contributions: it can analyze and propose, but approval remains a human responsibility.

This is a deliberate choice: AI can accelerate engineering work, but it does not have the authority to bypass the controls that protect our infrastructure.

Turning operational knowledge intoreusable engineering assets

Introducing AI agents also changes the way operational knowledge needs to be documented.The value of an agent does not primarily come from the prompt used to interact with it. It comes from the quality of the engineering knowledge and constraints made available to it.

At Estreem, we capture part of this knowledge through what we call skills. A skill describes how a particular type of work should be performed in our environment: how a deployment should be structured, how resources should be named, which evidence needs to accompany a change, which controls must be performed and which actions must never be taken automatically. In that sense, skills can be understood as operational run books expressed in a form that both engineers and agents can use.

This creates an opportunity to make operational knowledge more durable. When a review identifies a weakness in an agent's proposal, the objective is not simply to correct that individual output. The underlying skill can also be improved so that the same knowledge is available the next time a similar situation occurs. Practices that might otherwise remain in an engineer's experience or disappear into a conversation can progressively become versioned, reviewed and reusable engineering assets.

This is also why human oversight remains central to the model. Automation can takeover repetitive execution and AI can accelerate analysis, but neither removes the need for engineering judgement. On the contrary, moving engineers away from routine execution makes the quality of their decisions even more important. Reviewing whether an architecture is resilient, whether a dependency introduces an unacceptable risk or whether a deployment should proceed requires context and accountability that cannot simply be delegated to a tool.

Keeping humans in control is not a limitation of our automation strategy. It is one fits design principles. The objective is not autonomous infrastructure in which humans progressively disappear from operations. It is an operating model in which machines perform more of the deterministic work while engineers retain control over the decisions that carry consequences.

Automating for reliability, notsimply for speed

This distinction is particularly important for Estreem because automation is being introduced in the context of critical payment infrastructure. The objective is not simply to increase deployment velocity or reduce the time required to complete operational tickets. It is to build an operating model capable of supporting a platform that must remain available, controlled and understandable as its scale and complexity increase.

A conventional production organization can spend a significant share of its capacity on repetitive operations, incident investigation and manual remediation. Every part of that work that can be safely standardized and automated creates more capacity for engineering questions that cannot be reduced to a procedure: Is this design sufficiently resilient? Is this dependency acceptable? How will the platform behave if a region becomes unavailable in the middle of the night? Does this change introduce a risk that should prevent us from deploying it?

This brings us back to Jidoka. The most useful automation is not necessarily the automation that removes the greatest number of human actions. It is the automation that knows what it can execute, what it must verify and when it needs to stop.

For Estreem's SRE practice, GitOps and AI agents are therefore part of the same engineering philosophy. GitOps establishes a controlled, versioned and machine-readable foundation. AI agents can use that foundation to accelerate analysis and prepare changes. Automated pipelines enforce the controls required before execution. And engineers remain responsible for the decisions that require judgement.

Our ambition is to make automation more powerful without making our infrastructure less accountable.By keeping human responsibility and control at the centre of our engineering practices, we can use AI to extend our capabilities while maintaining the standards of reliability, resilience and safety required to operate critical payment infrastructure.