What automation is for
Automation is often framed as a way to reduce headcount or eliminate toil. Both are real effects, but neither captures what automation is actually good at. The strongest case for automating a process is that the process is more reliable, more consistent and more auditable when a machine performs it than when a person does.
Repetitive operational work has a specific failure profile. It is performed correctly most of the time, incorrectly under pressure, and inconsistently across teams. Automation does not eliminate error, but it relocates it — from the execution of a process to its definition, where it is at least visible and reviewable.
Infrastructure automation
Infrastructure automation has matured faster than most operational disciplines. Declarative configuration, immutable images and pipeline-driven deployment are now standard in organisations of almost any size. The result is that the infrastructure layer is often the best-instrumented and most reproducible part of the stack.
The remaining problems are usually at the boundaries: state that lives outside the declarative model, changes that bypass the pipeline, secrets managed informally, and the long tail of resources that predate current practice.
Orchestration and its edges
Orchestration tools coordinate work across systems. Their value is proportional to the clarity of the interfaces between those systems. When interfaces are well-defined, orchestration is straightforward. When they are not, orchestration becomes a place where ambiguity accumulates.
A common failure mode is orchestration that works well for the happy path and poorly for everything else. Retries, partial failures, idempotency and compensation logic are where the real design work happens. They are also where it is most often skipped.
Measurement and feedback
An automated process without measurement is a bet. The useful questions are specific:
- How often does the automated path succeed on the first attempt?
- When it fails, how is the failure detected?
- How long does recovery take, and who performs it?
- What proportion of executions require manual intervention?
- Has the intervention rate improved, degraded or stayed flat over time?
These are not sophisticated metrics. Their value is in the discipline of collecting them and acting on what they show.
The toil question
Toil has become a useful term for work that is manual, repetitive, automatable and does not produce lasting value. Reducing it is a reasonable goal, but it is worth being precise about what replaces it. Automation that removes the execution of a task but adds a new category of task — maintaining the automation, debugging it, handling its edge cases — has not reduced toil so much as renamed it.
The better framing is not how much work is eliminated, but how much of the remaining work is the kind that compounds. Diagnostic work, design work and improvement work compound. Routine intervention does not.
AI-assisted operations
There is a meaningful distinction between automation that executes a known procedure and automation that participates in deciding what to do. The first is mature and widely deployed. The second is neither.
Where AI is genuinely useful in operational automation today, it tends to be in classification, summarisation and retrieval — tasks where the cost of being wrong is bounded and the human remains the decision-maker. Where it is least useful is in actions with irreversible consequences, executed against systems whose state is not fully known.
That boundary is not permanent. It is, however, the honest one at present.
This page describes a field of exploration. ConvexOps does not currently offer automation software, tooling or services.