The Elastic Loop
robert-glaser.de ↗
The Elastic Loop · Part five

Roles

Every role on a team carries judgment about agent work that nobody else can supply: what is worth building, which of several solutions is the right one, and whether the result actually holds up. Checking the output is only the last of those. It is the first thing that gets lost when companies roll out agents: engineering builds the harness, dashboards fill up with velocity, and the people who actually know the product, the users, and the domain stand around wondering whether their job now requires learning Python. It does not. What the loop needs from them runs its whole length. Someone has to set the intent that opens it and bring the context that grounds it. Someone has to supply the BackpressureThe resistance an agent works against while it builds, well before any review at the end: a failing test or type error on the technical side, an acceptance scenario or rubric on the product side. Some of it reaches the agent automatically as a signal in the loop; some it imposes on itself by following a discipline set at the start, like writing the failing test first and working until it goes green. The more of it you can encode, the longer you can let the loop run.A red build is backpressure; the agent reads it and fixes the code. So are acceptance criteria: write them well and the agent works against your definition of good as it goes, instead of a person catching the miss at the end. that keeps it honest. And someone has to have the taste to tell a strong variant from a merely plausible one. The product and domain side of that judgment is also what keeps fast output from sliding into The statistical middle (slop)Output that converges on the bland average of everything the model has ever read: plausible, smooth, and indistinguishable from anyone else’s.The onboarding text that reads like every onboarding text ever written. (the plausible, generic stuff that passes every technical check and dies quietly in the market). Treating non-engineering roles as smaller coders wastes them. Their leverage is the judgment no compiler or linter can provide, across the loop and not just at its end.

The engineer: designer of the loop

The shift here is an identity question. If your professional identity was “I type the implementation”, agentic work feels brutal. If it was “I turn ambiguity into reliable systems”, the canvas just got larger. The new disciplines have names by now: intent design, context engineering, HarnessThe scaffold that turns a model into an agent, assembled from many parts. Among those: the loop it works in, the tools it can reach, how its context is managed as a run grows long (compression, retrieval), the hooks that fire on what it does, subagents, and guardrails. Backpressure and other resistance attach here, and beyond it.An interactive agent tool like Claude Code, Codex, or Pi is a harness. You have been working inside one all along. engineering, backpressure design, verification and evaluation, Outcome gradingJudging whether a result is good, precisely enough that the judgment can be applied again and again, by a person or a machine.You already do the simplest version every time you write a test or a definition of done., variant generation and selection, production learning, and plain judgment about what deserves to exist. Nine is a lot, and nobody masters all of them. The shortest version I have: The developer becomes less like a manual fabricator and more like a designer of executable learning factories.

The product owner: one discipline, two outputs

If you have ever written acceptance criteria, you have already produced product backpressure. You produced it for humans, late in the loop, as part of a handoff. The change is that this material becomes a steering instrument: agents will iterate against whatever definition of good you can make explicit, and they will iterate against the gaps in it too.

POs are not replaced by AI. Their bottleneck moves to intent and verification.

In practice that splits into seven jobs:

  1. Make intent explicit: problem, user, impact, assumptions, non-goals, which constraints are hard and which are negotiable.
  2. Curate product context in agent-legible form (scenarios, examples, decision history, business rules) instead of letting it evaporate in chat threads.
  3. Make options and trade-offs visible before committing.
  4. Test variants in real software, close to the actual architecture and data, because a variant far from the system is output rather than learning.
  5. Prevent backlog inflation, the sprawl pattern in product clothing, since an agent with an unclear mandate generates artifacts faster than any grooming session can absorb.
  6. Co-design evaluation with UX, engineering, QA, and the business side.
  7. Feed production learning back into the next loop: usage signals, rework, support pain.

Notice what these seven have in common. They are one discipline with two outputs. The PO defines the Search spaceThe set of possible solutions a task allows. An agent does not translate a spec line by line; it samples from this space, pulled toward one solution by your context, or proposing a few in a planning step. Generating many on purpose and selecting the best is a discipline you opt into.There are many valid ways to implement a story. The agent is choosing among them, not transcribing the one right answer., which is intent and context and the non-goals that fence it. And the PO supplies what the result gets graded against: acceptance scenarios, CounterexampleA plausible-looking but wrong output you keep on file, so the system learns never to produce that kind of thing again.The bug you once shipped and then wrote a regression test for., RubricA written list of what “good” means for a kind of output, so the same standard can be applied to every result.Acceptance criteria, reused as a grading checklist instead of a one-off.. That sits closer to machine learning engineering than to classic product management. Whether the role’s name survives the shift is a question I cannot answer yet.

The designer

