Table of Contents
This edition takes a different direction from previous ones. The goal of this newsletter is to help us understand the latest technologies and concepts shaping the AI industry, first for ourselves, and then to share them here in a way that can actually help operators, or the industry in general.
Over the past few weeks we've covered specific frameworks, skill guides and the AI features Nexudus has been building, all of them meant to help operators generate immediate value in their operations and in the member experience.
Today we're covering something different: a concept that got a lot of attention across the AI industry this past month, called Loop Engineering. Our goal here is not to present it as the definitive framework for how AI systems should work. The industry is moving fast and new technical requirements appear along the way. In the coming months new developments will arrive, built on top of what we already have: prompting, context and skills.
So let's look at why the AI industry moved from prompt engineering to context engineering and now toward loop engineering, and what that last stage offers the coworking industry.
How AI has evolved: prompting, context engineering and loop engineering
Just a bit of history 😊
The most frequent way users have interacted with AI until now has been through chatbots and conversational interfaces. Enter a prompt, get an output, refine it until the result is useful. The industry spent two years getting better at this: clearer role instructions, examples of the desired outcome, more precise step-by-step task descriptions. Prompt engineering was the field. The limit showed up quickly: without a specific business knowledge base or context layer to ground it, the agent could hallucinate.
Context engineering solved that. In this second stage the operator stops packing everything into a single prompt and starts building the environment the AI works in: the data layer and knowledge base, the tools, the skills, the CLI or MCP connections that give the agent access to what it needs. This is what let spaces build a base where the LLM could reason from their own business context rather than from generic training data.
So once the context layer, the skills and the tools the LLM can reach are defined, what comes next? Two problems are worth naming first:
A well-written prompt solves a task once. Run it again next week and you get a similar result, it has learned nothing from the runs in between. There's no continuous improvement.
Agents decay in production. The instruction file grows with every edge case. The evaluation criteria shift, but nobody remembers when or why. Each fix gets pasted into a chat or a file, the output changes, and the history is gone.
This is what loop engineering tries to solve.
Boris Cherny, who leads Claude Code at Anthropic, shared: "I don't prompt Claude anymore. I have loops running that prompt Claude and figuring out what to do. My job is to write loops."
Peter Steinberger, creator of OpenClaw, posted the same idea on X days later: "You should be designing loops that prompt your agents".
Two relevant voices from different sides of the industry, saying the same thing within the same week.
Loop engineering shifts the work from writing a good output to building the system that produces a better one each run.
Let's explore how it works.
What's a loop?
A loop is a cycle an AI agent runs through repeatedly. The agent runs, the output gets evaluated, the change stays if quality improved and gets reversed if it dropped. The learning is then saved to a history file, so the next run starts ahead of the last one.
Every functioning loop has five parts:
Trigger: when the loop starts. A schedule, a command instruction, an event in the platform.
Action: what the agent should do, usually encoded as an execution skill, a saved instruction set the agent runs the same way every time.
Proof: how the operator and the system know the output got better. This is where evaluation lives.
Memory: where the learning gets saved. No memory, no improvement. It can be as simple as a markdown file that logs what happened, what worked, what failed, and what to remember on the next run.
Stop condition: when the loop should end. Many AI systems do not fail because the LLM is weak. They fail because the loop has no clean exit. The agent keeps generating, expands the scope on its own, or delivers a confident summary without enough evidence behind it. Before spending tokens on work that has drifted from the objective, the system stops and asks for approval.
The main goal of a loop is to produce more intelligent and more relevant work every time it runs.
How to know if a task can be implemented as a loop:
Does the task repeat? For anything one-time, a prompt is enough.
Is there a clear definition of done? A loop without one will keep prompting itself indefinitely.
From prompt to loop: the member feedback use case
Member feedback is the example we keep returning to in this newsletter, because it makes these concepts easy to illustrate. Let's use it to walk through the key differences between the three stages: prompting, context engineering, and loop engineering.
Prompting
At this stage, the operator exports the help desk data, uploads it to Claude or ChatGPT, and asks what members are complaining about. The output is useful, but next month they start from zero: upload the new dataset, run the prompt again. Then they notice that last month the model called it "connectivity issues" and this month "WiFi problems", same complaint, two labels, no way to track a trend. There's no way to tell whether complaints about a specific topic are above average this week. The prompt gives a snapshot, not a comparable, aggregated view. The results aren't consistent across executions.
Context engineering
In this second stage, the team gives the model access to the data layer and knowledge base it needs, and defines a detailed skill to analyse member feedback: a fixed taxonomy where WiFi is always SF-01, a fixed priority formula by topic (frequency × impact), and a fixed output (theme table, topic priority, root causes, 30/60/90 action plan). Now anyone inside the team can run it and the same structure comes out every execution. But the skill is static. There is no way to monitor how the metrics behind the action plan perform in the next executions. The output is more relevant, and it creates consistency, but it still does not improve between runs. The skill definition is not updated between runs, and there is no memory of the actions deployed.
Loop engineering
The loop runs weekly and reads new tickets against a theme history file: what repeats, what's new, how this week compares against the last four, so the team can see whether a topic is escalating and requires immediate action. It also signals when the taxonomy needs a new code.
Then the operator reviews, and the correction doesn't stay in the chat. If the analysis flattened a nuance, the skill instruction that produced it gets fixed. If a code was missing, it's added to the taxonomy. If the formula under-weighted a theme repeating for four weeks, the recurrence rule goes into the skill. Every correction is written back into the file the agent runs next time.
The skill is no longer written once and applied, it's edited by its own results. The history file keeps the memory of what was analysed, what changed and why, so each execution starts from the corrections of the ones before it. The next run gets better.
Prompting does the task once, context and skills do it the same way every time, and loop engineering makes each run better than the last.
A real use case makes the five parts easier to see.
A loop example: reducing unnecessary handoffs in a support agent
This example is deliberately further along than most coworking spaces are today, but it shows clearly how a loop works: one that refines the agent's skill and guidelines to reduce handoffs to a human, with every proposed improvement verified by the team before it's consolidated.
The starting point is an operator whose support agent already answers member questions in production, and who wants to tighten its guidelines so fewer tickets end up with staff.
Goal: reduce the number of handoffs to a human that the agent could have resolved on its own.
Boundary: the agent can attempt resolution, ask clarifying questions, and pull booking and member data. It cannot issue refunds, override access permissions, or change contract terms. Mandatory escalation triggers stay untouched (billing disputes, legal or complaint language, etc.). The loop adjusts policy, and escalation rules, inside those limits and never widens them.
The loop itself
1. Trigger: Two triggers feed this loop. Every ticket the agent escalates enters the review queue. Every ticket the agent closes on its own enters the autonomous-close log, where it waits seven days to see whether the member comes back.
2. Action: A judge LLM, separate from the agent that handled the original ticket, reviews each escalated case against the criteria a human would use. The judge sees the information the agent had at the moment it decided to escalate (member record, booking history, prior tickets, etc.) and not the resolved thread.
Did the human resolve it with information already available to the agent, or did the case require asking the member for something new? The judge marks the case avoidable or not avoidable.
The judge returns one code:
To simplify this use case, only the first code counts toward avoidable. Cases that require human judgment are never acted on automatically. Where the judge finds a pattern across avoidable cases, it drafts the change that would have prevented them: an edit to the policy file, a tightened guideline, or a skill the agent needs to resolve the case itself.
Recommendations for reducing unnecessary approval handoffs ship on a weekly cadence. A topic qualifies once it has been raised repeatedly and shows a clear improvement gap.
3. Proof: two numbers carry the metric. The unnecessary handoff rate is the percentage of escalated tickets the judge marks as resolvable with data the agent already had. The bad-close rate is the counterweight: the percentage of autonomously closed tickets where the same member replies or opens a new ticket within seven days.
A falling handoff rate only counts as progress if the bad-close rate holds flat alongside it.
The metrics tell you whether the agent improved. You also need to check that the judge is still reliable enough to say so, and that's what the golden dataset is for: a fixed sample of escalated tickets a human has already marked avoidable or not avoidable. Re-running it through the judge every few weeks shows whether its codes still match the human ones. If they drift, the handoff rate stops being a reliable number.
4. Memory: When a topic's unnecessary handoff rate falls below the target and its bad-close rate has held flat, the loop drafts the update to the policy file and writes it once a human has approved it. An entry might read: last-minute booking changes within 24 hours follow the standard proration rule, do not escalate.
Every change is logged with the evidence that triggered it, so the policy file's history doubles as an audit trail. The same file records what did not land: proposals a human rejected, with the reason given, and changes reverted after the bad-close rate rose.
5. Stop condition: The loop keeps proposing changes for a topic until its unnecessary-handoff rate holds below target. No change takes effect without human approval. Proposals are aggregated and delivered weekly, and only for topics that come up regularly.
Each suggestion arrives with the evidence behind it: the tickets that produced it, the judge's code on each one, and the metrics for that topic. A person then accepts, edits, or rejects the wording. The loop never writes to the policy file on its own. It does the analysis, builds the case, and drafts the rule, and a human decides whether that rule becomes policy.
A topic then converges when its unnecessary handoff rate holds below the target and its bad-close rate stays flat for three consecutive weeks after the accepted change. At that point the change is treated as settled rather than provisional, and the loop stops proposing on that topic.
Two escalation examples from the loop: one avoidable, with the learning and the proposed change behind it, and one that was right to escalate.
Final Thoughts
Loop engineering adds what the first two stages left out: a system that improves with each run, and a memory of what changed to shape the next one.
A place to start this week:
Pick one task the team already repeats and that has a clear definition of done.
Define the trigger, the inputs it consumes, and the step-by-step process. Codify that process as a skill with a single primary action. Specify what good output looks like, the metric it must beat, and the stopping condition that sends it back for approval.
Run the loop and learn from it.
That's it for today. See you in two weeks.