Thinking · AI tooling

When the AI app works — and when it won't.

"It can't pull data from that report." That kind of moment isn't a failure of the AI or a setup mistake — it's a clue about how connected apps really work. Once you see it, the frustration makes sense, and the path to better AI gets clearer.

The reframe

A connector is a menu, not a master key.

When a chat app "connects" to a tool, it doesn't get free run of it. It gets a fixed list of things it's allowed to do.

01

It's a menu of actions

Look up a record, search, create, fetch history, summarize a call — each is its own button. The AI can press the buttons it has. It can't invent new ones. If the thing you want isn't a button, it improvises or comes back empty — and either way it feels like a miss.

02

True for every app

Email, CRM, calendar — every connector has its own menu. The menus differ; the rule is the same. It's why the same question can work in one tool and fail in another: the AI didn't change, the menu did.

03

The menu is the guardrail

A fixed list is what stops the AI from deleting records, mass-emailing customers, or reading data it shouldn't. The trade is flexibility for safety — and for anything holding customer data or financials, that's the right trade.

The mental shift: stop picturing the connector as "the AI talking to your system." Picture it as the AI ordering off a menu the system's team built. And every step is a choice the AI makes — which is why two near-identical requests can come back different. For exploring, that flexibility is the point. For repeat work, it's the variance you're trying to remove.

Two shapes of work

Same AI. Different jobs. Different tools.

Most "why didn't this work?" moments come from using one tool for the other's job.

Pattern 01 · Exploration

Open-ended, in the moment

Reach for a connected app.

You don't know in advance what you'll ask or what data you'll need. "What do I know about this account?" "Summarize my last call." "What's on my calendar?" Flexible, conversational, fast to set up — the menu is usually broad enough to handle it.

Pattern 02 · Execution

Repeating, precision work

Build a workflow.

Same job every week. The data must be exact, the format identical, the rules can't drift — the Friday pipeline report, the monthly health newsletter, a renewal-risk summary. A workflow pulls the exact data and applies the exact rules every time, using AI inside it for drafting and summarizing.

Where each one wins

Real tasks, sorted.

Most teams use the connected app for everything — and feel the friction when it's asked to do precision work it wasn't built for.

Reach for the connected app

"Catch me up on this account before my call."
Different account each time — the flexibility is the point.
"Draft a reply to this email."
One-off and conversational; you'll edit it anyway.
"Find the contact from last year's event."
Lookup work — searching is on the menu.

Build a workflow

The weekly pipeline or account-plan brief.
Same signals, same format, every time.
Deal-health scoring before commit calls.
Defined risk rules, applied identically each run.
An onboarding doc from the closed-won record.
A repeatable path, not a one-shot chat.

A simple test: could you draw the task as a flowchart before you start — the trigger, the data, the rules, the output? If yes, it's a workflow: build it once and it runs the same way every time. If every run is a little different and you don't know what you'll need until you're in it, that's exploration — and the connected app is exactly right.

The decision tree

Two questions sort any use case.

Answer honestly, not aspirationally — especially the first one.

Question 1

Will every run be different, exploring different data?

If every run explores something new and the path isn't fixed, you want a connected app — flexible, conversational, built for open-ended work. If the runs mostly repeat the same shape, you don't need an app; read on.

Question 2

Does any step need AI judgment to add real value?

If a step genuinely needs judgment — drafting, summarizing, or classifying — build a workflow with AI inside a defined path. If no step does, skip the AI: a plain workflow is faster, cheaper, and more predictable.

If a question is hard to answer, that's the signal — often one "use case" is hiding several inside it, or what looks like a connected-app job is really a workflow nobody has mapped yet.

Want help sorting your team's AI use?

A short working session is usually enough to draw the line between exploration and execution — and surface the few high-value workflows worth building first.