Here’s what nobody wants to talk about in the AI productivity space: most of these tools want your data, your credentials, and your permission to act on your behalf. And most of them are black boxes.
You connect your email. You connect your calendar. You hand over API keys. And then the tool does… something. Maybe it sends emails in your name. Maybe it schedules meetings. Maybe it summarizes conversations and stores those summaries on servers you don’t control.
I have a problem with this.
I’ve spent 20 years building trust with the people I work with.
I’m not going to outsource that trust to a system I can’t see inside.
The pilot metaphor
When I built Andy, I designed them around a simple principle: the pilot stays in the loop.
Andy can draft an email. They can’t send it.
Andy can suggest a follow-up. They can’t execute it.
Andy can prepare a meeting brief. They can’t cancel the meeting.
Every action that touches another human being requires my review. Every single one.
This isn’t a limitation.
It’s the design.
Because the moment an AI tool sends a bad email in your name, or schedules a meeting at the wrong time, or follows up with the wrong context, you lose trust. Efficiency is recoverable. Trust is not.
Once I had that principle clear, the infrastructure question answered itself.
Where it runs
Andy runs on my own accounts. My own devices. My own Claude API key.
I’m not routing my business communications through someone else’s servers.
When you build a JFDIBot system, it works the same way. Your accounts, your tools, your Claude subscription. The system is yours to own and inspect.
This matters for a reason beyond privacy: you can see exactly what it’s doing.
Every decision, every draft, every automation has a trail. You can audit it. You can adjust it. You can turn off anything that isn’t working.
Trust as a feature
This is what I built Andy to be: transparent, controllable, and respectful of the relationships I’ve spent years building.