AgentClip: A Tool for Loop Engineering

The most interesting part of AI agents is not the model. It is the loop.

A prompt gets you an answer. A loop gets you ongoing work: read something new, compare it against everything you already know, decide if it matters, and surface it when it does. Without the loop, an agent is just a chatbot with a longer memory. With the loop, it becomes something that watches while you do other things.

This idea — loop engineering — has become one of the dominant threads in agent tooling this year. The conversation has shifted from “which model is best?” to “what does the loop actually do?” People are less interested in a one-shot answer and more interested in an agent that keeps running: planning, generating, evaluating, and deciding when to stop.

I built AgentClip as the inbox that triggers that loop.

What AgentClip Does

AgentClip has three pieces:

• Browser extension — select text on any page and clip it.
• Mobile app — share a link or paste text into AgentClip from iOS/Android.
• Agent interface — both MCP and REST, so local AI agents can read, search, and process everything I clip.

Clips go to Cloudflare Workers, are stored in D1, and are indexed for search. The agent does not need to know any of that. It calls search_clips or GET /clips/search and gets back what it needs.

The point is not to build a better bookmark manager. The point is to build an inbox that agents loop over.

From Storage to Inbox

Most clipping tools ask: “How do we help the user organize what they saved?”

That was never my problem. My problem was the opposite: I saved things and forgot to do anything with them. Read-later queues became graveyards. Bookmarks became folders I never opened. The bottleneck was not storage. It was processing.

AgentClip treats each clip as a trigger. A clip is not “something I might want later.” It is “something I want something done about.” That could mean summarize, compare, find related ideas, or just tell me if it conflicts with something I already believe.

The inbox is the interface. The agent is the worker. The loop is where the value is.

What the Loop Actually Does

The question everyone asks about loop engineering is: what does the loop actually do?

Here is what a typical AgentClip loop looks like on my machine. It is not abstract. It is a script that runs every morning and asks four concrete questions:

1. What did I clip in the last 24 hours?
2. For each new clip, what older clips seem related?
3. Does any new clip change or contradict something I saved before?
4. Write a short digest and save it as a Markdown file.

The output lands in my local notes directory as something like 2026-06-23-agentclip-ideas.md with a few sections:

• Summary of the new clip
• Older clips that seem related
• A tentative conclusion or open question
• Suggested next searches

That Markdown file becomes the trigger for the next loop. I point another local agent at it — often Claude Code or a local LLM — and ask it to expand the research, find gaps, or sketch an implementation. The first loop turns a raw clip into a structured note. The second loop turns the note into a design or a draft.

I keep each loop small on purpose. The first agent does not write code. The second agent does not browse the web. Each one has a narrow job, and AgentClip is the shared inbox they both read from.

Another loop runs when I start a coding session. It searches AgentClip for clips related to the current git branch name or recent file changes, then prints the top three matches. Before I write new code, the agent reminds me what I already read about the topic.

MCP and REST

MCP is the convenience layer. Claude Code, Cursor, or any MCP client can discover AgentClip and call it like a native tool. That is how I do ad-hoc exploration.

REST is the control layer. When I write my own watch script, it fetches clips through GET /clips and passes them to an LLM on my own terms. The LLM does not need to know AgentClip exists. It just receives the data and reasons about it.

I use both. MCP for interactive work. REST for scheduled loops.

How the Loop Ends

This is the part of loop engineering nobody talks about enough. If you do not design the end condition, the loop runs forever and bills forever.

My loops end in one of three ways:

• Time box — run for 15 minutes, then stop.
• Task limit — process the five most recent clips, then stop.
• Token budget — spend up to N tokens, then stop and wait for me.

The exact condition depends on the task. A daily summary loop gets a small budget. A deep research loop gets a larger one. The important thing is that the loop never runs open-ended. An infinite loop is not engineering. It is a bug.

Local-First

The storage is in Cloudflare, but the agents are local. That distinction matters to me.

