Be your own connector: feeding a sandboxed AI what it can't reach

Overview

In June 2026 Glean’s Work AI Index — a survey of 6,000 workers, 1,500 of them in Australia — put a number on a tax most people feel but never name: 6.4 hours a week spent “botsitting,” the unglamorous work of making AI usable, part of it feeding the tool context it couldn’t get for itself. That tax falls hardest on a sandboxed assistant — the kind your employer walls off so it can’t open your files, query a system, or pull a live document. If the tool can’t reach anything, then everything it knows about your task, you put there. So the skill worth building isn’t a sharper prompt. It’s feeding a blind tool well.

The content

The obvious read is that a sandboxed tool is just a weaker version of a connected one — same assistant, fewer plugs, so you settle for slightly less. That’s not quite it. A connected tool fetches what it needs and can quietly fill gaps from your live systems; a sandboxed one can’t, and — here’s the part that bites — it won’t tell you when it’s missing something. It answers from whatever you gave it, with the same confidence either way.

Which makes you the connector. On a walled tool, the job a plug-in would have done — pulling in the current, complete, correctly scoped source — falls to you, by hand, every time. Two things decide whether that works.

Currency. A connector reads the live source, so it sees today’s version. A snapshot you paste is frozen the moment you copy it, and the tool has no way to know the real document has moved on. If the number changed yesterday, a sandboxed tool will reason confidently from the old one. Completeness. A connector can range across a whole drive; you’re handing over a single document, and the tool treats whatever you paste as the entire record. Leave out the exception buried on page 12 and the answer won’t hedge — it will be wrong and sound right.

So before you trust a sandboxed answer, run the test a connector would have passed for you: is this the current version, and is anything that bears on the question sitting in a document I didn’t hand over? The tool can’t ask that. You have to.

Try it

Pick a real task you’d give your walled assistant today, but before you accept its answer, make it show you the holes:

Before you answer, list what you're missing: the documents, figures, or
context you're assuming, or that would change your answer if you had them.
Then answer — and flag which parts rest on something I didn't give you.

Where it breaks: if it names things you didn’t provide — a current figure, a policy you forgot to paste — that’s your gap to close, not its failure. A connected tool would have pulled them in; a sandboxed one just showed you they were missing. Feed those in and ask again, rather than shipping the first answer.

Additional reading

• The Work AI Index 2026 — Glean Work AI Institute, 10 June 2026. The “botsitting” finding — 6.4 hours a week making AI usable — drawn from 6,000 workers (1,500 in Australia), surveyed December 2025–January 2026.
• “Botsitting”: The AI time-savings killer only governance can stop — CIO, 26 June 2026. Where the integration-layer point comes from: “when AI tools don’t have access to accurate data… employees become the integration layer that re-explains a project to every tool and fixes what breaks.”

Editor’s note

The mistakes that hurt in my real work are rarely about reasoning. What worries me are the things I don’t know. A sandboxed tool has the same blind spot, except it can’t go looking for the missing piece the way I can. For example, ask it to advise on positions in a contract based on a guidance document, and it may confidently treat a mutual obligation as acceptable simply because neither party assumes an obligation not held by the other. Answers are often only as complete as the context the tool is fed, and assumptions a model makes beyond that are particularly dangerous for knowledge workers.