Interaction vignettes can become rubrics an agent’s output gets graded against. Evaluating generated variants is grading work, and designers have been doing the qualitative version of it for years. Brand and voice consistency is domain-specific backpressure of the purest kind, the “this is off” that no test suite produces. And the design system needs to become a constraint in the search space, walls the agent works within rather than guidelines it might read. Not a bin of Lego bricks to snap together and nothing more. That degrades the agent to an assembler and wastes most of what it can do. I am keeping this section deliberately short: this role is less mapped than the PO’s, and I would rather leave it open for now.

The domain expert

Edge cases, professional rules, failure taxonomies, regulatory and operational limits, decision history, the war stories about why the obvious solution was wrong the last time someone tried it. GoldenAn output you have blessed as correct and keep around as the answer key, to compare new output against.The trusted fixture in an integration test: the known-good result everything else is measured against. of known-good output, counterexamples of plausible-but-wrong output. This is the most valuable grading material in the whole loop, for a simple reason. It is the material agents are least able to generate themselves. That makes it the hardest part of the harness to bootstrap, and the part most worth a person’s time to supply.

The people who run the process

Two anchors hold what I can say so far. First, the mirror logic: the loop reflects the team’s rituals back at it, so whatever a scrum master or coach has built into how the team works, agents will amplify. Second, Charity Majors’ observation that AI wins and AI costs often land with different people, so “there is no natural feedback loop”. The backpressure discipline I see emerging is organizational loop closure: making sure what individual loops learn lands with the team instead of staying private practice, and turning loop sizing (tight, elastic, loose: how much line the agent gets) into an explicit team decision rather than something each person quietly settles alone. What does a retrospective look like when half the iterations happened inside an agent run? I do not know yet. Anyone selling a finished framework for it this early is guessing. But if a team builds and evolves a factory (the harness) alongside the products the factory produces, there must be mechanisms in place to identify failures and harden the factory with every iteration.

The engineering leader

The engineering leader carries four jobs in this model.

Do these become new jobs?

So does this spawn new roles, or just reshape the ones you have? Mostly it reshapes them. A new title earns its place only when an important task needs a scarce skill no existing role reliably supplies, and someone will fund it and answer for it when it rots. Most candidates fail that test. The skill folds back into a senior version of a job that already exists, or the next model absorbs it. Everything in the sections above is an existing role whose center of gravity moved, from making artifacts to encoding judgment a loop can use.

One job does pass the test, and it is new. The harness engineer owns the shared scaffold your agents run inside, the loop shapes and tools and graders and guardrails, as a product with a roadmap and a pager. The scarce skill is debugging a probabilistic system end to end and knowing which knob actually moves the failure rate, a reliability instinct most product teams have never had to build. It earns a title the way shared infrastructure eventually does. The harness crosses team lines and rots when it belongs to no one, so a company ends up putting someone on it. Below platform scale it stays a hat a staff engineer wears.

One more sits at the edge: who decides what the fleet is allowed to touch, and who answers when an agent writes to production it should never have reached. That usually attaches to a security function you already have, and someone there has to own it. Past that, the honest answer is I don’t know yet. Whether grading and eval work becomes its own seat, or stays a hat the product owner, designer, and domain expert pass around, depends on scale and on how fast the tooling commoditizes the one hard part, calibrating the judge. So the org chart barely grows. One new title, maybe two at scale, and underneath them the old roles carrying more weight than they used to.

When handoffs stop making sense

Here is the reframe I want to leave you with. Where people expect AI to dissolve silos by making everyone do everything, the actual mechanism is that AI materializes the intermediate steps. The spec draft, the prototype, the test, the review artifact, the things that used to justify a handoff, now appear in hours inside the loop. The old sequence (PO formulates, UX designs, engineering builds, QA checks, operations learns about it later) assumed those steps were expensive enough to deserve their own stations. The loop model runs intent, context, variants, verification, decision, production learning, and the roles gather around it rather than queueing along it. The bottleneck moves to the work everyone now does at once: sharpening the context and the assumptions, weighing the options, agreeing what good looks like.

Stations versus loop Left: the old sequence of roles as a handoff line, PO to UX to Engineering to QA to Ops, drawn in neutral grey. Right: the same people gathered around a central loop running six uniform steps, each role labelled with the backpressure it supplies, in mint-emerald accent. Before The handoff line Roles queue along the work, one station at a time. PO formulates UX designs Eng builds QA checks Ops learns later Each step expensive enough to deserve its own station. After Gathered around the loop AI materializes the intermediate steps. Each role brings judgment no one else can. intent context variants verification decision production learning the loop Product Owner intent + grading material: acceptance scenarios, counterexamples Engineer designs the loop and harness; verification Designer brand & voice, design system as constraint Domain Expert edge cases, golden examples & counter- examples Process & coaching organizational loop closure Eng. Leader where back- pressure investment goes AI materializes the intermediate steps, so the roles stop queueing along the work and start surrounding it.
Stations versus loop: the roles stop queueing along the work and start surrounding it.

Which brings this page back to where it started: every role carries judgment nobody else can supply. The question for your team is:

Whose judgment is still trapped in someone’s head, where no loop can reach it?