Agentic loops: from prompting to a multiplayer team of agents

Why engineering has loops and product does not

The pattern shows up in almost every discovery conversation we have had with product people this year. The engineers have coding agents and ship a ticket in an afternoon. The product decisions still take the same three meetings, and a good share of them never reach the ticket in a form an agent could act on.

Agentic loops are the answer the engineering side found for its half of the problem. Instead of prompting an agent and taking its first draft, you give it a concrete goal and let it plan, act, check and adjust until the goal is met. The idea was everywhere on the engineering side of the internet this summer, and so was the joke that buried it: “We're no longer talking about loops. We're talking about graphs.”¹

The joke hides a real progression. Every stage since 2023 gave the model a bit more independence. This article walks through the stages, shows what changes when the task has no compiler to judge it, and argues that the stage arriving now is different in kind: the work moves from one person and one agent to a team.

I am a co-founder of Teklens. Before that I built Aioma and sold Localina's CRM to Swisscom, and I have taught at ZHAW. At Teklens we have had 24 discovery conversations with product people about how their teams work with AI; the pattern in the first paragraph comes from those. The engineering practice in this article comes from the sources at the end, chiefly a September 2026 webinar by Nufar Gaspar on The AI Daily Brief, an episode of Lenny's Podcast with Tara Seshan, who leads product for Codex and ChatGPT Work at OpenAI, and the OpenClaw 2.0 release notes as discussed on the same podcast.^1,2,4

The thesis. Each stage of working with AI moved independence from the person to the model. The next stage moves the work from the individual to the team, and it only pays off when two things are designed rather than assumed: the finish line and the shared context.

Why did the vocabulary change every quarter?

Because the object of attention kept moving. Prompt engineering was about what you say. Context engineering was about what the model knows. Harness engineering was about where it runs and which tools it can touch. Loop engineering is about how long it can run on its own. Graph engineering is about how many agents work together. Gaspar's summary of the direction of travel holds for all five: each step gives the AI more independence at a bigger scale.¹

1. Prompt engineering. What you say. The model is an assistant. The skill is phrasing. Most teams still have a document called “good prompts” from this period.

2. Context engineering. What the model knows. The skill becomes supplying the right background: the repository, the ticket, the architecture notes, the coding conventions. This is where product teams first felt the gap, because the context an engineer has in their head was never written down anywhere an agent could read it.

3. Harness engineering. Where it runs. The model gets tools, a file system, a terminal, permissions. An agent can now act, not only write. Every agentic tool you use today, from Claude Code to Codex to Cursor, is a harness around a model.

4. Coding agents. The first agentic loop at scale. Software was the first domain where loops became normal, for one reason: verification is free. Code compiles or it does not. Tests pass or they fail. The agent can check its own work without a human in the loop, so it can plan, use tools, inspect the result, test, and revise until the tests are green.¹

5. Loop engineering. How long it can work alone. The harness already runs a small loop under the hood. Loop engineering extends it: you define a measurable finish line and tell the agent to keep going until it is met. In Claude Code that is the goal command, in Cursor the loop command.¹

6. Graph engineering. How many work together. When one loop is not enough, you split the job across agents that pass work to each other. I covered the mechanics in Graph engineering: multi-agent workflows, not chat chains; this article stays on the why and the when.

One more thing changed underneath the vocabulary, and it belongs to stage two. Context stopped being something an agent reassembles on every query and started being an asset that is curated once, versioned, permissioned and shared. Jörg Schad, VP of Engineering at Pinecone, describes their Nexus system as a materialised view for context: a precomputed artefact with its own schema, metadata and lineage, so an agent gets the same answer to the same question twice and an auditor can see which data produced it. Keep that idea in mind. It comes back when the team enters the picture.³

Why did coding get loops first?

Because a coding task carries its own referee. A test suite is a finish line that is boring, objective and machine-checkable, and boring is a compliment here. When the agent asks “am I done?”, the test runner answers.

