Fundamental Pieces for Building Any Claw or Loop

"OpenClaw is fading. Loop engineering is the new thing!"
"Huh?"

I wanted to level up from Prompt Engineering to Loop Engineering. But I quickly realized that my prompt-engineering setup, raw Codex/Claude CLI, had two fundamental problems preventing it from becoming a true loop-engineering harness.

Limitations of Raw Agent CLI

1. Agent CLI is not effective when I am away from my computer.

• With Agent CLI, the agent waits for my prompt to decide what to do next. My output is capped by the hours I can sit at the keyboard.

2. Agents in CLI are brilliant, but they have no memory.

• Without memory of what happened and what agents did in the past, they are not capable of long stretches of work.

---

Because of these fundamental problems, a raw agent CLI cannot do end-to-end work. It can only do part of the work, under our instruction and while we are watching. When the check-ins, context, and next actions all live in our heads, we become the bottleneck.

To solve the above two problems, I primarily wanted two things:

OpenClaw solved this problem. I wanted to run OpenClaw for my engineering and research work, but it felt too large (18k+ files, 114 skill files) for my use.

To be effective for my requirements, agents needed to act on my behalf while I was away. Letting a huge harness run with broad access on my machine did not feel right, especially given the sensitive nature of my work.

---

I had two options:

1. Run a heavily sandboxed OpenClaw with limited access
   • This significantly reduced the usefulness.
2. Build my own OpenClaw
   • A simpler system I fully understand, so I can assess the risk and give it the appropriate permissions.

I started by using SeedBot. I loved it. SeedBot proved the harness could be tiny: a bash loop with file-based memory. Check out Huizi Mao’s SeedBot Blog to learn more. SeedBot gave me trust through simplicity, but it was missing the pieces I needed to scale: scopes, permissions, and concurrency.

---

So I set out to build my own harness with all these lessons in mind. I wanted the right skeleton to start with because, as I have learned, that naturally makes future build-out simpler.

I started building BeeLoop. The interesting part was that my independent redesign and solutions kept arriving at a few fundamental design pieces of OpenClaw. They are listed below.

The Four Fundamental Pieces of Any Effective Harness

Piece	Role
Always-listening socket	A perpetual process listens for events and invokes the right agent.
A Good Memory System	Markdown state files preserve work, preferences, and context.
Scoped Agents, for Access and Context	Agents get only the workspace and permissions they need.
Concurrency and Coordination	Parallel agents coordinate work instead of conflicting or duplicating effort.

These fundamental pieces transform agent CLIs into something that feels like a living entity: one that acts in the present, grounded in the past.

OpenClaw might fade out over time, but these four pieces are here to stay. The interfaces and implementations will change, but under the hood they all look similar to OpenClaw’s design.

Always-listening socket

In OpenClaw lingo, this is the gateway: the always-on central process. Its job is to listen for events and route them to the right agent.

The events might be Slack messages, cron ticks, CI runs, Slurm run completions, and so on. This gateway is what makes the harness eventful. It monitors CI status and dispatches to the right agents as needed, without someone watching.

OpenClaw’s gateway is written in TypeScript in more than 100k lines. In SeedBot, a very minimal version of this is written in 82 lines of bash script, which I found absolutely brilliant.

To be fair, OpenClaw’s gateway does a lot more, like managing agent memory and mapping each event to its session and workspace, potentially reducing token costs. However, this felt like an unnecessary engineering burden for my personal use.

A Good Memory System

This piece literally has no code. Memory is organized in plain English in Markdown files. However, the right design of memory files is crucial in making the agent feel stateful and determining whether memory retrieval is slow or fast.

There are two kinds of memory:

1. Long-term memory
   • This captures knowledge, facts, and user preferences the agent learns over time.
2. Working memory
   • Working memory, or state, is the sufficient context of what happened in the past to carry out the rest of the work. This includes the task summary, status, blockers, next steps, and so on.

