Your agent just shipped a beautiful component. Clean code. Sensible structure. Named everything right.
It also has no idea the page renders blank.
It can't see the screen. It wrote the thing, declared victory, and moved on -- blind to the fact that nothing actually works. If you've spent any real time building with agents, you've watched this happen. Probably this week.
The industry has settled on a word for the machinery that's supposed to fix this. The word is loops. Agentic loops, feedback loops, the agent loop. It's everywhere now.
I think it's the wrong word. I've thought so since January, when I started calling these things circuits in every session and every doc I write. Watching everyone converge on "loop" hasn't changed my mind. It's done the opposite.
Here's why I'm not switching.
First, What "Loop" Gets Right
A loop describes the cycle. The agent acts, sees the result, adjusts, acts again -- around and around until the job's done. ReAct, OODA, "closing the feedback loop," the while-loop of the agent. The word is pointing at something real: iteration. Repetition until convergence.
I'm not arguing the concept is wrong. I'm arguing the word hides the most important part.
A Loop Is Always Closed. That's the Whole Problem.
Think about what a loop actually is. A closed cycle. A loop that isn't closed isn't a loop -- it's just a line.
Now go back to that agent from the top of this article. The one that wrote a component and never found out it rendered blank. That's the single most common failure in agentic systems: the path from "what happened" back to "what I do next" is broken. The agent acts and never learns the consequence.
"Loop" has no word for that. It assumes the connection it's supposed to be describing. Circuits don't. A circuit can be open or closed, and that distinction is the entire game.
That blind agent is an open circuit. All the parts are there. No current flowing. Nothing happening at the other end. The whole job -- the thing Playwright and tooling exist to do -- is to close the circuit so the signal can complete the trip.
You lose that the moment your only word assumes the wire's already connected.
"Loop" Is Already Taken
Second reason, quicker. Open any programming book and count the loops. For loops. While loops. Event loops. Render loops. Infinite loops. It's the most overloaded word we've got.
Reuse it for agent architecture and you're colliding with thirty years of meaning every time you say it. "Circuit" is mostly clear. Not perfectly -- the circuit breaker pattern borrows the same metaphor -- but that's one tidy pattern versus a word that shows up on page one of every tutorial ever written. I'll take the trade.
A Circuit Has Parts. A Loop Just Has Motion.
Third, and this is the one that matters most when you're actually designing the thing.
A loop describes movement. Round and round. That's it.
A circuit describes an assembly -- components wired together, where the wiring carries as much weight as the parts. That's a far better picture of what you're really building: a model, a set of tools, an environment, and the connections between them. Any of those can be present, missing, or wired up wrong.
When something breaks in a circuit, you check the components and the connections. That's exactly the discipline agents demand. "Loop" never asks you to think that way. "Circuit" makes you.
"But Doesn't 'Loop' Capture the Iteration?"
Fair hit. It's the obvious objection: loops move, circuits sound static.
Except that's backwards. In electronics, feedback loops live inside circuits. Oscillators, op-amp feedback, control systems -- the loop is a behavior the wiring produces. It isn't the rival of the circuit. It's a thing the circuit does.
So you don't lose iteration by switching words. You contain it. The circuit is the system. The loop is one move the system makes. That's not loop versus circuit. It's loop inside circuit -- and the bigger word wins.
Your Web App Isn't One Circuit. It's Four.
Here's where this stops being philosophy and starts paying rent.
Build a web app with an agent and you're not running one circuit. You're running several, and some of them are open while you're not looking:
- The build circuit. Code in, compile, errors back out, fix. Usually closed -- the toolchain hands failures straight back.
- The test circuit. Code in, run the suite, read the reds, fix. Closed only if tests actually exist and the agent can run them.
- The render circuit. Code in, render the page, actually look at it, fix. Open by default. Nothing about writing JSX tells the agent the page painted.
- The interaction circuit. Click the button, fill the form, navigate -- like a real user -- and watch what breaks. Also open by default.
See the pattern. Where there's a return path, the circuit's closed and the agent fixes itself. Where there isn't, it's guessing -- no matter how good the model is.
And here's the part most people get wrong: when an agent flails on a UI task, the reflex is "the model isn't smart enough." Usually that's not it. The reasoning is fine. The circuit is just open. It can't see what it did.
This Is Where Playwright Earns Its Keep
So close the circuit.
An agent building a UI with no browser is an open render circuit, full stop. It writes a component and the path dead-ends. It can't see the layout collapse, the button sitting invisible behind a z-index, the click that 500s, the console screaming red. It's soldering parts to a board with no way to check whether anything conducts.
Playwright is the wire.
Give the agent a real browser and the dead-end becomes a return path. Now it can:
- take a screenshot and see what actually rendered
- read the DOM to confirm the elements exist where they should
- click, type, submit -- exercise the real paths a user would
- read the console and network and catch the errors that reading the code would never surface
Now the loop completes -- write, render, observe, diagnose, fix, render again -- and the agent runs current through the whole thing itself. No human in the middle relaying "hey, the button's dead." In practice you wire this in through Playwright's MCP integration, so the browser becomes just another instrument the agent reaches for.
That's the payoff of the word. "Add a feedback loop" tells you nothing. "The render circuit is open -- close it with Playwright" tells you what's broken, where it's broken, and what to wire in. The agent stops guessing the second it can finally see the whole system it's assembling.
Sometimes You Want It Open
One more thing the word buys you: the open state as a choice.
Closing the circuit isn't always right. On a divergent pass -- brainstorming directions, throwing out rough variants, exploring a design space -- clamping the agent to instant feedback strangles it early. Let it run open and generate; judge after. Sometimes closing the loop is just too slow or too expensive to bother with for a throwaway step. And sometimes you leave the circuit open on purpose, so a human sits in the gap as a checkpoint before the current's allowed to flow.
A loop can't be any of those things. A circuit can be all of them. "Open, on purpose" becomes a design decision instead of an accident.
Why I'm Not Switching
I started saying "circuits" in January for a small reason -- "loop" was already crowded and I wanted something cleaner for my own notes.
Months of sessions later, it's not a small reason anymore.
The word names the failure mode that actually trips agents up. It stays out of the way of programming's most exhausted term. It puts the parts and the wiring front and center, which is what you're really designing. And it swallows the loop whole instead of fighting it.
So no. I'm not switching to "loops" just because everyone else did.
When an agent gets stuck, the question that moves the work forward isn't "is the loop running." It's "which circuit is open -- and what closes it?"
Find the break. Run the wire. Watch it light up.