Gaspar puts the point sharply for everyone outside engineering: “When someone tells you, just put it on a loop, they're forgetting that they, as coders, had free verification and you don't.” Nobody's compiler decides whether a spec is complete, whether a roadmap is defensible or whether a release note is clear. That is why loops spread through engineering in months and are only now reaching product work.¹

The practical consequence for a product leader is uncomfortable but useful. The parts of your team's work that already have a referee can be looped today. The parts that do not have one need the referee designed first, and some of them should never be looped at all.

How do you design a loop when there is no compiler?

You invent the referee. Gaspar's method is a goal card: an objective, the required artefact, judging and stopping criteria the agent can measure, optional stages, a cycle cap, and limits on time, tools or sandbox. If you cannot write a verifiable finish line, the task is not a loop candidate.¹

A task is loop-worthy when most of this is true: one prompt did not get it done, even with the strongest model you have in one shot. Progress can be checked, so someone or something can tell whether draft three is better than draft two. It can run without you, over lunch or overnight, and you want a finished result rather than a draft. It should continue until a specific bar is reached, not until the agent feels polite enough to stop. And it improves through repetition: more sources, fewer gaps, more test cases, tighter wording.

A task should not be looped when one pass is enough, when your judgment is the actual work, when the outcome depends on taste or an executive's approval, or when there is no stable definition of done. Gaspar's examples of the second kind: executive communication, hiring decisions, strategy. Autonomy has no taste of its own.¹

Step 1. State the objective in one machine-readable sentence. Not “improve the spec”. Instead: “Produce a spec for the invoice export feature that an engineer can implement without asking a clarifying question.”

Step 2. Name the artefact. A file, a ticket, a table. “One markdown file at the agreed path.”

Step 3. Write boring, checkable criteria. Every acceptance criterion maps to at least one existing code module or is flagged as new. Every open question is listed with an owner. No two criteria overlap. Reading time under six minutes. Gaspar's research example uses the same shape: more than 200 unique data points, each with URL and date, a fixed source mix, zero duplicates.¹

Step 4. Add gates only where you need control. For example: stop and report after the first draft if more than three code modules are touched.

Step 5. Cap it. Maximum cycles, maximum tokens or time, and a sandbox where mistakes cost nothing. A loop that runs against your production Jira is not a sandbox.

Step 6. Ask for a log. One line per cycle: what it checked, what it changed, how far from the finish line it is. When you are new to loops this log is how you learn what your criteria actually asked for.

Loops fail in four recognisable ways. The spend runs away, which the cap prevents. The cycles stack without progress, which means the finish line does not converge and you stop it manually. The loop finishes and the result is mediocre, which is the sneaky one: the agent met the letter of your criteria and your criteria were the problem. And the fourth: the task should never have been looped, because judgment was the work.¹

Notice what the third failure teaches. When the output meets your definition of done and you are still unhappy, rewrite the definition, not the loop. Most of the skill lives in that rewrite.

When does one loop stop being enough?

When self-review turns into a rubber stamp. Gaspar's five signals for moving from one agent to several: the agent says “done” and you keep finding things it should have caught; one agent wears too many hats and the objective researcher starts getting creative too early; independent work is running in series when it could run in parallel; the finish line keeps changing mid-run because it hides two jobs; and quality flatlines no matter how you tune the goal card.¹

Two of these deserve a product leader's attention. The rubber-stamp signal has evidence behind it: models tend to agree with themselves, so a verifier should ideally be a different model with a fresh context that knows nothing about how the draft was produced. And the “two jobs in one card” signal is the one product teams hit most often, because a spec is at least two jobs: deciding what to build and describing it so it can be built.¹