When working memory is maintained well, a fresh agent invocation feels continuous. Context bloat and the need for compaction are minimized. The agent knows what the work is, what happened, and what to do next without us telling it.

Scoped Agents, for Access and Context

The gateway should route each event to the right agent for its trust level and context.

My direct messages can go to a privileged agent that acts on my behalf. A team Slack message should go to a team-scoped agent with access only to shared team resources. Public channels should wake restricted agents with limited tools and sandboxed execution.

A shared or public channel should never reach my privileged agent. That boundary has to be enforced by the harness, not by a line in AGENTS.md asking the agent to behave.

Workspace- and context-scoped agents are also better for cognition. A focused worker with the right repo, state, and tools usually performs better than a generalist agent carrying unrelated context.

Concurrency and Coordination

Once an agent can be woken by events, concurrency appears immediately.

A cron job can fire while the previous check is still running. A Slack follow-up can arrive while a worker is implementing a fix, and so on.

If every event related to a piece of work starts a fresh agent, agents will duplicate work, overwrite each other, or send incoherent replies.

The harness needs a concurrency protocol. This can be as simple as instructions for detecting active work, attaching new inputs to the existing task, and using locks while editing shared files.

Continuity and Concurrency

Working memory is how agents coordinate across time. Past agents leave behind unfinished work. Parallel agents need to know current state: who is working on what. So working memory should capture the past context for continuity and present state for handling concurrency.

Context and Permissions in OpenClaw

OpenClaw handles memory and concurrency by mapping each conversation or event to a session lane. Only one agent runs in a lane at a time.

The gateway does this routing job. It decides which lane an incoming message belongs to and routes it to the agent with the right memory, workspace, and permissions. A lot of OpenClaw’s complexity lives in this session resolution layer. This complexity looked unnecessary to me.

With BeeLoop I attempt to simplify the gateway: it stays thin, the input source defines the permission boundary, and a broader-scope generalist agent resolves context before delegating focused work to specialized agents.

Claws Vs Loops

Loop engineering is not new. It is just a term for how a well-engineered Claw operates.

By Claw, I mean any agent in a harness that is stateful and eventful, with most of the pieces sketched out above. Implementations can differ.

Here is my Slack chat transcript with BeeBot, my Claw:

This happened while I was hiking in Alaska. When I got back to work, the PR had already merged.

I just triggered. BeeBot did the work - end to end.

Under the hood, this was not one long chat session staying alive for days, but:

1. My Slack message was routed to BeeBot, my trusted agent.
2. BeeBot resolved the request into a task and launched a Model Optimizer workspace-scoped agent.
3. Worker agent performed feature dev workflow: create the branch, loop: plan - code - test, create PR, report back.
4. Follow-up Slack messages invoked a new BeeBot agent, which resolved the work and past status from working memory and launched a new worker to address the comment.
5. Worker agent performed feature dev workflow, again.
6. A follow-up Slack message invoked a new BeeBot, which set up a scheduled event to wake up another BeeBot on Monday at 5 AM.

It was a harness orchestrating many loops, setting monitors, scheduling events - as it was engineered to do. BeeBot was Loop Engineering, not me!

Loop Engineering crowd is going wild, inventing ever more complex, but hard-coded loops. Do such loops generalize to all work? I do not think so.

There is no universal loop that fits all work.
So lets build the Claws, who engineers the Loops!

Claude Tag

Once you see the pattern, Claude Tag looks like another harness built from the same primitives.

• A gateway listens to Slack channel messages.
• Each message can trigger a scoped agent for that channel, possibly with shared team filesystem access.

There is no magic there. I can ask BeeBot to build it for me:

Closing Notes

Once you understand the fundamental pieces of building an eventful and stateful agent harness, you can build your own — lean enough to trust, small enough to read end to end, agile enough to grow as new needs arrive, and customized so it’s actually useful to you.

This is Part 1 of a blog series about building BeeLoop, my personal agent harness.

Part 2: BeeLoop: My Loop That Engineers My Other Loops.

Check out BeeLoop on GitHub.