Loop Engineering: Building Software Platforms That Improve Themselves
Most engineering organisations run their software the way they did a decade ago: a scatter of disconnected tools, a human wired into every decision, and a platform that quietly decays the moment nobody is watching it. Planning lives in one tool, code in another, CI somewhere else, deployment somewhere else again, dashboards in a fourth place, cost in a spreadsheet, security in an inbox, and the AI experiments in a browser tab nobody governs. Every one of those seams is a place where work stalls, context is lost, and access has to be granted by hand.
At Wohlig we’ve built a different model: a single governed platform that takes an idea all the way from a tracked task to a running service in production, to a dashboard that proves it works, to a suggestion for what to improve next. The part that makes it feel alive is the loop — not a cron job that does the same thing forever, but an intelligent, continuously running cycle that observes real usage, telemetry, cost and security signals, decides what matters, acts, and then measures whether the action actually moved the number.
We call the discipline of designing and operating those cycles Loop Engineering. It’s only now becoming genuinely practical, because frontier models such as Fable 5 can reason over many steps, use real tools, and run unattended without falling apart.
The problem: a human in every loop
Ask an engineering leader where their software lifecycle actually lives and you’ll get a list, not a place. And all of it depends on a person choosing to look. Someone has to remember to check the cost report, notice the latency creeping up, spot the feature nobody uses, catch the vulnerability that keeps recurring, or find the idle environment burning money over the weekend. When that person is busy, on leave, or simply overwhelmed, the platform stops improving. It doesn’t fail loudly. It just slowly gets worse.
The traditional answer is automation, and automation helps — but classic automation is static. A script does exactly what it was written to do, forever, whether or not that’s still the right thing. It can’t read a dashboard and conclude the real problem is somewhere else. It can’t weigh impact against effort, or write the follow-up task. The judgement stays with the human, and so the bottleneck stays with the human.
That’s the gap we set out to close.
One governed surface for the whole lifecycle
The foundation is an internal developer platform: a single, opinionated surface where a team can plan, build, test, release, operate and improve everything, spanning DevOps, applications, business intelligence and AI. Three ideas hold it together.
One paved road. There’s a sensible, well-lit default path for the common case, with escape hatches for the exceptions. A new service can go from a fresh idea to production without a single manual infrastructure ticket. Developers don’t assemble their own pipeline every time — they follow the road, and the road is fast.
One identity. Every tool authenticates through the same corporate identity, and access is decided by group membership rather than a separate user list in each tool. Grant someone the right group and they can do the right things everywhere; remove them, and access is revoked everywhere at once. No per-tool cleanup, no forgotten account left behind.
Desired state is declared, not clicked. The intended configuration of the platform lives as reviewed, version-controlled declarations rather than ad-hoc changes made by hand in a console. Changes are proposed, reviewed like code, and reconciled automatically. The whole platform stays auditable and reversible: you can always see who changed what, why, and roll back to a known-good state.
The lifecycle, stage by stage
Plan. An idea becomes a tracked task on a board, and larger bets land on a roadmap. Nothing gets built that isn’t visible, owned and prioritised.
Build. A new project is scaffolded from a golden template that already has the pipeline, packaging and deployment wiring in place. Secrets never live in code; they’re pulled at runtime from a managed secret store. Conventions are baked in, so every project looks and behaves the same way.
Test. Quality is enforced by the pipeline, not by hope. Unit, integration and end-to-end tests, plus load testing and security scanning, run as gates. A change that fails a gate cannot merge or promote. There’s no “we’ll test it later.”
Release. Promotion from development to staging to production is one-way and driven entirely by the declared desired state. Each promotion has explicit gates: green tests, a load test within the performance budget, a clean soak period, and an approval. Production rollouts are progressive, using canary or blue-green strategies that abort automatically if the service breaches its reliability targets.
Operate. Every workload becomes observable without a single line of instrumentation code. A modern, low-level agent captures traces, metrics and logs automatically and streams them into a single observability layer, so there’s one pane of glass for the health of every service. Security posture, threat detection and vulnerability status sit in a parallel set of views. On-call has runbooks, not guesswork.
Improve. This is where the platform stops being a static toolchain and starts being a system that gets better on its own. Real usage data and live telemetry feed a standing improvement cycle that continuously proposes concrete technical work, feeds it back into planning, and closes the loop.
Data and AI as first-class operating surfaces
Two capabilities are what let the platform be operated conversationally rather than through a dozen consoles.
Talk to your data. Instead of standing up heavy BI infrastructure and waiting on a report queue, analysts ask questions in plain language. The AI assistant writes and runs the query against the warehouse through a governed connector, and returns the answer as a live chart, table or interactive widget in the same turn. Access is scoped by the same group membership that governs everything else, sensitive columns are protected, and every query is audited. The distance from question to insight collapses from days to seconds, without giving up governance.
AI as an operator, not just a chatbot. The assistant is wired into the platform through a catalogue of governed tool connectors. Through them it can query the warehouse, inspect running infrastructure, read logs and traces, look at product usage, and read or update planning documents — all with least-privilege scopes and confirmation required for anything destructive. Every action is audited. The output isn’t a wall of text; it’s an artifact — a dashboard, a report, a calculator, a widget — something a human can actually use and share. A gateway sits in front of the models to manage keys, quotas, budgets and routing, and an observability layer tracks the cost, latency and quality of every AI call.
Put those together and you have a platform a person can operate by describing what they want, while the system keeps the guardrails on.
The big idea: the continuous improvement loop
Here’s the cycle that makes the platform self-improving. It runs continuously, and every turn feeds the next.
Observe. Pull in the live signals: how features are actually used, how services actually perform, what things actually cost, and what the security posture actually looks like.
Detect. Find what matters in that noise — an anomaly, a reliability budget burning too fast, a slow code path, a feature nobody touches, waste, a recurring risk.
Suggest. Turn the finding into a concrete, written improvement — not a vague concern, but a specific proposal.
Prioritise. Weigh impact against effort and pick what to do next.
Execute. The chosen improvement becomes a real, tracked task and ships through the same paved road as everything else.
Measure. Check whether the signal actually moved. Did the change do what it promised? Confirm it, then go back to observing.
For years, every one of those steps except the last needed a person. Someone had to read the dashboards, connect the dots, write the proposal, make the call, and later come back to verify. The loop existed on a whiteboard, but in practice it ran only as often as a human had the time and attention to run it. That’s the constraint that has now lifted.
Loop Engineering: the discipline that runs the loop
Loop Engineering is the practice of designing, deploying, governing and observing intelligent loops that run continuously and improve the thing they are watching.
A loop, in this sense, is not a script. It’s an AI agent given a job, a cadence or trigger, a set of governed tools, and a definition of done. On each turn it gathers fresh context, reasons about it, decides what to do, does it, and verifies the result before it moves on. The loop is the unit of engineering. You compose loops, chain them, put guardrails around them, and watch them the way you’d watch any other production system.
It sits one level above both DevOps and classic automation:
Automation repeats a fixed action.
DevOps gives humans a fast, safe path to ship changes.
Loop Engineering gives the platform itself the ability to observe, decide and act on a cadence, with humans supervising rather than driving.
Why now: what Fable 5 changes
Loop Engineering has been the dream for a long time. What was missing was a model reliable enough to trust with the loop. An agent that has to run for ten or twenty steps — or for hours — unattended, calling real tools against real systems, cannot afford to lose the thread halfway through, invent a command, or quietly do the wrong thing.
Frontier models in the current Claude generation, and Fable 5 in particular, are what make the loop dependable enough to run without a babysitter. Fable 5 is built for long, autonomous work: it can sustain a multi-stage task over an extended session, verify its own output, and carry out ambitious code and knowledge work with minimal oversight. The qualities that matter for Loop Engineering are:
Long-horizon autonomy. The model can hold a multi-step task in mind, plan across it, and carry context from the observation at the start of a run all the way to the verification at the end.
Real tool use. It doesn’t just talk about the systems — it operates them through governed connectors: querying the warehouse, reading telemetry, inspecting infrastructure, filing tasks.
Unattended reliability. It can run a full cycle end to end without a human prompting each step, which is the entire point of a loop.
Self-verification. It can check its own work, compare a result against the goal, even read a screenshot of a rendered interface and judge it against the design, and decide whether the loop succeeded or needs another pass.
Structured, auditable output. Its actions come out as clean artifacts and structured results that downstream steps, and humans, can rely on.
Put simply: the loop was always a good idea. Fable 5 is the first-class engine that makes it safe to leave running.
Self-improving is not self-learning
A point worth being precise about, because it’s where most people get the idea wrong. Self-learning would mean the model rewrites its own weights as it goes. That’s not what’s happening, and it’s not what you want in a governed production system. What Loop Engineering delivers is self-improvement, which is a property of the system, not the model.
The model stays constant. The environment around it sharpens. Every run writes down what it learned, verified facts accumulate, the procedures the loops follow get refined by real edge cases, and the next run starts smarter than the last because it inherits that memory. Nothing about the model changed — the system compounded. Self-improvement is a property of the system, not the model, so you build the system. That’s exactly what Loop Engineering is.
What actually makes a loop get better
Three patterns separate a loop that compounds from one that just repeats. We build all three in.
Independent verifiers, not self-critique. A model grading its own work has skin in the game: it tends to bless conclusions consistent with its own reasoning. So the maker and the checker are kept separate. One agent produces the work; a second, independent agent sees only the finished artifact and the rubric — with no exposure to how it was made — and returns a verdict. If the verdict fails, the loop iterates. It exits only when an impartial checker passes it. This single design choice is the biggest driver of trustworthy autonomous loops.
Memory that compounds. A loop that forgets everything between runs can’t improve. So each loop follows a memory progression: it records a failure, investigates why it happened, verifies the diagnosis into a checked fact, distils that fact into a general rule, and then consults the rule on the next run instead of re-deriving it. Verified facts and hard-won rules live in durable state that every future run reads at the start and updates before it finishes. Recurring know-how gets promoted into reusable procedures, so a lesson learned once is applied everywhere. Two weeks of disciplined writing produces a system that materially outperforms starting fresh each time.
Tiered routing for economy. Not every step needs the most powerful model. A well-engineered loop uses a heavyweight model like Fable 5 as the orchestrator for the long, hard, multi-day work, delegates bounded sub-tasks and high-volume worker jobs to lighter, cheaper models, and uses the smallest, fastest models for simple grading. Matching model power to task difficulty keeps a continuously running fleet of loops economical rather than extravagant.
The anatomy of a well-engineered loop
Every loop we build shares the same skeleton — and this is where the “engineering” in Loop Engineering lives:
A trigger — a schedule, such as every weekday evening, or an event, such as a deploy or an alert.
An objective — a crisp statement of what the loop is for, narrow enough to be verifiable.
Scoped tools — only the governed connectors this loop needs, at least privilege. A cost loop can’t touch production; a reporting loop can’t delete anything.
An independent verifier — a separate checker that grades the output against the objective before the loop is allowed to finish.
Persistent memory — durable state the loop reads at the start and updates at the end, so each run inherits what the last one learned.
Guardrails — destructive actions require confirmation, high-risk changes stop and ask a human, and everything is logged.
A definition of done — the signal the loop is supposed to move, so success is measurable rather than assumed.
Observability on the loop itself — cost, latency and quality of the loop’s own runs are tracked, because a loop is a production workload.
That last point is the discipline that separates Loop Engineering from “we let an AI run overnight.” Loops are supervised, budgeted, audited and measured. They aren’t magic — they’re operated.
Loops already running
The improvement cycle isn’t the only loop. The platform runs a family of scheduled AI agents that each own a slice of operational health — and, crucially, prepare the ground for the humans:
A weekly cost review loop pulls spend from the warehouse, finds the waste and the spikes, and produces the report leadership reads on Monday morning.
A usage-to-improvement loop rolls up product analytics every week and turns real behaviour into candidate improvements, so the improvement log is never empty.
An access-drift loop compares who should have access against who does, and flags the difference before it becomes an audit finding.
A security-findings loop digests the day’s posture and threat signals into a briefing instead of a flood of alerts.
A reliability loop rolls up service-level performance and error budgets, and surfaces the services trending the wrong way.
Notice the pattern. Each loop does the gathering, the reading and the first draft of the thinking, then hands a human a decision that’s already framed with the data attached. The meetings that used to start with “let me pull the numbers” now start with the numbers already on the table. The humans spend their time deciding, not fetching.
What the experience feels like
For a developer. You have an idea. You open a task, scaffold a project from a template that already has everything wired, and push your code. The pipeline runs your tests, load tests and security scans as gates, so you find out immediately if something is wrong — not in a review three days later. When it’s green, promotion to production happens through the paved road with no infrastructure ticket. The moment it’s live, it’s already observable, already secured, already on the dashboards. You didn’t configure any of that. You followed the road, and the road did the rest.
For an SRE. You’re not staring at ten consoles hoping to catch a problem. The loops watch continuously. Reliability trends, error budgets and anomalies come to you, framed and prioritised. When something breaks, production rollouts abort themselves on a reliability breach before you even reach for the runbook — and when you do need to act, the runbook is right there. Your standup and your ops review open with a pre-read a loop already prepared. You spend your attention on the hard calls, not on assembling the picture.
For an analyst. You don’t file a report request and wait. You ask your question in plain language, and the answer comes back as a live chart or interactive widget you can share, in the same conversation. The warehouse is serverless, access is governed by your group membership, and every query is audited. Insight is a sentence away, and governance was never traded for speed.
For a platform admin. Day-to-day operation happens conversationally. You ask the AI assistant to inspect a cluster, check a budget, or summarise the week, and it does the work through governed tools and hands you an artifact. Access is a matter of group membership, so onboarding and offboarding are clean and instant. The recurring reviews — cost, security, access, reliability — all arrive pre-built by loops. You supervise a system that largely runs itself, and you can prove, at any moment, exactly what it did and why.
For leadership. The platform is legible. Every service is visible in one place, every cost is attributable, every access grant is traceable, and the list of proposed improvements is never empty. The organisation isn’t depending on any single person remembering to look. The looking is engineered in.
How it functions under the hood
Strip away the narrative and the mechanics are straightforward — which is the point.
Cadence and triggers. Loops fire on schedules or on events. Scheduled loops handle the rhythm of operations: the nightly, weekly and monthly reviews. Event-driven loops react to deploys, alerts and threshold breaches. Between them, the platform is always either watching or acting.
Governed tool access. Every loop reaches the systems it needs through a catalogue of connectors, each scoped to least privilege. The loop that reviews cost can’t change infrastructure; the loop that reports on usage can’t touch secrets. Scope is the safety mechanism, and it’s declared, not assumed.
Observe, act, measure. Each loop follows the same arc: gather fresh signal, reason, take a bounded action or produce an artifact, and verify against a defined outcome. The verification step is what makes a loop trustworthy, because a loop that can’t tell whether it succeeded is just noise on a timer.
Governance and audit. Destructive operations require confirmation. High-risk decisions escalate to a human. Every action — by a human or a loop — is logged and reviewable. A gateway in front of the models enforces budgets and quotas, and an observability layer tracks the cost and quality of every AI call, so the loops themselves stay within their means.
The human half. None of this removes people; it repositions them. Short, timeboxed reviews turn the loops’ outputs into decisions, and decisions into owned work. The loops do the gathering and the first-draft thinking. The humans do the judgement, the trade-offs and the accountability. That division is deliberate, and it’s what keeps the whole system both fast and safe.
Why it matters
Engineering the loops in, rather than leaving them to human attention, produces a platform with a different set of properties:
It doesn’t decay when nobody is looking, because the looking is continuous and automated.
It surfaces work instead of hiding it. The backlog of improvements is generated from real signal, so the team is always working on what actually matters.
It compresses the distance from signal to action. A cost spike, a reliability regression or an unused feature becomes a framed, prioritised, trackable piece of work in hours, not quarters.
It stays governed at speed. Everything runs behind one identity, with least-privilege access and a full audit trail, so moving fast doesn’t mean losing control.
It scales the team’s judgement, not its toil. People spend their time deciding and building, while the loops handle the watching, the gathering and the measuring.
This is the shift we’re putting a name to. DevOps gave us a fast, safe way to ship. Loop Engineering gives the platform the ability to run and improve itself on a cadence, with people supervising rather than driving every step. And it’s available with today’s technology, not a someday promise — because the models are finally reliable enough to trust with the loop.
Work with Wohlig
Wohlig designs and builds self-improving internal platforms end to end: the paved road from idea to production, the single governed identity layer, the observability and security backbone, the conversational data and AI surfaces, and — above all — the engineered loops that keep the whole thing getting better on its own.
If your engineering organisation is carrying the cost of a scattered toolchain and a platform that only improves when someone finds the time, this is the model that changes the equation. Talk to Wohlig about bringing Loop Engineering to your platform.