No connector? Design the handoff.

The dream setup is an AI tool with a native connector to every platform you work in. The reality is that you regularly need to get work into a system your AI can't touch. The instinct at that point is to sigh and do the work manually. The better move is to treat the gap as a workflow design problem.

Here's a recent, concrete example, plus the general pattern I extracted from it.

The job

I needed to adapt an existing survey for an internal pilot of a new assessment tool, then build the adapted version in Microsoft Forms. Two distinct kinds of work hiding in one task: deciding what the survey should be, and clicking it into existence, question by question, in a web form builder.

Manual estimate for the whole thing: about two hours. And there's no MCP connector between Claude and Microsoft Forms, so no way to say "build this in Forms" and walk away.

MCP, for the unfamiliar, is the open standard that lets an AI model operate other software directly: read from it, write to it, act in it. When a connector exists, integration is nearly free. When one doesn't, people tend to assume the AI can't help with that part at all. That assumption is the mistake.

Split the thinking from the execution

The task divided cleanly into two phases with different needs.

Phase one, the thinking work. I brought the baseline survey and project context into Claude and iterated until the adapted survey was right: question types, wording, response scales, ordering. This phase needed my judgment in the loop, which is exactly what a chat interface is good at. Fast cycles, human taste, decisions on the record.

Phase two, the execution work. I asked Claude to write a detailed prompt for Claude for Chrome, the browser extension agent that can see and operate a real browser. The prompt specified the full question list, each question's type, the exact scale anchors, required-versus-optional settings, and what "done" looked like. I dropped it into the browser agent and stepped away.

Forty-five minutes later the form was built. No errors, no babysitting. My total active time across both phases: about 20 minutes.

Why the split works

The two phases fail differently, and that's the whole design.

Thinking work fails when it's under-specified and unreviewed, so it belongs where a human is in the loop by default. Execution work fails when instructions are ambiguous, so it belongs behind a specification precise enough to execute unattended. A browser agent asked to design a survey while building it would be slow and wobbly. A browser agent handed an exact spec is a machine following a checklist, which is a thing machines are good at.

The connective tissue is the handoff artifact: one AI writing the operating instructions for another AI's tool. I didn't write the browser prompt myself, because the chat thread that had just finished designing the survey already held every detail the prompt needed. It's the same principle I wrote about in the handoff-prompt pattern for long threads: distilled context, moved to where the work happens.

When to build the connector instead

One honest caveat. This was a roughly one-time task, and the pattern above is a one-time-task pattern. If I were building surveys in Forms every week, I'd invest differently: probably a small custom MCP server or an API script, so the execution step becomes a tool call instead of a 45-minute browser session.

The frequency math is the decision rule. Occasional task, no connector: design a handoff. Recurring task, no connector: build the connector, or at least a script. The failure mode to avoid is the middle path, where you do the same "one-off" manual workaround every month and never notice it compounding.

The takeaway

A missing integration is not a missing capability. Separate the work that needs your judgment from the work that needs reliable hands, give the hands a specification instead of a conversation, and let one AI write the instructions for the other. The gap between your tools is just another thing you can design across.