The Agent Loop Is the New SaaS

← all writing

[ AGENTS · 2026-06-21 · 6 MIN ]

The Agent Loop Is the New SaaS

by Burak Emre Kabakcı

FIG_01 [ cover · agents ] © lobu v1

For a decade, running a company meant buying software for each job. A tool for sales, a tool for support, a tool for finance, another for the thing the last tool didn’t cover. You were not really buying software. You were buying business logic as a product, one vertical at a time.

That is starting to come apart, and the reason is how agents get built now. The people who build them have stopped talking about prompts and started talking about loops.

Peter Steinberger 🦞

@steipete

Here's your monthly reminder that you shouldn't be prompting coding agents anymore.

You should be designing loops that prompt your agents.

19K·Jun 7, 2026View on X ↗

Boris Cherny

@bcherny

We talk a lot about how important it is to set up self-verification loops. Especially in the age of powerful models that can run for long periods of time, self-verification is a key ingredient that enables the model to run for much longer, delivering a result that is closer to what you intended, so you can do more without having to constantly check in on Claude as it works.

3K·Jun 9, 2026View on X ↗

They are talking about coding agents, but the idea travels. An agent loop is simple: something happens, the model decides what to do, it does it, and the result feeds the next pass. Once you can build the loop, the loop is the thing you ship. And a loop that watches your data and acts on it is the same business logic a vertical SaaS used to sell you, except you build it once, on one backend, instead of renting ten tools that never share a memory.

That is the shift. The workflow layer above your systems of record, the part that used to be a separate tool per function, is turning into agent loops you build. Lobu is the backend you build them on.

What the loop actually looks like

++++

The operating loop

01Events stream in

webhooks + connectors, batched

stripepayment_failed· Acme

typeformlead.created

agentnote.created· Acme

sentryerror.spike

gmailreply· Globex

agentticket.opened

hubspotdeal.won

slackmention

stripepayment_failed· Acme

typeformlead.created

agentnote.created· Acme

sentryerror.spike

gmailreply· Globex

agentticket.opened

hubspotdeal.won

slackmention

02Written to the log

append-only · every event a row

event_idsource

a1f9…stripe

b2c4…sentry

c3d7…agent

entityAcme → at risk

03Watcher fires, agent acts

sandbox · your model · MCP toolsenterprise-churn-watch

StripeHubSpotSlack

each action emits an event:

note.createdticket.openedmessage.sent

←

every action is a new event, back into the stream

That is one trip around the loop. A payment fails on Acme, the enterprise-churn watcher you defined picks it up, the agent checks the account and drafts a recovery note, and that draft becomes a new event in the log. You define one thing: the watcher. Lobu runs the rest of the circle. Here is each piece.

Events come in two shapes

Push and pull. A webhook posts to Lobu and the payload lands in an append-only events log as a row: Stripe charged a card, a form was submitted, Sentry threw. Or a connector runs on a schedule and goes and gets the data itself, a bank feed, an inbox, a CRM.

Webhook events are stored by default, and you opt a source into search when you actually want it in memory instead of just on the ledger. Either way the trigger is something that happened, not someone remembering to ask.

You define the watcher, not the steps

A watcher is a standing goal, written once in config and applied to every matching event:

defineWatcher({

agent: revenue,

name: "Enterprise churn watch",

schedule: "*/10 * * * *", // runs every 10 minutes

prompt: `When an enterprise account (ARR > $25k) has a failed payment,

pull the account, draft a recovery note, and post it to #cs

for approval before anything goes out.`,

reaction: reactionFromFile("./recovery-note.reaction.ts"),

})

You are not scripting the steps. You say what to watch for, which model runs it, and where it should stop and ask a human. On its next run the agent reads the new stripe.invoice.payment_failed event, checks Acme against memory, and drafts the note. The reaction posts it to #cs and waits. When someone approves, it sends, and the run writes a recovery_note.sent event back to the log. That event is the audit trail, and it is also what the next watcher might pick up.

You write this once. It keeps applying to every account that matches, and you can read exactly what it did from the events it left behind.

The agent runs in a sandbox with real tools

The agent works in its own sandbox: a separate process with a network it can only reach on an allowlist you set, and no standing access to your systems. It reads the event, pulls what it needs from memory, and calls MCP tools to act: read a record, post a message, open a ticket.

The credentials behind those tools are swapped in at the edge, as the request leaves the box, so the agent uses real access it never actually holds. You decide which actions need approval, and every call lands in the same append-only log. That is what a small blast radius means here, concretely: no secrets in the worker, no network it was not given, explicit approval policy, and a full record of what it touched.

What it does with what it finds

Usually three things. It updates entities, which are the durable records for a customer, an account, a contract. It writes new events, which is how a correction or a decision joins the record without erasing what was there before. And it runs reaction scripts, the part where it actually acts: send the email, file the ticket, kick off the next job.

Those new events land back in the log. Another watcher might pick them up on the next pass. That is the loop closing on itself, which is the whole point of drawing it as a circle.

Your org chart, as loops

The Acme example is a revenue loop. The same shape covers the rest of the company, on the same backend.

A GTM-engineer agent watches new signups and enriches, scores, and routes them, the work people wire together from five point tools today. A marketing agent watches what shipped and what landed and drafts the post, the changelog, the follow-up. A finance agent watches the ledger, reconciles, flags variances, and preps the close. A support agent watches the queue and drafts replies grounded in the same customer memory the revenue agent writes to.

None of these has to be a product you buy. Each is a watcher and a loop you define, on shared memory, so the finance agent and the revenue agent are looking at the same Acme. That is the part a stack of separate tools struggles with: each owns a slice, and none of them owns the whole customer.

The memory is what makes it compound

A loop with no memory is a cron job with a model bolted on. It wakes up blank, guesses, and forgets.

In Lobu every agent in the org reads the same events log, so the watcher that ran an hour ago left something behind for the one running now. Facts get corrected by superseding the old event, not by deleting it, so the record stays honest and the current view stays clean. And it is per org, walled off from every other tenant on shared infrastructure. I wrote more about why this is a warehouse and not a notebook in Filesystem vs Database for Agent Memory.

The new SaaS is a loop you own

So the unit you ship moves. Instead of buying a tool per function, you decide what should wake each agent, what it can touch, which model runs it, and what it should remember, and you wire that once on one backend you run yourself. Lobu is open source, so the loop and the memory it builds stay on your machines. Vertical SaaS sold you someone else’s loop on someone else’s servers. This one is yours.

Start with the docs, or read how the memory layer works.

▪

‹ all writing Next: 002 — Shopify's Aquifer, in the Open ▸