I once tested a tool called Alfred AI to triage and draft my emails, and it was atrocious. I spent more time cleaning up its mess than I would have spent just writing the emails myself.

Connect Business Tools AI: Fix the Workflow First

Alfred AI Was Atrocious, and the Tool Wasn't Really the Problem

Alfred AI was supposed to sort my inbox and draft replies so I could move faster through email. Instead, it would constantly muddle who was corresponding in the email chain. My drafted replies would talk about things as if I were the other person, referencing their own points back at them as if I'd said them. It wasn't a small glitch either; it was a structural confusion baked into every draft it produced.

Then there was the signature problem. All the links in my email signature got blown out, the full raw URLs spilling out instead of clean formatted text. That's a basic markdown formatting issue, the kind of thing that tells you something is functionally off "under the hood."

Between the identity confusion and the broken formatting, fixing what Alfred AI produced took longer than doing the emails myself. And that, in my experience, is what people actually mean when they say "AI tools don't work." It's rarely that the AI is incapable. It's that before you connect business tools, the AI depends on being set up to use properly, and very few platforms and builders take the time to do that.

The Thin Intelligence Layer Nobody Builds

After I started building my own systems, I went back and looked at what was actually wrong with something like Alfred AI, and it wasn't the tool itself. The connectivity was fine. It was plugged into Gmail, reading the inbox, generating drafts on schedule. All the plumbing worked. But what it was missing was a thin intelligence layer. Somebody had plugged in a base model, probably Claude or ChatGPT, and just let it run without giving it much direction underneath. No matter what model is used, these systems will always need a governing prompt: the instruction set that tells the model who it's speaking as, how to interpret a conversation thread, what tone to hold, and what never to do. Without that, the model is guessing at all of it every single time, and it will pretty quickly guess wrong, like assuming I was the person I was replying to.

This is a diagnosis I keep running into with client systems too, and I've written about this from the builder's side in more depth if you want the longer version of how I think about it. But the short version is this: a governing prompt and governing system underneath a tool is the difference between something that actually works and something that technically runs.

How I Diagnose a Tool Problem vs a Process Problem

When something isn't working, I don't start by blaming the AI. I start by checking connectivity and integration first. Is it actually reading the right inbox, the right database, the right calendar? With Alfred AI, that part checked out. The tool plugged into Gmail and the connectivity was good.

So then I look at what's underneath the connection. Is there a real governing prompt directing the model, or is it just a base model plugged in raw, with no instruction beyond the platform's generic defaults? That second scenario is what I run into constantly, and when you connect business tools, the AI still has to know what to do once it's plugged in. Connection alone doesn't get you there.

Here's the thing worth conceding: a tool being connected and functional on paper, meaning the login works, the permissions are granted, and the sync runs on schedule, doesn't mean it's actually working. Most failures I've diagnosed aren't the tool itself. They're a data issue, or a thin-wrapper issue where nobody built the layer of judgment that should sit between the connection and the output.

Clean Data Is the Foundation, Not an Afterthought

I built a system for a client recently that took his original client database and cycled it through a warm outreach email automation. The idea was simple: read the database, pull relevant details, and then customize outreach emails so they get through Gmail's native inbox filtering.

The data he gave me to start was not clean. It required quite a bit of tidying up before the system could actually use it. That meant making sure people's information was sitting in the fields where it belonged, names in name fields, company details in company fields, and pulling out the irrelevant clutter that had accumulated in the wrong places over years of manual entry.

Once it was fed clean data for AI workflows to actually run on, it functioned exactly as it was supposed to. It read the database correctly, and it wrote customized outreach that reflected the right person and the right context. Nothing about the underlying system changed between the messy version and the clean version. The only variable was the data going in.

This is the construction-adjacent point I keep coming back to. You don't finish a room before the foundation is poured. You can have the best framing crew and the best finish carpenter in the business, but if the ground underneath is uneven, none of it holds. Data is the same. No governing prompt, however well written, fixes bad inputs.

What Actually Working Looks Like Once It's Fixed

Compare that to where I started with Alfred AI. A system that's actually set up right reads the data correctly, writes in the right voice, and doesn't hand you a pile of cleanup work at the end. It knows who's who in a conversation. It formats a signature link the way it's supposed to look. Small things, but they're the difference between a tool that saves time and one that costs it.

None of that comes from a smarter model. The conversational models didn't get that much better between my Alfred AI experience and the systems I build now. What changed is the scaffolding around the model, the governing prompt and governing system doing the actual directing, and the data underneath being clean enough to work with.

There's an ownership piece to this too. A properly built governing prompt is part of what a client owns when I build them a system, not a feature buried inside someone else's subscription that can change or disappear on their pricing whim. When you connect business tools to AI in your actual workflow the right way, you're building infrastructure that's yours.

Fix the Workflow, Then Let the Tool Do Its Job

If you've had your own Alfred AI moment- some tool you tried that created more work than it solved and you quietly stopped using it- that's a reasonable reaction. I did the same thing. Nobody keeps fighting with software that makes their day longer.

But before writing off AI entirely, it's worth asking whether the tool failed or whether the setup underneath it was ever built properly in the first place. In my experience, it's almost always the second one. If you want to talk through auditing something you've already tried, or building a system with a proper governing layer and clean data from day one, I'm happy to have that conversation. You can also look at the systems I build to get a sense of what that actually looks like in practice.