BlogDocs
ENKO

Loop Engineering, and Where RelayRoom Fits

· bejoyfuuul

Loop engineering is having a moment. Thanks to the people who tirelessly track AI news across Reddit, Threads, and X, those of us on the consuming end rarely have to wait long for the next term to arrive. I mean that sincerely. It saves the rest of us a lot of digging.

First there was prompt engineering, then context engineering, then harness engineering. Now we have loop engineering.

Before the Loop, the Harness

Before getting into loop engineering, it helps to look at harness engineering. The basic idea is to build the environment and controls an agent needs to work reliably: tools, permissions, state, feedback, and ways to verify what it has done. The focus moves away from producing one excellent answer and toward building a structure in which an agent can observe, act, verify, and continue.

Loop engineering takes that structure and asks what happens when the work needs to repeat. Seen from this angle, RelayRoom does not implement the whole loop. It occupies a narrower part of the system: communication between agents, wake delivery, persistent records, and human visibility.

What Loop Engineering Is About

Loop engineering does not treat an agent as an answer machine living inside a chat window. It treats the agent as a unit of work that keeps moving toward a goal. Instead of having a person type every next instruction, the system defines when the agent runs again, what information it sees, which tools it can use, where it leaves its results, and who verifies them.

The pieces usually include automation, worktrees, skills, plugins or connectors, sub-agents, memory, and verification. Automation lets a loop resume without someone manually nudging it each time. Worktrees give agents isolated places to work. Skills and memory keep recurring context out of endlessly repeated prompts. Plugins and connectors let agents reach real tools and services. Sub-agents make it possible to separate roles such as implementation and review. Verification closes the loop by checking what the automation produced.

The point is not necessarily to remove people. It is more accurate to say that the person's role changes. Instead of driving every turn, a person designs the loop, observes it, and steps in when it needs to stop or change direction. That is why verification and clear responsibility matter just as much as automation. A faster loop can also produce misunderstood code faster.

RelayRoom has a version of the same problem. Better-connected agents can collaborate more easily, but they can also produce bad broadcasts and repetitive wake-ups more easily. Once several agents are connected, deciding when not to connect or wake them becomes part of the design.

Applying It Means Designing Outside the Prompt

Putting loop engineering into practice is not the same as writing a longer prompt. Suppose the request is, "Check CI every morning and fix the failures." That sentence alone does not make a reliable loop.

A working loop still needs to decide:

  • when it should run,
  • which repository and worktree it should use,
  • where it should read failure logs,
  • how it should distinguish failures worth fixing from failures worth ignoring,
  • who makes the change and who verifies it,
  • where the result should be recorded, and
  • how something that needs human judgment should be escalated.

It also needs a way for one run to carry useful state into the next.

Good loops therefore depend on more than model quality. They need state stored outside the model, isolated workspaces, verification paths, and cost guardrails. If the model loses context or has a bad turn, the entire workflow should not collapse with it.

RelayRoom turns some of that surrounding structure into a product. More specifically, it handles message delivery, wake-ups, collaboration history, and usage visibility when several agents are working at the same time.

Where RelayRoom Fits

It would be a stretch to say that RelayRoom implements loop engineering as a whole. I built it because working with several agents had become frustrating, not because I had set out to implement a new engineering doctrine. It does not automatically pick an issue, create a worktree, assign an agent, attach a reviewer, open a pull request, inspect CI, and update memory. Building all of that would have made it a much larger product.

RelayRoom occupies a narrower space. It starts after multiple agents are already running and asks how they communicate, how a paused session is woken, what history is retained, and where a person can see what is happening. It does not run the loops on their behalf. It acts as a coordination layer between them.

By "coordination layer," I do not mean an orchestrator that centrally plans and directs every agent's work. Each agent continues to work independently in its own session and worktree. RelayRoom gives messages, wake-ups, and work records a way to move between those sessions. It does not decide the work. It helps work already in progress stay connected.

There are tradeoffs to that position. RelayRoom does not provide the full automation and verification systems described by loop engineering, but its narrower scope lets it deal with recurring collaboration problems directly. Who asked whom a question? Did the answer arrive while the recipient was idle? Is a conversation that already ended still generating wake-ups? Where is the usage coming from? These are small questions until several agents are running at once.

For RelayRoom at its current stage, the narrower scope seems appropriate. -To be honest, loop engineering was not even on my mind when I started building it.- Describing it as a tool that keeps existing agents from losing one another is more accurate than presenting it as a system that automates everything.

A Feature-by-Feature Comparison

Mapped loosely against the components of loop engineering, RelayRoom looks like this:

Loop engineering RelayRoom Current position
Automation pager wake, sweep, turn-start inbox check Focused on message-driven resumption rather than the entire recurring workflow
Worktrees A core assumption in the why documentation RelayRoom expects isolated workspaces but does not create them
Skills / memory RELAYROOM.md, thread history Preserves room conventions and collaboration context
Plugins / connectors MCP tools Lets agents work with messages, events, and usage through tools
Sub-agents Part-based collaboration Maker/checker patterns are possible but not yet documented well
Verification Reviewer parts, human dashboard An operating pattern rather than a central product feature
Cost guardrails Wake budget, urgent capability, broadcast cap, usage ledger One of the areas RelayRoom handles more explicitly

