Most organisations using AI today use it as an assistant. A developer asks a model to draft a function. An analyst asks for a summary of a report. The AI speeds up the task, the person stays in the loop for every step, and the value gets measured in minutes saved.

That helps. It is also the smallest part of what this technology can do.

The distinction that matters in my work is between using AI to help someone perform a task and designing a process where AI performs part of the operation itself.

What changes when the AI is the operator

An assistant waits to be asked. An agent observes.

The systems I spend most of my time on are agentic. They watch information across multiple sources (monitoring, logs, tickets, security alerts, data pipelines), reason over what they see, retain context about the environment they operate in, and identify the situations that need a human. In between, they do the work: triaging the routine, correlating signals no single team watches, drafting the first version of an incident summary, running the repetitive parts of a security investigation, keeping a living model of what counts as normal.

The difference shows up in the operating model, not the demo. An assistant makes a person faster. An agent changes what the team is for. The repetitive middle of operations (collection, correlation, first-pass analysis, status updates) stops being human work, and people concentrate on judgement: what matters, what we risk, what we decide.

Where this applies first

The best early ground for autonomous operations shares three conditions: the work is repetitive, the inputs are observable, and the cost of a wrong low-stakes action is recoverable. That describes more of technology operations than most people expect.

• Monitoring and incident triage: an agent that watches every alert stream, correlates related events, closes the noise, and escalates only what matters, with the evidence attached.
• Security investigation: machines run the repetitive collection and initial analysis; experienced people concentrate on judgement and risk.
• Software engineering: coding agents that take well-specified work end to end, with review gates. A unit of delivery, not autocomplete.
• Data and reporting: conversational access to governed datasets, so the fifty routine questions a week stop becoming fifty centrally maintained reports.

The questions that decide whether it works

The failure mode to design for is an agent that is confidently, plausibly wrong while nobody is looking. Useless systems get switched off. Plausibly wrong ones keep running. So the design questions are governance questions:

• What decisions is the AI making?
• What information can it access, and should it?
• What happens when it is wrong? How likely is that, and what is the impact?
• Which actions require a human in the loop, by rule rather than by habit?
• How do we measure whether the system is useful rather than merely active?
• What happens when the underlying AI provider is unavailable?

If a provider outage now takes out part of your operations, provider resilience and model portability have become architecture concerns. They sit in the same class as cloud regions and database failover.

Governance that enables experimentation

My approach is to encourage experimentation while establishing proportionate governance around risk, security, cost and resilience. If a review board takes six weeks to approve a prototype, governance has turned into prevention. A one-page risk assessment, clear data boundaries, an escalation rule and a cost ceiling per agent are governance an engineering team can actually work inside.

Cost deserves the same discipline. AI consumption is easy to ramp up and easy to forget about. Agents that run continuously need unit economics (cost per investigation, per deployment, per answered question), or the invoice arrives before the insight does.

The operating model is the product

By now every technology team uses AI in some form, so that question has answered itself. The question to ask is whether it lets the organisation operate in a better way: detecting problems earlier, investigating faster, releasing more safely, answering more of its own questions.

If AI exists in the organisation only as assistants making the old process marginally faster, then nothing has changed yet. The shift from assistant to operating model is where the leverage is. It is also where the discipline is: observability, boundaries, escalation, measurement.

The organisations that will get this right are the ones treating AI as part of operations, designed and governed and measured, rather than as a bolt-on to a process that never changed.

Satish Chandran is a senior technology leader specialising in engineering, cloud infrastructure, DevOps, cybersecurity, data and Artificial Intelligence.