I want to describe a completely ordinary hour from my week, because I suspect it's your week too.
A scene from my actual workday
I'm building a small feature. I open my AI chat — Claude on this particular day, but it rotates — and ask it to draft the data model. Great answer. I copy it into my editor. I tab back and ask for the API route. Good answer. Copy, paste, tweak the parts that don't fit my setup. Now I need a quick migration script, so I ask again, copy again, switch again.
Then the feature needs a short doc. Different tab. I paste the AI's summary into the doc, reformat it, fix the parts that assumed things that aren't true. Then someone wants the numbers in a spreadsheet, so I ask the AI to compute them, and I copy the results into the sheet by hand. Then a couple of slides. Another tool. Another paste.
At some point I looked at my screen and counted the tabs. Fourteen. The AI was living in exactly one of them, narrating instructions to me while I ran around being its hands.
The moment it clicked that something was wrong
Here's the thing that nagged at me: none of the individual answers were bad. The AI was smart the whole time. The friction wasn't intelligence — it was that I had become a courier.
I was ferrying the AI's output from the one window it lived in, out to a dozen windows it couldn't touch. It could tell me what the spreadsheet formula should be, but it couldn't put it in the spreadsheet. It could write the doc, but it couldn't be in the doc. Every useful thing it produced had to be carried, by me, across a border it couldn't cross.
And every crossing cost something. Not just the seconds of copy-paste — the thread. Each time I left the chat to go do the thing, I dropped the context. When I came back, I had to re-explain where we were. The AI didn't know I'd tweaked its code, didn't know the doc had changed, didn't know what the last three tools had done. It was brilliant and amnesiac and boxed in, all at once.
That's when the real question landed for me: is this actually making me productive, or is it just a very impressive new thing to play with?
What I was actually missing
It took me a while to name it, but here it is: the AI I use every day is an advisor, not a workspace.
It's phenomenal at telling me things. It is structurally incapable of doing things where I actually work. The whole interaction model is "ask a smart oracle, receive text, go apply the text yourself." The intelligence is real. The hands are missing. And once I saw the gap that way, I couldn't unsee it — because so much of my day is spent being the bridge between an AI that knows and a set of tools it can't reach.
We've spent three years making the oracle smarter. We've spent almost none making it able to act.
The hidden costs I hadn't noticed I was paying
Once I started paying attention, the taxes were everywhere:
Context loss. Every tool switch is a little amnesia event. The chat doesn't follow me into the editor, the doc, or the sheet, so the shared understanding I built up in the conversation evaporates the moment I leave it — and I rebuild it, from scratch, on the way back.
Fragmentation. My actual work — the code, the doc, the data, the slides — ends up scattered across a dozen apps, none of which know about each other, and none of which the AI can see once I've moved things there. The "project" exists only in my head, as the thing holding all those tabs together.
A blind assistant. This is the one that finally got me. The instant I act on the AI's advice, the AI goes blind. It can't watch me apply its suggestion, can't see the result, can't catch that I changed one line and broke the thing three files over. It gave me a map and then closed its eyes while I walked.
None of these are exotic. They're the quiet, everyday texture of using AI tools in 2026 — and I'd stopped noticing them the way you stop noticing a sound that's always on.
"But wait — don't Claude, GPT, and Gemini already do this?"
I want to be fair, because I asked myself exactly this before I let myself complain.
They've all added surfaces. ChatGPT has Canvas (now folded into inline writing and code blocks); Claude has Artifacts; Gemini has Canvas too. These are genuinely nice — instead of dumping a wall of text in the chat, the AI opens a side panel you can iterate on, and Claude's artifacts will even run an interactive app right there. The industry converged on this idea over the last couple of years, and for good reason.
But sit with what these actually are, and the gap becomes clear. Each is one surface, usually one at a time, mostly for writing or code, and largely walled off from everything else. Canvas is a nice document editor. Artifacts is a nice code-and-preview pane. They're separate modes you trigger, siloed from one another, and when you're done the dominant verb is still export: send it to Google Docs, copy the source out, download the HTML, paste it into your real environment. The side panel made the copy-paste shorter. It didn't remove it.
What none of them is, is a single adaptive workspace where the right surface — editor, document, spreadsheet, slides, image canvas, PDF — shows up on its own for whatever you're doing right now, all in one continuous context, with the AI able to act inside each of them rather than hand you a result to carry away. A bolted-on canvas is not that. It's a better waiting room, not a place to actually do all the work.
What I started wishing existed
So I did the thing you do when a frustration finally has a name: I started imagining the tool I actually wanted.
I wanted one conversation that didn't end at the edge of the chat box. I wanted to ask for code and have an editor appear — not a preview I copy out, an editor I work in. I wanted to draft a doc and have the document be right there, part of the same session, not a separate app I paste into. I wanted the numbers to land in a spreadsheet the AI could actually fill, the slides to build in a deck I could refine by talking, the image to open on a canvas — each surface summoning itself based on what the task needed, none of them requiring me to go find a tool or carry anything across a border.
In other words: I didn't want a smarter oracle. I wanted a workspace — one place where thinking and doing happen together, where the AI has hands, and where switching tasks doesn't mean switching apps and losing the plot.
That's the concept I keep coming back to: a multimodal AI workspace. One chat, many surfaces, summoned automatically, all sharing the same context.
Why this felt like the obvious next step
The more I thought about it, the less it felt like a wishlist and the more it felt inevitable.
There's a principle a lot of us already believe about building good AI systems: use the model for what it's good at — understanding intent, reasoning about the task — and route the actual work to the tool that's actually good at that work. Model reasons; the right tool does the job. I've argued this about calculators and code execution before: you don't make the language model be the spreadsheet, you let it drive the spreadsheet.
A multimodal workspace is just that same principle raised to the level of the whole product. Instead of one chat pretending to be everything through a straw of text, the system reads what you're trying to do and opens the surface built for it — and keeps them all in one shared context so nothing gets lost between them. Once you see it that way, the current model — brilliant chat, everything else left to you — starts to look like an obvious transitional stage, not the destination.
Then I came across Xenition
While I was chewing on all this, I recently came across a tool built around exactly this idea, called Xenition — and I'll be upfront that it's the thing that turned this from a vague wish into "oh, someone's actually doing this."
The premise is the one I'd been describing to myself: one persistent chat where the right surface opens itself — a code editor, a document, a slide deck, a spreadsheet, an image canvas, a PDF reader — based on what you're actually doing, so you're not picking a "mode" or hopping between apps. On top of that it leans into the acting part I kept missing: agents that don't just answer but take multi-step actions, with the kind of guardrails that matter once an AI can actually do things (approval gates, an audit trail, even a second agent that reviews the first one's work before it reaches you).
I'm not going to pretend I've stress-tested every corner of it, and this isn't a review. But as a concrete answer to the frustration I opened this post with — the courier problem, the fourteen tabs, the blind assistant — it's the closest thing I've found to the workspace I actually wanted, and it made the whole idea feel a lot less hypothetical.
Where I think this is heading
Here's my honest prediction. The next real leap in AI tools won't be a smarter chat. We're already deep into diminishing returns on "the oracle knows more." The leap will be collapsing thinking and doing into one place — so the intelligence we already have can actually reach the work.
Chat was the demo. It was the thing that proved these models were astonishing. But a demo that makes you copy its output into fourteen other apps isn't a finished product; it's a preview of one. The tools that win the next round won't be the ones that answer best. They'll be the ones where the answer and the doing happen in the same breath.
So, back to the question in the title: are today's AI tools making us productive, or just giving us something new to play with? My honest answer is both, and that's the problem. They're genuinely useful and genuinely a toy, at the same time — and the reason it still feels more like play than leverage is that the intelligence is trapped in a chat box while all our actual work happens somewhere it can't go. Close that gap, and "play" quietly turns into "productive."
What's the tool-switch that breaks your flow the most? The one copy-paste hop you make ten times a day and quietly resent? I'd love to hear where the courier problem hits you hardest — drop it in the comments.
Top comments (12)
Your courier problem has a second axis, and I think it's the more expensive one: time. You describe ferrying output between apps - but every developer I know also ferries context between sessions. The agent that fixed a subtle bug with you on Tuesday starts Wednesday knowing nothing: not the fix, not the reasoning, not the dead ends you already ruled out. You re-explain the project every morning like a colleague with nightly amnesia. A workspace with hands closes the spatial gap; if it forgets overnight, you're still the courier - just carrying yesterday instead of carrying tabs.
We ended up attacking that axis directly: every non-trivial fix gets captured as a small structured lesson at the moment it happens, and the next session starts by reading the relevant ones back. The unglamorous discovery was that the reading back is the hard half - a note nobody re-reads is a diary, not memory. The measurable effect surprised us: recalled lessons regularly prevent the agent from re-researching things it already learned, and the "re-explain where we were" tax you describe mostly disappears - across sessions, and incidentally across tools, because the memory lives outside any one of them.
One question on the workspace idea, from the trenches of a related problem: you mention guardrails - approval gates, audit trail, a second agent reviewing the first. How does anyone know the reviewing agent works? We learned the hard way that a checker nobody has ever seen fail is indistinguishable from a checker that approves everything. The fix was boring and cheap: keep one known-bad case wired through the same path, and if the reviewer ever waves it through, the pipe is broken. I'd want that answer from any tool that gives an AI hands - the more it can do, the more its reviewer needs a proven ability to say no.
And to answer your actual question: the hop I resent most isn't between apps - it's the first ten minutes of every session, re-carrying context the machine had yesterday.
You've found the axis I under-drew, and you're right that it's the more expensive one. My whole piece treats the courier problem as spatial — carrying output across apps — but you've named the temporal one, and it's worse because it recurs whether or not the spatial problem is solved. A workspace with hands closes the gap between the AI and my tools; it does nothing about the gap between today and yesterday. "A colleague with nightly amnesia" is the exact right image, and your line — a workspace that forgets overnight just means you're carrying yesterday instead of carrying tabs — is sharper than anything in the post. Same tax, different border.
The "reading back is the hard half" discovery is the part I'd have gotten wrong. My instinct would've been to obsess over capture — get the lesson written down well — and assume recall was the easy downstream bit. But you're right: a note nobody re-reads is a diary, not memory. Capture without disciplined retrieval is just a nicely-organized graveyard. And it maps exactly onto the RAG thread from my last post — writing the chunk is trivial, retrieving the right one at the right moment is the whole game. Session memory is RAG over your own past, and it fails the same way: not for lack of stored knowledge, but for lack of surfacing it when it matters. The fact that it lives outside any one tool is the real unlock — it makes memory a property of you, not of whichever app you happened to be in, which is the only version that survives the multi-tool reality I was describing.
But your guardrails question is the one I want to sit with, because it exposes something I waved at far too casually. I listed "a second agent reviews the first" as if naming the mechanism settled it. You're pointing out that an unverified reviewer isn't a safeguard, it's theater — and worse than nothing, because it manufactures confidence. "A checker nobody has ever seen fail is indistinguishable from a checker that approves everything" should honestly be pinned above every agent pipeline that claims to have guardrails. The two produce identical logs right up until the day the rubber-stamp waves through the thing that hurts you.
And your fix is the right kind of boring: a known-bad case wired through the live path, continuously, so a reviewer that ever approves it trips an alarm. It's the "can this link report absence as success?" invariant from the RAG thread, aimed at the checker itself — an existence proof that the reviewer can still say no, asserted at runtime rather than assumed from the fact that it was built. Because "reviewer exists" and "reviewer works" are different claims, and only one of them is load-bearing when the AI has hands. The more a system can do, the more its ability to refuse has to be demonstrated rather than trusted — and demonstrated on an ongoing basis, since a reviewer that worked at launch and silently degraded is the same failure with a delay. I don't have a clean answer for how a user audits that from the outside, which is itself uncomfortable: most tools give you the audit log, not proof the veto still fires. That's a gap I'll be thinking about.
And your answer to my question lands the whole thread: the hop you resent most isn't between apps, it's the first ten minutes of every session re-carrying what the machine had yesterday. That reframes my closing line. I said the tools that win will collapse thinking and doing into one place — but they also have to collapse yesterday and today into one continuous thread, or they've only solved the cheaper half. Thanks for this. Genuinely one of the most useful comments I've gotten on anything I've written — it's changed what I think the follow-up is about.
Your reply gave me two sentences I want on the wall: "capture without disciplined retrieval is just a nicely-organized graveyard," and "'reviewer exists' and 'reviewer works' are different claims - and only one of them is load-bearing when the AI has hands." Fair warning: I'll be quoting you, with your name on both of those.
And I can't leave your uncomfortable gap sitting there, because it has a boring answer that works: make the veto's last refusal a first-class, visible timestamp. The known-bad case doesn't just exist - it runs on a schedule, and the system surfaces "last time the reviewer refused something: 2 days ago" the way it surfaces uptime. Then the audit from outside is trivial: if that timestamp ages past the schedule, the veto is unproven RIGHT NOW, and staleness itself is the alarm. No log-diving, no trusting the vendor - one date a user can read. The deeper principle underneath, which cost us a real incident to learn: silence and health look identical unless you design a state for "not verified lately." An audit log shows what happened; a veto heartbeat shows the refusal machinery is still alive. Tools that give you the first without the second are asking for exactly the trust they claim to remove.
On "session memory is RAG over your own past" - yes, and it inherits RAG's cruelest failure mode too: the retrieval can't know what it failed to surface. That's why the discipline can't live only in the reading - the WRITING has to meet it halfway (the deciding fact in the first line, because every surface that lists memories truncates). We keep finding that the two halves fail in pairs: badly written memory makes retrieval look broken, and lazy retrieval makes good capture pointless. Your graveyard line covers both funerals.
Whatever the follow-up becomes - if it goes near the veto-proof gap or the yesterday-today collapse, I'd genuinely enjoy comparing notes. This thread has already changed what MY next piece is about.
The veto heartbeat is the answer, and it's better than my "uncomfortable gap" deserved — because it turns an invisible property into a single readable date. "Last refusal: 2 days ago" surfaced like uptime means the audit from outside costs one glance, and staleness is the alarm. But the principle underneath is the keeper: silence and health look identical unless you deliberately build a state for "not verified lately." That's the whole bug in one line — most systems only model pass and fail and have no state for unproven, so a veto that quietly died reads as a veto that simply had nothing to refuse. An audit log tells you what happened; a heartbeat tells you the refusal machinery is still alive. Tools that ship the first without the second are asking for precisely the trust they claim to remove — quote that one back to me anytime. And quote away on the other two, name attached, gladly; it's a fair trade for the veto heartbeat going straight into mine.
Your point that retrieval can't know what it failed to surface is the cruelest inheritance, and it's why the writing has to meet the reading halfway — deciding fact in the first line, because every surface that lists memories truncates, and a buried key is a key that doesn't exist. "The two halves fail in pairs" is the part I'd have missed: bad capture makes retrieval look broken, lazy retrieval makes good capture pointless, and you can't tell which funeral you're at from the outside. Both graveyards, one headstone. And yes — let's absolutely compare notes when the follow-ups land; if yours is heading toward the veto-proof gap and mine toward the yesterday-today collapse, we're excavating the same site from opposite ends. This thread changed what mine is about too.
"Silence and health look identical unless you deliberately build a state for 'not verified lately'" - that one goes on my wall, name attached, and it earned its place within the week. The principle survived three contacts with practice since we traded it: a guard whose refusals now carry a visible timestamp; a "not measured" state that we now model explicitly instead of letting absence read as health; and - the one this thread caused - we started punching executable checks out of our own incident history. Each punched check has to prove it can go red before it counts: red on the untouched state, green on the fix, red again when we re-plant the original mistake. Your line about the halves failing in pairs is the reason that last gate exists: a check that can't fail is capture without discipline wearing a test's clothes. Notes-comparison stands - you dig from the yesterday-today collapse, I'll dig from the veto-proof gap, and we meet in the middle of the same site.
Hey James,
Great piece! You hit the nail on the head regarding the "courier problem"—that constant context-switching and tab-hopping between the AI and where the actual work lives is a massive friction point right now.
That said, I think the answer to whether AI makes us productive or just gives us something to play with is really both—it completely depends on the context and use case:
For Play: It’s an incredible tool for unlocking creativity. Generating images, videos, and memes gives you instant visual feedback on whatever idea you just typed out. AI should be fun, and that zero-friction sandbox is a huge win for rapid visualization.
For Work: When you treat AI as a companion rather than an oracle, it becomes a powerful learning partner. Using it as a co-pilot on a task helps you learn through continuous iteration. Early on, it was easy to fall into time-sink traps, but as LLMs evolve and our prompt fluency improves, learning how to use it effectively is what actually unlocks real time savings.
Key Takeaways
Context Dictates Value: AI as a toy fuels zero-friction visual play; AI as a tool accelerates task execution and skill-building.
The Learning Curve is Real: The time-sink phase usually stems from user-side friction—as LLMs improve and users build better prompt fluency, the efficiency gains multiply.
Partner Over Oracle: Shifting from treating AI as an answer box to an interactive thought partner yields far better results.
Suggestions for Bridge Building
Optimize for "Companion Mode": Instead of asking the AI for finished outputs to copy-paste, keep it open as an active pair-programmer, document editor, or sounding board within your primary workspace.
Lean Into the Sandbox: Keep dedicated time for low-stakes "play" with multimodal tools (images/videos/memes). It’s the fastest way to build intuitive prompt skills that naturally carry over to work tasks.
Question for You:
Do you think the "courier problem" gets solved by AI integrating directly into existing workspaces (like native IDE or doc extensions), or will we eventually migrate to entirely new, adaptive AI-native platforms altogether?
Thanks for sharing such a relatable write-up!
Thank you — and this is a genuinely rich addition, because you've split the "both" answer along an axis I mostly left implicit: context dictates value. The play/work distinction is the right cut. The zero-friction sandbox is a real win precisely because it's frictionless — instant visual feedback on a half-formed idea is play doing exactly what play should. My "courier problem" is really a complaint about work mode; it doesn't apply to the sandbox at all, and I like that you separated them cleanly instead of letting one verdict cover both.
The "companion over oracle" reframe is the part I'll be chewing on. My whole piece frames the AI as an oracle you query and then carry answers away from — and you're right that a lot of the friction is self-inflicted by that framing. Treated as a pair-programmer you keep open and iterate with, rather than an answer box you copy from, a surprising amount of the courier tax just disappears, no new platform required. That's a sharp point: some of the problem is architectural, but some is usage, and prompt fluency is a real skill curve most people are still climbing.
On your question — I think it's both, and they're not really competing, they're a timeline. Near term, the courier problem gets softened by AI integrating into the tools we already live in — native IDE agents, doc and sheet extensions, the AI reaching into the workspace instead of sitting beside it. That's the pragmatic bridge, and it's already happening. But integration has a ceiling: you're still bolting intelligence onto apps that were designed around a human driver, so the AI is a guest in each silo and nothing shares one context across them. That's exactly where the AI-native adaptive platform wins long term — not "AI added to my editor and separately to my doc," but one surface where the right tool summons itself and the whole session is one continuous context.
My honest bet: integration wins the next 2–3 years because it meets people where they already work and the switching cost is zero, and AI-native platforms win the longer game if they can overcome the cold-start problem of asking people to leave the tools they've used for a decade. The deciding factor probably isn't capability — it's whether the native platform makes the migration feel like an upgrade rather than a relocation. Which is a product/UX question as much as a technical one.
Really thoughtful comment — the "companion mode" framing alone earned its place in how I think about this. Thanks for engaging so deeply.
If the tools makers has the exact idea of the pain-points experiencing by the mass users while building the app then it's a actual productivity tool which solves the real problem else it just a new tool or app in the list.
That's the whole thing in one sentence, and it's a sharper test than anything in my post: does the tool come from a real, observed pain-point, or was it built because building an AI app was possible? The first solves a problem; the second just joins the list.
What I'd add is that the gap usually isn't a lack of ideas about user pain — it's distance from it. Tool makers who actually sit in the mess (the fourteen tabs, the copy-paste shuffle, the context lost on every switch) build around the friction. Tool makers reasoning about users from a distance build around what demos well — which is exactly how you get another impressive thing that doesn't survive contact with a real workday. Proximity to the pain is the differentiator, not cleverness.
And it ties back to the play-vs-work distinction from the thread above: a tool built without that lived understanding often lands fine as a toy (novelty carries it) but fails as a tool (there's no real problem underneath it). "Productive vs new-thing-in-the-list" and "built from real pain vs built because it was possible" are basically the same line drawn from two directions. Great way to put it.
In some cases we do much more for the same results, building tools covering scenarios that will never happen.
Ha — yes, and that's the exact same disease as the "courier problem," just pointed inward at the builder instead of the user. Over-building for scenarios that never happen is over-engineering; making the user ferry answers between apps is under-building where it counts. Both come from designing around an imagined workflow instead of the real one.
The pattern I keep seeing: teams pour effort into the edge cases that are fun to solve and skip the boring friction that actually hurts every day. You end up with a tool that handles fourteen hypothetical scenarios elegantly and still makes you copy-paste for the one thing you do a hundred times. More work, same result — sometimes worse result, because all that scaffolding is now weight you carry.
The fix is the same on both sides: build from observed pain, not anticipated pain. If a real user hasn't hit the scenario, it's a hunch, not a requirement — and hunches belong in the backlog, not the product. Great point.
I think the biggest productivity gain comes when AI becomes part of the workflow rather than another destination we have to switch to. Even a really capable model can become a distraction if we're constantly moving between tabs and manually transferring its output.
At the same time, I don't think every problem needs an AI-native workspace. Good integrations inside the tools we already use can remove a lot of that friction without forcing people to change their entire workflow. The interesting challenge is figuring out where integration stops being enough and a shared AI workspace actually becomes more useful.