A loop is already the smallest graph, one node with an arrow back to itself. Adding a fresh-context verifier makes it a two-node graph. A research fan-out with a synthesiser, a citation checker and a human gate is a six-node graph. None of this needs new tooling. You can draw it on a whiteboard, and if you can draw it, an agentic tool can build it. Gaspar's rule for all of it: if one agent works well, keep one agent. Graphs cost tokens and attention, and a beautiful graph can consume millions of tokens without blinking.¹

There is a trap on the way to the graph. Most people draw the graph the way humans do the work today, with the handoffs, approvals and role splits that exist because humans get tired, lose context and cannot be expert in six things. Agents have different limits. Design for the job to be done, not for the current process.¹

Why is the next stage multiplayer, not a bigger loop?

Because loops and graphs, as practised so far, are single-player. One person, one terminal, one private conversation with an agent. The code that comes out is shared. The process of getting there stays hidden in one session. OpenClaw maintainer Colin named the assumption plainly in the notes for the 2.0 release: “Most developer agent workflows still assume one developer, one terminal, and one private conversation.”⁴

OpenClaw 2.0, a ground-up rebuild by 933 contributors across 16,000 pull requests, made the shared session its headline change. Teammates open the same agent thread while the work is happening. When the agent needs information one of them has, that person adds it directly. When a decision needs a second opinion, both look at the same context. When someone hands over a half-finished server setup, the handoff is opening the thread, not assembling a document of why certain decisions were made and which approaches already failed. The session becomes the record of the work.⁴

Tara Seshan describes the same shift from the tool-maker's side. Work moves from rowing to steering, and the steering climbs the abstraction ladder: from accepting a line of code, to directing a task, to setting a goal. The agents she expects are persistent co-workers that you and your teammates sync with, review in progress, and direct at goal level. Her caveat is the one product leaders should underline: an agent without access to the systems where your data lives is like a colleague you lock in a room without Google Docs, Slack or the company database. Not very useful.²

Persistent, not disposable. Agents that keep context across sessions and sprints, the way a team member does. Gaspar calls the standing version an org graph rather than a work graph.¹

Shared, not private. Sessions that several people can inspect, steer and take over. The handoff document disappears because the thread is the handoff.

Grounded, not isolated. Access to the tickets, the documents and the code, with the context curated once and versioned, so that two people and three agents reading the same decision get the same answer.³

Whittemore's summary on the same episode: so far, agents have been designed for work you do alone, and a huge portion of work is work you do together. That is the next big development for agents.⁴

For a product team this is not a tooling upgrade. It is the moment the loop's referee stops being a test suite and starts being the team's shared definition of what was decided. A coding agent can verify code against tests. Nothing verifies a ticket against a decision that was made in a meeting and never written down. Multiplayer only works if the decision exists somewhere all players and all agents can read it.

What survives the next renaming?

Loops pay off wherever a finish line can be written down and checked: research sweeps, spec completeness checks, test-strategy drafts, release notes, campaign optimisation with real metrics. They do not pay off on judgment calls, and the temptation to loop those is strong because the tooling makes it easy. Cal Newport's argument on effort and reward is a useful counterweight: reward is nonlinear, so one thing done deeply beats five things nudged along. A loop is a way to give one task that depth. Ten loops running at once are ten shallow things with a token bill.⁵

Graphs pay off when verification needs independence or work can run in parallel, and they cost tokens, attention and design time. Start with one agent, add a loop when one shot fails, add a second node when self-review stops catching errors.

Multiplayer is early. OpenClaw's implementation is one team's experiment, ChatGPT Work and Codex are being built for model capabilities two to three months out rather than for today's, and the commands for loops and sub-agents change between releases, sometimes between the CLI and the desktop app of the same tool. Check the current documentation before you standardise anything.^1,2,4

The stages will keep being renamed. The skill under them does not change: define the work, choose the level of autonomy, build the verification, coordinate the agents. That is Gaspar's closing point, and it is also the job description of a product leader in 2026.¹