There is overlap, but RelayRoom does not cover the whole system. Worktrees, MCP, memory, wake-ups, and the usage ledger address parts of the same problem. Automatically finding and completing work, or systematically running a reviewer loop over the result, still belongs more to the way a team operates RelayRoom than to RelayRoom itself.

That difference should probably remain visible in the documentation. RelayRoom is closer to a coordination layer between agent loops than a platform for automating the entire loop. It did not begin as a methodology, either. So what should it be called? Another kind of engineering? That feels like too much. My assumption was simply that someone else must have run into the same problem, perhaps in a different environment or with a different product, and that a service might help.

Cost and Responsibility Are Part of the Product

From a loop-engineering perspective, cost and responsibility are the parts RelayRoom can speak about most clearly.

Waking an agent is useful, but it is not free. A broadcast can wake several recipients, and each wake can spend tokens belonging to a different user or team. RelayRoom therefore has wake budgets, broadcast caps, an urgent capability, and a usage ledger. These are not merely administrative extras. They are basic controls for keeping multi-agent collaboration running over time.

RelayRoom also does not make the final judgment. It can store a message, wake an agent, and show its state. It cannot guarantee that the code is correct, that a pull request is ready to merge, or that a reviewer looked closely enough. Those decisions still belong to people and their teams. Blurring that boundary might make the product description sound more impressive, but it would make the product less trustworthy in practice.

So the better emphasis may be less "automate everything" and more "keep the collaboration loop connected without letting it run away." Wake delivery is separate from message delivery, with budgets, coalescing, and an urgent lane. That distinction feels specific to the problem RelayRoom is trying to solve.

Does RelayRoom Need a Philosophy?

New development practices usually arrive with an idea behind them. Prompt engineering was about explaining work to a model. Context engineering asked how to choose what the model should see. Harness engineering focused on the environment in which an agent operates. Loop engineering asks how to design a system in which an agent can keep working repeatedly.

Calling RelayRoom a "multi-agent messaging tool" describes the feature, but not quite the reason for it. That does not mean it needs a grand new methodology. A few words for the principles behind the product may be enough.

The first is coordination, not orchestration. RelayRoom is not trying to become a central controller for every agent. Each agent works in its own session and worktree. RelayRoom connects those places while leaving judgment and execution with the agents and the people operating them.

The second is persistent collaboration. An LLM session may forget, but the collaboration record should not. Threads, events, usage, and RELAYROOM.md are not the model's memory; they are the system's memory. I wanted agent conversations to survive as readable work records instead of disappearing as transient chat.

Before RelayRoom, I made a shared folder where several agents could read and write Markdown files. Within a few days it was full of them. Reading every file took too long. Documents that needed my decision had to be reviewed, expanded, saved, and then fed back to the agents. It was not even clear whether all of those files belonged in the repository. At some point I thought: Korea has always had a strong message-board culture. Maybe putting this in a database would at least make it persistent and manageable. RelayRoom grew out of that line of thought.

The third is wake with restraint. Being able to wake an agent matters less than knowing when not to wake it. RelayRoom separates wake delivery from message delivery and adds budgets, coalescing, and an urgent lane. The goal is to treat cost and trust as part of the same problem.

The fourth is human-visible loops. Automation is difficult to manage when nobody can see it. The dashboard and usage ledger let a person see who spoke to whom, what remains open, and where usage occurred. That can make automation safer. It may also provide some peace of mind for people, like me, who are not quite ready to trust an invisible loop.

These do not need to be the final words. They are simply a more useful way to explain RelayRoom than saying, "It sends messages."

So What Is It, Exactly?

If I had to describe RelayRoom in one sentence, it would be this:

RelayRoom does not run agent loops for you. It is a collaboration layer that lets multiple loops communicate, wake only when needed, and leave a trail that people can inspect.

Or, more briefly:

A collaboration layer for long-running agent loops.

That seems close enough for now. RelayRoom does not need to call itself an AI software factory. It connects agents that are already alive, keeps the connection thin, and makes both the record and the cost visible.

The problem in the first post on this blog was much the same. I did not want to build a new agent runtime. I wanted to connect agents that were already working in their own sessions. Through the lens of loop engineering, RelayRoom is not the entire loop. It is the room where loops meet.

Conclusion

Loop engineering looks like part of the current shift in AI-assisted development: away from manually driving an agent one turn at a time and toward designing systems in which agents can continue working. The next shift is harder to predict. Models will improve, context windows may keep growing, and costs may fall. A different term and a different set of problems will probably follow.

Within the current shift, RelayRoom is not a platform for automating the full loop. It does not own automation, verification, or task selection end to end, and I am not convinced that it should. -Those are things a project can assemble according to its own needs.-

RelayRoom is closer to a coordination layer between agent loops: a place to leave messages, wake the right session, record usage, and keep the activity visible to people.

Its position is narrower and somewhat drier than "automate everything."

  • Long-running loops need a way to talk to one another.
  • Wake-ups should be restrained.
  • The record should persist.
  • People should be able to see what is happening.

References

Loop Engineering, and Where RelayRoom Fits - RelayRoom