Agent sprawl
Half a dozen sessions running at once, and nobody can say what state any of them are in.
Loop engineering · operated agentic dev loop
AI coding tools without a harness are just fast typing. Loop engineering is the part that delivers.
WebbyLab designs and operates agentic dev loops in production — planning, implementing and releasing product with a human gate.
Case study
Loop engineering on a production AI agent platform
These loops run in production on a commercial AI agent platform we built — a product with paying customers and a release schedule, not a lab experiment.
Planner human-approved
status::needs-planningstatus::planningstatus::ready-for-dev
Reads the issue, works up the approaches, writes the plan into the issue as a comment: goal, acceptance criteria, decomposition, risks.
Developer autonomous
status::in-progressstatus::in-review
Branches off main, implements through sub-agents — implementer, tester, reviewer — and opens the merge request. It never pushes to main and never merges its own work.
QA human-approved
status::bug-awaiting-approvalstatus::bug-in-progressstatus::bug-in-review
Own label scope, so it runs alongside the developer loop without fighting over issues. A person decides which bugs are worth fixing before any work starts.
blocked— the loop asks one grouped question in Slack, names the issue, and waits. It resumes on the first reply that isn't its own.failed— tests would not go green, so the issue goes back to a person with the reason. No silent retrying, no burning quota against a wall.
One issue per tick. Each tick is one agent turn that ends by itself, on a schedule — not a process left running. Nothing lives in a WebbyLab database: the labels and the issue thread are the state.
A diagram only goes so far. Book a demo and we will show you how it really works — the live issue queue, a loop mid-flight, and the Slack thread where it stopped to ask us a question.
Book a demoSeats solved the easy part.
The verification tax
Code arrives faster and in bigger batches, so review becomes the new bottleneck. DORA named this: time saved writing code gets re-spent auditing it.
No proof of ROI
Spend climbs and there's nothing to show leadership when they ask whether it's working.
What changes when the loop runs
Not "your developers type faster". The work stops waiting on people being free, and the standard stops depending on who picked the ticket up.
5×
faster from request to delivered feature
Across features and initiatives once the loop is running. Most of that is not typing speed — it is the waiting that disappears: for a developer to come free, for the next planning session, for someone to pick the item up.
Best practice becomes the system, not the person
SDLC discipline usually lives in whoever happens to be on the task. In a loop it is built into the cycle itself: every item gets a written plan, tests, a merge request and a human review — the boring ones as well as the interesting ones.
It runs 24/7, not 8/5
Your team keeps office hours. The loop doesn't — planning and implementation carry on through the evening, the weekend and the holiday, and the release is still there waiting for a person on Monday morning.
From idea to work started in seconds
File the item and the next tick picks it up. Nothing waits for standup, for sprint planning, or for a calendar to open — the gap between having the idea and having work underway effectively disappears.
Token spend engineered down
Anything a deterministic script can do, a script does. Loops are scheduled rather than left running, retries are bounded, and cost per item is measured from day one — so the spend is a number you manage, not a surprise on the invoice.
One loop. Three stages. A person at each end.
Plan
Reads the task, asks questions where it's unsure, writes the spec.
Implement
Branches, writes the code, opens the merge request.
Release
Backs up, deploys, health-checks, rolls back automatically on failure.
Autonomy is proportional to reversibility. A person starts the work and a person starts the release. In between, implementation runs unattended — a branch can be thrown away, a deploy cannot.
Readiness check: six questions, an honest answer
How big is your engineering team?
Is your test suite reliable?
This matters more than it looks. Our own release loop once treated a flaky suite as a real failure, then as a false pass — a race condition, then timeouts from a shared dev box. A loop can only trust what CI tells it.
How would you describe your doc & spec discipline?
Does your tracker reflect reality?
Count the cards genuinely in progress against the number of developers. If it’s several times higher, the board isn’t reflecting how work really happens — and a loop has nothing real to read from it.
Where is AI tool adoption today?
How soon do you need to show results?
Result
One thing to fix first: your test suite
The loop gates release on tests passing, so a flaky suite means it can report a failure that isn’t real — or worse, a pass that isn’t either. Most teams close this in two to four weeks. That’s fixable work, and we can help with it before any loop conversation.
Result
A little early for an operated loop
An operated loop needs something to operate. Get your team onto AI coding tools first and come back when you’ve felt the plateau — that’s exactly the point we pick up from.
Result
One gap to close first
The planning loop reads specs and tracker state to work from. Right now there isn’t enough of either for it to read. Even one team writing short specs, with a board that reflects real work in progress, is usually enough to start a pilot on.
Result
Your team looks ready to pilot an operated loop
Nothing here rules out a pilot. A Loop Readiness Audit is the fastest way to confirm scope and see a concrete plan for your stack.
Nine steps, one team, five to seven weeks.
-
1
Discovery
One week of active work to map your SDLC, tooling and team, and confirm the loop can run here. One week of our time — calendar time depends on your approvals.
-
2
Loop design
What Plan, Implement and Release look like for your stack specifically.
-
3
Tools integration
Messengers, infrastructure, and your tracker: Jira, Linear, Trello, GitLab, GitHub.
-
4
SDLC & process tuning
Only where needed. Sometimes that means saying your branching model doesn’t suit a loop; trunk-based generally fits better than long-lived branches.
-
5
CI/CD modification
Only where needed. The loop depends on CI meaning what it says.
-
6
Test environment
A safe place for the loop to build and verify before anything reaches your main branch.
-
7
Task examples & rules
Your conventions made explicit, so agents work from your house style.
-
8
QA loop
A separate verification loop. This isn’t the dev loop pointed at testing: an agent asked to implement something will rationalise its own output as correct, so verification needs a fresh context whose only job is finding what’s wrong.
-
9
Cost & ROI measurement
Instrumented from day one: AI service cost, cycle time, and time-to-production in real terms.
Anything a deterministic script can do, a script should do. Burning tokens on work a CI job already handles is waste, and we design the loop that way from the start.
Why WebbyLab for agentic SDLC work
| Dimension | AI coding tools | Enterprise programmes | WebbyLab Loop |
|---|---|---|---|
| What it is | A seat per developer | A multi-track transformation | An operated loop for your team |
| Time to value | Immediate, then plateaus | Months before first result | 5–7 weeks to a proven pilot |
| Who runs it | Your developers, unaided | Your team, after training | We operate it on your infrastructure — or build it, train your team and hand it over |
| Proof | — | Case studies, sample scores | A live product runs on these loops today |
Model-agnostic. The loop coordinates whatever tools you already use; the coordination layer lives in your tracker, not in a vendor’s platform.
Frequently asked questions
Common questions about loop engineering, agentic SDLC, and how an operated loop behaves in production.
Loop engineering is the practice of designing the repeatable cycle an AI agent runs in — its trigger, its goal, its stop conditions and its guardrails — instead of prompting the agent task by task. In software delivery it means agents plan, build and verify work continuously, while humans design the loop and hold the decision points.
It's a system that plans, writes, tests and releases code using AI agents, run continuously by a partner rather than left to your team to configure. Unlike a coding assistant, it runs as a background process with its own state in your tracker and human checkpoints at defined gates. Designing that cycle — its triggers, its gates and its stop conditions — is the loop engineering work.
Those tools assist one developer at a time. An operated loop coordinates planning, development and release across a whole team, with a tracker-based state machine and human review gates. It's a system, not a seat — and it works alongside whichever of those tools you already use.
Either. By default we operate it on your infrastructure, because keeping a loop healthy is ongoing work — prompts drift, CI changes, new edge cases turn up. The alternative is that we design and build it, run it until it is stable, train your team on it and hand it over. Nothing holds you to the first option: the loop's instructions live in your repository and its state lives in your tracker, so there is no WebbyLab platform to keep paying for.
No. Work starts when a person files it, and release is always started by a human, with mandatory backups beforehand and automatic rollback on failure. In between, implementation runs unattended because its output — a branch, a merge request — is reversible in a way a deploy is not. There's also a kill switch that stops every loop immediately.
Bounded retries, defined stop conditions, and a kill switch. Loops are also scheduled rather than left running continuously, and anything a deterministic script can handle is left to the script. A single unattended loop can consume hours of quota quickly, so cost control is designed in from the start, not added later.
The loop gates progress on tests passing. If the suite is flaky, the loop either treats a real failure as noise or treats a false pass as success — and both are worse than no automation. Reliable CI is the single hardest prerequisite; without it we recommend fixing that first.
A typical first pilot runs five to seven weeks end to end on one team, covering discovery, loop design, tool integration, and a stabilisation period before handover. Discovery itself is about one week of active work.
GitLab, GitHub, Jira, Linear and Trello, among others. The coordination layer is your existing tracker — statuses and labels act as the loop's shared state — so you keep the system when the engagement ends.
Book a Loop Readiness Audit
One week, fixed scope. We’ll map your SDLC and tell you honestly whether a pilot is the right next step.