Someone in a Discord I lurk in posted last week about ripping out 40 Zapier zaps and replacing them with “a single paragraph of instructions to a browser agent.” I assumed they were exaggerating. So I tried it for a week. They weren’t.

The trick they had figured out, and that I’m slowly internalizing across maybe a dozen of my own experiments, is that workflow automation doesn’t actually need to be a graph of pretty boxes connected by webhooks and trigger conditions. It can just be a sequence of browser actions, one after the other, described in plain English to an agent that already lives in your tab.

Where this even comes from

Zapier and Make and n8n exist because APIs are messy and humans don’t want to write the glue between them. They abstract the messiness with pretty boxes you connect. But every box is a small contract: this app’s API has these endpoints, with these auth requirements, returning these schemas. And when the contract breaks, the box breaks. Or when you want a new box, someone has to build it.

A browser agent skips the contract entirely. It clicks, types, reads, scrolls. The same way you do. So a “workflow” just becomes whatever you’d do at the keyboard if you had infinite patience and a halfway decent memory.

A real chain I built last Tuesday

Take a chain I actually run. Every Tuesday morning I want to know which support tickets in our Linear instance have been tagged “billing” but haven’t been touched in 48 hours, and I want a draft email to the customer for each one. Pre-dassi this would have been a Zapier filter wired to a Linear API call wired to a delay node wired to a custom email template wired to a Gmail send action, and probably a Slack notification on top of all that, which I’d predictably ignore by week two.

The chain I now run looks like this, given as a single prompt:

  1. Open Linear in the active tab.
  2. Filter issues by label “billing”, status open, last updated more than 2 days ago.
  3. For each issue, open it, read the latest comment, and pull the customer email out of the description.
  4. Draft a Gmail reply (in the compose tab, don’t send) acknowledging the delay and asking a follow-up question based on the latest comment.
  5. List the draft IDs back to me with a one-line summary each.

The agent does it in about four minutes. I read the drafts, send the ones that look good, edit the rest. And no webhook ever fires. No API key gets rotated. And if Linear changes their UI tomorrow, the agent re-reads the screen and figures it out, which is something a Zapier integration absolutely cannot do without a developer fixing the connector first.

The mental model that helped

I kept failing at chains until I realized I was prompting like I was talking to GPT, not directing a worker. But browser action chains aren’t conversations. They’re shift instructions to someone smart enough to interpret intent but who still wants the steps numbered, the boundaries marked, and the failure modes spelled out before they start.

A few rules I converged on after a lot of broken runs:

  • Be explicit about state changes. “Save the draft, don’t send” is one I learned the hard way after sending three half-written emails to a customer named Greg.
  • Tell it where to read from and where to write to. “Get the data from the table on this page, paste it into the Sheet in tab 3” beats “summarize and save.”
  • Tell it when to stop. Open-ended chains drift. “Process the first 10 rows, then stop and report” is your friend.
  • Checkpoint anything irreversible. Pause before sending external messages, deleting anything, or hitting submit on a form that costs money.

Most of my chains are now ten or fifteen lines long. And they live as text snippets in a Notion page I keep open. When I want to run one, I paste it into the dassi side panel and walk away from my desk. If you want the basic single-step version first, How dassi Automates Your Browser Tasks walks through that.

What this is bad at

But I’m not pretending this is a Zapier killer for every situation. If you need a workflow that runs at 3am while your laptop is closed, this is not it. Browser agents need a browser, which means they need a session, which means they need you (or a machine pretending to be you) to be logged in somewhere. There is a category of automation, the unattended-server kind, where the old tools still win.

But that category is smaller than the marketing suggests. Most “automation” I see in the wild is a human triggering something once a day, then forgetting about it. For that case, chaining browser actions inside a tool that already sees your tabs is just less work, end to end. I wrote up a related angle in 40 MCP Tools and It Still Can’t Fill Out a Form, which goes deeper on why API-first tooling keeps coming up short.

When chains break

They do. And sometimes the agent misclicks. Sometimes a page loads slowly and it scrolls past what it needed. So you start over. Chains aren’t transactions.

One last thing

A friend asked what would happen at a chain’s halfway point if the agent went off script and started doing something dumb. You watch it happen, you hit stop, and you rewrite the prompt to be more specific about the part that failed. But after a couple of rewrites the chain stabilizes and runs the same way every time. Which, weirdly, is exactly what made me trust it.

Closer to a junior employee doing your weekly todo list than a CI pipeline. And mostly that’s fine.