The Agent Loop Is the New SaaS - Lobu Blog<br>agents architecture loops saas

Jun 20, 2026

TL;DR: The workflow layer above your systems of record, the part you used to buy a tool for, is becoming agent loops you build. A loop that watches your data and acts is that business logic, built once on one backend with shared memory instead of rented across ten tools that never talk. Lobu is where you build it.

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 🦞Verified<br>@steipete

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

You should be designing loops that prompt your agents.<br>Likes19K·Jun 7, 2026View on X ↗

Boris ChernyVerified<br>@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.<br>Likes3K·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

Events stream in<br>webhooks + connectors, batchedstripepayment_failed· Acme<br>typeformlead.created<br>agentnote.created· Acme<br>sentryerror.spike<br>gmailreply· Globex<br>agentticket.opened<br>hubspotdeal.won<br>slackmention<br>stripepayment_failed· Acme<br>typeformlead.created<br>agentnote.created· Acme<br>sentryerror.spike<br>gmailreply· Globex<br>agentticket.opened<br>hubspotdeal.won<br>slackmention

Written to the log<br>append-only · every event a rowevent_idsource<br>a1f9…stripe<br>b2c4…sentry<br>c3d7…agent

entityAcme → at risk

Watcher fires, agent acts<br>sandbox · your model · MCP toolsenterprise-churn-watchStripeHubSpotSlack<br>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"),

})

$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...