A vision for coworking with agents

I spent the past year trying to squeeze more out of my interactions with AI. My frustration boiled over on something as simple as updating a resume. Copy, paste, prompt, iterate. Scroll, iterate, scroll, over and over. For something that was supposed to be an assistant, I was doing all the grunt work. I thought agents could solve this, but building one felt like overkill for the problem in front of me, like renting a crane to hang a picture frame.

It wasn’t until I used Cursor that I understood what it meant to put an agent to work: a tool with a basic set of commands, somehow adept at combining them in creative ways to get a task done. And if you don’t live in an IDE, or the letters CLI mean nothing to you, you’ve probably never felt that moment that’s exhilarating and a little destabilizing at the same time, when you realize you’ve just been handed something genuinely capable and you have no idea yet what it means for your future.

So I set out to cut down the copy-paste. What would it look like if your documents were first-class citizens, and the agent were built to act on them, not just talk about them? What if you could mark up a draft the way you would a coworker’s, and have the agent respond like an assistant that gets to work, instead of a chatbot that just talks back?

Five things fell out of that question. Everything I’ve built since traces back to one of them.

Files form the foundation

The chatbot model has the causality backwards. You describe what you want, the model describes what it would do, and then you’re the one who goes and does it: copies the snippet, retypes the paragraph, reconciles its version with yours. The model talks; you act. I wanted to invert that.

The agent’s response should be the document itself, not a description of an edit sitting in a chat window waiting for me to apply it by hand. Chats offer a lot of output but little outcome without intervention.

The introduction of “Artifacts” in some products helped, but they often felt like an afterthought—bolted onto the side of an existing product rather than built into its core. I wanted to explore an interface where you can engage with a document like you would if it were written by a coworker: mark it up, iterate, all while preserving version history.

”Always-on” Agents

I wanted to build toward a vision where agents are ambient, not something you open a tab for and close when you’re done. There’s still plumbing to figure out here, and I don’t think anyone has fully cracked it yet, but the core mandate is clear: work should keep moving after I close my laptop. A task should be able to start from wherever I happen to be, whether that’s inside the app itself or a passing mention somewhere else that pulls context into the workspace.

Context belongs in the cloud

While desktop-native solutions are a great way to “meet users where they’re at,” I’ve always preferred to skate to where the puck is going. That means shifting the workspace itself entirely to the cloud: executing long-running processes in data centers instead of dragging down personal computers, and streaming results back to the user as needed.

The rigid boundary between desktop and cloud is exactly what breaks ambient AI. If an agent’s memory lives in a chat thread on a single local machine, it dies the moment that laptop goes to sleep. An ambient assistant shouldn’t depend on local hardware staying awake. By shifting the workspace to the cloud, every channel and every model reads from and writes to the exact same persistent state.

Nothing you save should die in an isolated chat thread. The longer you work within a cloud-native workspace, the more context the agent accrues. That compounding value is the entire point.

Transparency builds trust

The moment you let an an ambient cloud agent write to your files directly, you’ve handed it something a chatbot never had: the ability to be wrong in a way you don’t immediately see. That trade only works if you can watch it happen. I wanted every tool call and every line of thinking to stream live, not show up only after it was done, and I wanted every edit to land as a tracked change I could accept, reject, rewrite, or branch from, the same way I’d review a coworker’s suggestion. Version history has to put a file back exactly the way it was, no questions asked.

An agent I can’t see is an agent I can’t actually delegate to. Trust doesn’t come from the model always being right. It comes from the work being transparent and reviewable.

Mixture of Models

While the best models are impressive in their ability to navigate complex situations, two things seemed obvious to me:

1. The leader in any given capability, whether coding, image generation, reasoning or prose, kept shifting: rarely did one model excel at everything and hold the edge for long.
2. The open-weights alternatives deliver matching capabilities months later, at a fraction of the price.

Hitching the product to a single provider’s roadmap was a risk I wanted to avoid from day one. So I didn’t build loyalty to a single model into the foundation. Each task should go to whichever model does it best today, and when something better ships, swapping it in should be routine, not a rewrite. Providing users with consistent access to the latest capabilities shouldn’t require stacking multiple monthly subscriptions and manually shuttling context between them.

Brute-force “tokenmaxxing” is an unsustainable way to build. Once the novelty of massive context windows wears off, enterprises will revert to what is second nature to businesses and engineers alike: minimizing cost while maximizing efficiency.