The loops run on my Mac mini or laptop, usually inside tmux. They can call local tools, write local files, and cross-reference clips against code I have on disk. A cloud agent could not do that without me shipping everything outward.

Keeping the loop local also means I control when it runs, what models it uses, and when it stops. It is slower to set up than a managed agent, but the boundary is clear.

Architecture

Chrome Extension / Expo App
        │
        ▼
Cloudflare Workers (Hono)
        │
   ┌────┴────┐
   ▼         ▼
  D1      Vectorize
(metadata) (embeddings)
        │
        ▼
Local AI Agents via MCP + REST
        │
        ▼
Continuous loop: read → connect → surface

The browser extension captures the selected text, URL, and page title. The mobile app does the same through the share sheet. Both send the clip to Workers, where it is stored in D1 and indexed.

When an agent asks a question, Workers queries the index, fetches the corresponding rows from D1, and returns the result.

What the Agents See

AgentClip exposes two interfaces:

MCP tools:

• search_clips — search over all clips.
• get_clip — fetch a specific clip by ID.
• list_recent_clips — recent clips.
• add_clip — write a note back.

REST endpoints:

• GET /clips — list clips with filters.
• GET /clips/search — search clips.
• POST /clips — create a clip.

No agent sees everything at once. They ask. That keeps context windows reasonable and prevents the inbox from becoming noise.

Multiple Agents, One Inbox

I do not run one loop. I run several, each with a different model and purpose.

• Kimi handles broad research and idea expansion.
• Codex picks up clips that involve code, APIs, or infrastructure.
• Claude Code does deep local work, reading my codebase and pulling relevant context from AgentClip.
• Local LLM via llamafile runs the cheap loops: summarization, redundancy checks, and anything I do not want to send to the cloud.

They all read from the same inbox. Each one takes the clips it is good at and ignores the rest. This is cheaper and more flexible than asking one model to do everything.

What I Tried Before This

I wanted automatic processing of research and ideas, so I tried more autonomous agents — the kind that watch, learn, and act on their own. The premise is appealing: feed it clips, and let it decide what matters.

In practice, I found them hard to debug and harder to trust. When an agent decides on its own what to remember and what to do, you spend as much time managing the agent as you would have spent doing the work yourself.

Local coding agents with MCP — Claude Code, in particular — turned out to be a better fit. They are transparent: I can see what they read, what they call, and what they produce. They are controllable: I define the tools and the boundaries. And they compose well: I can route clips to them through AgentClip and let them decide whether to act.

That is why AgentClip stays simple. The loop is not the brain. The loop is the plumbing.

The Mobile Piece

Most interesting links reach me on my phone — Twitter, newsletters, chat apps. The mobile app is Expo + React Native with the same Workers endpoint and share sheet flow.

The share sheet integration matters because the moment I decide to “save this for later,” friction determines whether it actually happens. If I can send it to the agent inbox in two taps, it gets processed. If it requires opening another app and deciding where to put it, it does not.

What This Is Not

AgentClip is not a team knowledge base. It is not a replacement for Notion or a bookmark manager. It is a single-user inbox designed for local agents.

If multiple people need access, the design would change — permissions, workspaces, audit logs. That is a different product. This one is mine.

What Comes Next

The loop is still mostly reactive: agents process clips and surface them on a schedule. I want it to become more proactive — to notice that I am working on something and mention a connection without being prompted.

That requires the agent to have a sense of what I am doing, which is a harder problem. But the inbox, the retrieval layer, and both interfaces are now in place, so the rest is loop tuning.

Try It

AgentClip is open source:

• github.com/0xkaz/agentclip — Chrome extension + Cloudflare Workers + MCP server + REST API
• github.com/0xkaz/agentclip-mobile — Expo + React Native client

Both are early. The extension is usable. The mobile app is usable. The MCP server and REST API are stable enough that I run them in daily sessions across multiple agents.

If you also want your agents to keep working while you are not typing at them, the pattern is worth stealing.