Ask your assistant to write a script and it will, instantly and competently. Ask it to run that script every morning and send the results to your team, and the conversation stalls. The assistant has knowledge and judgment, but it is standing in an empty room: no disk, no long-running processes, no address on the internet. It can describe work. It cannot hold work.
This post is about closing that gap: what a real computer for an assistant actually needs to include, and how to attach one without becoming your assistant's system administrator.
Quick answer
An assistant needs four things a chat window cannot provide: durable storage that survives the conversation, a runtime that keeps processes and schedules alive, a stable URL where results live, and spending limits so autonomy stays safe. You can attach all four in one step by connecting an assistant-ready server over MCP, and the assistant provisions and uses the computer itself from that point on.
Key takeaways
- A chat session is stateless. Real work needs state: files, databases, history, and processes that outlive the conversation.
- The computer must be the assistant's to operate. If a human has to provision, deploy, and babysit it, you have hired yourself as the assistant's ops team.
- Outputs should be URLs, not pasted code. A live address is something your team can open, check, and keep using.
- Autonomy needs a ceiling. A hard budget cap is what makes it reasonable to let an assistant operate infrastructure at all.
Why a chat window is not enough
Everything in a conversation evaporates when the conversation ends. The code block your assistant produced yesterday is not running anywhere. The cleanup it did on your spreadsheet lives in a download, not in a tool your team can reuse. Each new request starts from zero, which is why so much assistant output feels like homework you still have to do something with.
The missing ingredient is not intelligence. It is a place: somewhere the assistant can write files, install what it needs, keep a process alive at two in the morning, and hand you an address instead of an artifact. We have written before about why persistent workspaces are the difference between answers and outcomes, and about the deployment layer that is still missing from most agent stacks. This post is the practical version: what the computer needs, piece by piece.
What the computer needs
Durable storage. The workspace has to survive the session, the day, and the month. That means real files and real data the assistant can come back to, so a follow-up request refines the same tool instead of rebuilding it.
A runtime that stays up. Monitors, schedules, webhook listeners, and small web apps are all long-running by nature. The computer must keep them alive when the chat is closed and scale to zero when nothing is happening, without losing state.
A stable URL. Work your team cannot open did not really ship. Every project should get an address that stays the same across edits, and it should stay private until someone decides otherwise.
Spending limits. An assistant that can provision compute can also waste it. A hard, account-wide budget cap that the assistant cannot raise is the difference between delegation and a blank check. We covered the mechanics in how credits and budget caps keep agent compute predictable.
An interface built for assistants. The assistant should acquire and operate this computer through tool calls, not through a cloud console designed for humans.
How to attach one in practice
With an MCP-compatible assistant, the setup is one configuration block: point the assistant at an assistant-ready server endpoint, authenticate with a key, and the provisioning tools appear in its toolbox. From there the assistant does the rest itself: it creates a server when it needs one, creates projects inside it, builds, runs, and hands back URLs. The full walkthrough lives in give your AI agent its own server with one MCP call.
The day-one experience looks like this: you describe an outcome, such as a page watcher or a small internal tool. The assistant provisions its computer, builds the thing inside a private project, checks that it runs, and returns a link. You review it privately, ask for changes in plain language, and flip it public when it is ready. A starter like the URL uptime monitor template makes a good first request because the result is visibly alive: scheduled checks, a status page, and a URL you can share.
If your assistant does not speak MCP, the same computer is reachable over a plain REST API, so the definition of "assistant" stretches to any script or agent framework you already run.
What changes once it has one
The practical difference shows up in the shape of the output. Instead of code blocks, you get running tools. Instead of one-off answers, you get software that accumulates: a feedback board, a weekly metrics digest, a watcher, a portal. And because every project is a real workspace with files and history, an engineer can open it later and take over without archaeology.
Ready to try it? Connect your assistant and give it its first computer.
FAQ
Is this just a sandbox?
No. Sandboxes give a caller a CPU for seconds and throw the state away. A real computer keeps the workspace, the processes, and the URL alive between conversations. The full comparison is in sandboxes vs build servers.
Does my assistant need special training to use it?
No. The tools are self-describing over MCP. Any MCP-compatible host discovers them and can start provisioning immediately.
What stops the assistant from spending too much?
The account-wide budget cap. When spending reaches the ceiling you set, new work pauses. Only the account holder can raise it; the assistant cannot.
Is everything the assistant builds public?
No. Projects are private by default. The URL only serves traffic once you choose to make the project public, and it keeps the same address when you do.
Related reading
- Give your AI agent its own server with one MCP call
- Why AI agents need persistent workspaces
- Sandboxes vs build servers
- The best use cases for AI agents that ship software