Key takeaways: The risk of an AI agent isn't that it's dumb. It's that it's fast. A wrong write to your CRM at machine speed is a bad afternoon. Bob's advantage is that the five controls below are not a security slide: reads keep moving, sensitive writes pause in Slack, standing permission can be granted and revoked in Slack, larger jobs get a cost estimate, completed work gets a receipt, and every task runs in an isolated sandbox.
The receipt under every finished run, copied verbatim from a production run. Ask “what ran this week” and Bob adds them up.
The failure mode nobody demos
Every AI agent demo shows the happy path: ask for the report, get the report. Nobody demos the day the agent misreads an instruction and updates 40 CRM records with the wrong close date, or emails a customer list it shouldn't have. Those aren't hypotheticals. They're the documented failure modes of this product category, in public case studies, today.
The answer isn't "better AI." Models will keep improving and will keep occasionally being wrong, the way employees keep occasionally being wrong. The answer is the same one businesses figured out for people: controls proportionate to the blast radius.
- Writes pause for a human, by default. Reading your pipeline is low-stakes. Changing it isn't. Bob lets reads run, then pauses sensitive external writes with Approve, Always allow, and Deny in the Slack thread. An Always allow is bound to the action or automation that earned it, and
/bob grantslists and revokes standing access without sending anyone to a settings portal. The default is the important part. Opt-in safety isn't safety. - The ask is readable. An approval request has to be something a busy human can evaluate in five seconds. Bob names the app and the proposed action in plain language, with the exact operation available for review. "Found 3 invoices more than 30 days overdue; approving sends each customer a reminder email." If your current tool shows you a JSON blob and calls that informed consent, it isn't.
- The important decisions stay visible. Approval requests, decisions, and denials live in the Slack thread beside the work. The people already collaborating there can decide, and a denial ends the action instead of becoming a suggestion for the agent to argue with.
- Spend is capped and receipted. Bob estimates larger or unattended jobs before they run. Every completed run ends with total credits, duration, and tool-call count, and the workspace has a monthly cap with a warning before the hard stop. Connecting an app is refunded, and a rerun is free when Bob missed the mark. An agent that can spend without a ceiling or explain the bill only at month-end is a liability with an API key.
- Execution is sandboxed. Each of Bob's tasks runs in its own isolated, disposable sandbox, torn down when the run ends. The agent gets a computer; it doesn't get your computer.
The test
Ask your vendor, any vendor including us, to show you all five in a live workspace, not a slide. The ones who have them will love the question.
FAQ
Doesn't approval friction defeat the point of automation?
No. The point is leverage, not absence of humans. Most reads and routine writes run unattended; the gates catch the 5% with real blast radius. You spend seconds approving, not hours doing.
Can we change which tools need approval?
Yes. Use Always allow on the exact action or automation you trust, then use /bob grants in Slack to see or revoke that standing access. Sensitive actions can remain gated while proven, narrow work runs without nagging the team.
What about prompt injection from web content?
Bob treats fetched content as data, not instructions, records where automated work originated, runs in an isolated sandbox, and keeps sensitive writes behind the human gate. Standing permission from one email address, webhook, or action does not become blanket permission for everything else. Defense in depth, not vibes.