Which brings the article back to the pattern in the first paragraph. The engineers had loops with a referee. The product decisions had neither a finish line nor a place where the agents could read them. Coding got fast. Knowing what to build did not, because the knowing was never written where the players could see it.

Where Teklens sits in this picture

This is the one place Teklens belongs in this article. Everything above describes the engineering half of the loop: agents that build until the tests pass. The product half is the decision, the spec and the ticket, and that half has no compiler. Teklens is built as the shared context for exactly that half. It reads Jira, the docs and the repository, keeps one living spec per initiative, and when a decision changes, every ticket and file that depends on it knows. Product decides, engineering sees the code impact, the coding agent gets its context from the same source. In the vocabulary of this article: the referee for the product side, and the shared session for the whole team.

We publish names and numbers only with permission, so there is no metric here. If you want to see the mechanism on your own repository, book a call with a founder. One call, and Jira and your repo are connected in under an hour.

Frequently asked questions

Recommendations

• Pick one recurring task with a natural finish line. Write its goal card and run it as a loop with a cycle cap this week. The log of the first run is the lesson.
• Fix the definition, not the loop. When the result meets the criteria and still disappoints, rewrite the criteria before you touch anything else.
• Add an independent verifier first. A different model with a fresh context that knows nothing about how the draft was produced is the first node worth adding.
• Draw the graph for the job, not for the meeting structure. Handoffs, approvals and role splits exist because of human limits. Agents have different ones. Start from the outcome, not from today's process.
• Check whether your decisions are readable. Before you buy into any multiplayer tooling, check where your product decisions are written down and whether an agent could read them. If not, that is step one.

Scope & caveats

• The stage model comes from Nufar Gaspar's webinar on The AI Daily Brief (3 September 2026) and reflects practitioner usage as of that date, not an academic taxonomy; she says herself the terms will be renamed by winter.
• The OpenClaw figures (933 contributors, 16,000 pull requests) are the project's own release numbers as reported on the podcast, not independently verified. Tara Seshan's statements describe OpenAI's internal practice and product direction, which is a vendor's view. The Pinecone Nexus description is the vendor's account of its own product.
• The 24 discovery conversations are Teklens' own, with product people, and they are conversations, not a study; the pattern in the opening is what recurred across them, not a single quote.
• The Teklens statements describe product capabilities, not measured customer results; names and figures only with permission.

Sources

Every external figure and quote in this piece – linked so you can verify it.

1. 1.Nufar Gaspar und Nathaniel Whittemore, «Agentic Loops for Knowledge Workers», The AI Daily Brief, 3. September 2026 ↗ – The backbone of this piece: the five stages from 06:44, the goal card demo at 23:03, the failure modes at 26:52, loops to graphs at 33:19.
2. 2.Tara Seshan mit Lenny Rachitsky, «AI's third era: the rise of persistent AI coworkers», Lenny's Podcast, 30. August 2026 ↗ – Rowing versus steering and persistent co-workers from 11:25; the rule of building two to three months ahead of the models at 28:01.
3. 3.Jörg Schad mit Kevin Ball, «Moving Beyond RAG with Precomputed Context», Software Engineering Daily, 3. September 2026 ↗ – Context as a precomputed, versioned, permissioned artefact at 07:04 and 09:58.
4. 4.Nathaniel Whittemore, «OpenClaw 2.0 Shows Where AI Agents Are Going Next», The AI Daily Brief, 1. September 2026, mit Zitaten von Peter Steinberger und OpenClaw-Maintainer Colin ↗ – The shared session at 24:11; “work you do alone versus work you do together” at 25:33.
5. 5.Cal Newport, «Ep. 209: Email and Living with Purpose», Deep Questions, 15. August 2022, Segment «You need to do less» (57:21) ↗ – Not about AI, and the right warning before you run ten loops at once.

Keep reading in the PM Lab

Related deep dives – from the same pillar and the adjacent phases.

Matching use cases from the library

From the article straight into practice: these use cases put the concepts to work with Teklens.