2
3 Comments

How we learned to build autonomy that founders actually trust

When we started building MarketSquad, I assumed the hard part would be capability. Could an AI agent actually do marketing well enough that a bootstrapped founder would use it? That seemed like the real question.

I was completely wrong.

We spent our first month interviewing founders about autonomous marketing. I asked them technical questions about agents, capabilities, model routing, integration complexity. Most of them looked confused. Then one founder asked if they could stop the agent immediately if it spent the budget badly, and that question shifted everything I thought about the product.

We spent the next two hours talking about control, not capability. Every founder we talked to after that asked variations of the same thing. What's the kill switch? What if I want to approve things before they go live? What's the daily budget cap? Can I see exactly what the agent is going to do before it does it? If the agent makes a mistake, can I undo it today or is it stuck in some approval queue?

This wasn't anxiety about the feature. It was a completely rational concern, and they were right to feel it. If I give an autonomous AI agent access to my marketing accounts and ad budgets, I am trusting a machine to make financial decisions on my behalf. Most SaaS tools don't do that. Most SaaS tools show you what they'll do and wait for you to click a button. The founder's anxiety was actually just competent risk assessment.

So we rebuilt the product architecture around approval gating. Not as an afterthought, not as a privacy feature. As the core of how the agent operates. Every material action, every ad change, every budget adjustment, every account post, goes into an approval queue by default. The founder sees exactly what the agent proposes to do before it happens. They can reject it, edit it, or approve it. They can set a daily budget cap so the agent can't exceed it without approval. They can hit a kill switch that freezes the entire agent in fifteen seconds.

What surprised me was how much this changed founder perception of autonomy itself. When we shipped the approval gates, the language founders used shifted completely. Instead of saying "I'm nervous about giving an AI agent control of my marketing," they started saying "I can finally automate my marketing without worrying about it going sideways."

It's not that the approval gate makes the product safer. It's that it makes the founder's risk assessment tractable. They can't eliminate risk, but they can see it and manage it. That changes everything about whether someone will actually use autonomous agents in their business.

What we learned about trust

The real insight from those interviews wasn't about safety features. It was that founders who said "I don't trust AI with this" didn't actually mean they didn't trust AI. They meant they didn't trust something they can't see. They didn't trust unknown unknowns. They didn't trust a feature that runs while they sleep and might be making decisions they'd never have made themselves.

Once we made the agent's actions visible and stoppable, trust followed naturally. Founders started asking different questions like "Will it actually get this right?" instead of worrying and asking "What if it breaks my stuff?" Those are the questions we can actually answer with product.

The kill switch isn't a feature, it's a permission structure

Here's what I'd tell any founder building an agent product. The kill switch might look like a feature, but it's actually the permission structure your customer needs. You're asking someone to delegate decision-making to a machine. The kill switch is how you make that delegation conditional. "Yes, I authorize you to do this, but I reserve the right to stop it."

When we first shipped it, I thought maybe 20% of founders would use the kill switch regularly. In practice, we found most founders enable it and leave it there. They barely touch it. Just knowing it exists changes how they think about the agent. It's not "this AI is running my marketing while I'm away," it's "I'm delegating this task to an agent I can stop anytime."

Why this matters for any autonomous product

If you're building anything that makes decisions on behalf of your user, you should start with the kill switch, not the capability. Your users don't care about the percentile of your model. They care about whether they can stop it if it goes wrong, and this should be the first thing you build. Everything else, the agent's actual smarts, the integrations, the automation, flows from that foundation.

Founders aren't anxious about autonomous marketing. They're anxious about delegating financial decisions to something they don't control. Once you give them control back, autonomy stops being scary.

on August 26, 2026
  1. 2

    The approval-gating approach is the interesting part because it makes autonomy something founders can control rather than something they have to trust blindly. The kill switch and budget limits seem especially useful when the agent can directly affect spending or publish changes.

  2. 1

    Really interesting distinction between making autonomy controllable and proving it is actually behaving as intended.

    The approval gates, budget caps and kill switch give the operator control — but once the agent is running in production, how are you validating that those controls are actually effective across real runs?

    For example, are you independently sampling agent actions, approvals, overrides and resulting outcomes against the intended operating rules, or is that still handled through the same system that executes the agent?

    That second layer is something I’ve been working on with OpsWatch.

  3. 1

    Really interesting distinction between making autonomy controllable and proving it is actually behaving as intended.

    The approval gates, budget caps and kill switch give the operator control — but once the agent is running in production, how are you validating that those controls are actually effective across real runs?

    For example, are you independently sampling agent actions, approvals, overrides and resulting outcomes against the intended operating rules, or is that still handled through the same system that executes the agent?

    That second layer is something I’ve been working on with OpsWatch.