Are agent workflows bringing back problems DevOps already solved?

Keep the same release gates you’d use for any other change. An agent can draft a fix or suggest an infrastructure update, but its output should go through review, tests, and the usual deployment process before it can affect production. I wouldn’t give an agent broad write access just because it can explain what it plans to do.

Scope its tools and credentials narrowly, log actions, and make rollback a normal part of the workflow. Treat generated changes as untrusted changes, not as approved changes.

Reproducibility is trickier than it is with an ordinary build. The output can depend on the model version, prompt, retrieved material, memory, tool results, and settings, and not all of those are equally controllable. Record the inputs you can, including which model and prompt were used, what context was supplied, and which tools were called.

Then test representative tasks and failure cases before rollout. Evaluation scores can help catch regressions, but a second model judging an answer is still an imperfect check, not proof that the behavior is safe. Keep humans in the loop for consequential actions.

Agents aren’t magic employees. They’re programs with flexible behavior, and the useful question is what they’re allowed to do. I’d use them to interpret requests and choose among well-defined tools, while keeping the tools themselves predictable and constrained.

For example, an agent might identify a likely issue and prepare a proposed change. A deterministic check can validate it, and a controlled pipeline can deploy it. That gives you some flexibility without letting a fuzzy decision quietly replace the controls around production.