DevOps Is Moving Toward LoopOps

I am starting a new project: LoopOps.

The short version is this: DevOps made software delivery continuous. LoopOps should make software improvement continuous.

That distinction matters more now because the shape of software is changing. A production system is no longer only code, infrastructure, deployments, and alerts. It is also prompts, tools, evals, retrieval paths, agent policies, human approvals, product feedback, and the messy path from “something felt wrong” to “the system is actually better.”

We have good machinery for shipping. We have good machinery for observing. We do not yet have good machinery for closing the improvement loop.

That is the gap I want LoopOps to live in.

Why I Am Thinking About This

Most engineering teams already run loops informally.

A customer reports a problem. A dashboard looks suspicious. An agent takes the wrong path. A support note mentions the same failure three times. Someone opens an issue. Someone diagnoses. Someone patches. Maybe an eval is added. Maybe a PR ships. Maybe, if the team is disciplined and has enough time, someone checks the next production window to see whether the fix worked.

That workflow is real, but it is usually not represented as a durable object in the system.

It is scattered across Slack, GitHub, dashboards, traces, docs, memory, and a few people who happened to be paying attention that week.

DevOps helped us stop treating deployment and operations as separate worlds. It gave teams a language for continuous delivery, automation, ownership, and operational feedback.

LoopOps is the same kind of shift applied to improvement itself.

The question is not only:

• Did we deploy?
• Is the system up?
• Did an alert fire?

The question becomes:

• What product pain did we observe?
• What evidence supports it?
• What change did we make?
• Who approved the risky boundary?
• Did the next measurement window prove that the system improved?

That last question is the one I care about most.

The Loop Should Be a Product Surface

Observability made production behavior visible. That was necessary. I do not want less telemetry, fewer traces, or weaker debugging tools.

But a dashboard is not the natural endpoint for every signal anymore.

If a coding agent can read evidence, inspect a repo, draft an issue, propose an eval, prepare a patch plan, and check a verification window, then the product should not force a human to be the parser for every raw signal.

The human should keep judgment, approval, and accountability.

The system should handle more of the repetitive investigation and packaging work.

That is the product idea behind LoopOps: turn product signals into improvement runs that are structured enough for agents to operate and clear enough for humans to review.

In practice, a loop needs a few basic parts:

• a signal that starts it,
• a bounded evidence window,
• a diagnosis or hypothesis,
• an action plan,
• an approval boundary,
• a verification step that can say fixed, regressed, or still unknown.

Once those pieces are explicit, improvement stops being a loose handoff and starts becoming something the product can track.

Why This Is Especially Important For AI Products

AI systems have failure modes that do not look like traditional uptime problems.

An agent can call a valid tool for the wrong reason. It can satisfy a schema while disappointing the user. It can use stale context, take an expensive path, miss a policy boundary, or regress because a prompt changed.

Those failures can be invisible if the only lens is infrastructure health.

The product might be up. The API might be fast. The database might be healthy. The user still might not have been helped.

That is why the improvement loop needs product evidence, not just system evidence. It should connect the behavior users experienced with the traces, tool calls, feedback, issues, evals, and code changes that explain what happened next.

This is also why I think the future of DevOps starts to look like LoopOps.

As more work is done by agents, the operational question shifts from “can we run the system?” to “can the system and its agents keep getting better under human control?”

What I Published On LoopOps

I wrote the more product-specific version of this idea on the LoopOps blog: Loops are the primitive.

That post goes deeper into the product claim: the loop itself should be a first-class primitive, not just a dashboard session, a ticket, or a convention held together by team discipline.

This post is the personal version.

LoopOps is me trying to make a long-running instinct concrete: telemetry should not end at “look at this.” It should help a team decide what to improve, hand the right packet of evidence to the right actor, keep humans in control of the write side, and prove whether the next window got better.

That is the category I want to explore.

Not observability as another place to stare at production.

Not automation that quietly changes things without review.

Not a generic agent platform trying to own every workflow.

LoopOps should be improvement infrastructure: a way to name, run, inspect, and verify the loops that serious teams already perform by hand.

Where I Want To Take It

The first useful version should be small.

Connect or send product telemetry. Generate a bounded improvement run. Produce a clear brief. Let a human approve what crosses an external boundary. Let an agent do the boring investigation work. Verify the next window honestly.

If that works, the system earns the right to become more ambitious.

Loop history can become a memory of what failed and what actually held. Evals can attach to real production pain instead of imagined edge cases. GitHub issues and PRs can carry the evidence that created them. Dashboards can become views over improvement state instead of the place where every investigation starts from scratch.

That is the vision:

DevOps made delivery continuous.

LoopOps makes improvement continuous.

And the loop only counts when it closes.