change Software Development with AI-Powered Cloud Agents

The split is over

PageSpace just shipped sandboxes, and the headline isn't "more AI agents." It's the collapse of two layers into one. Until now, the standard workflow looked like this: a workspace like PageSpace held context — docs, tasks, discussions, decisions, agent work — while local agents like Codex and Claude Code held execution. Two tools, two truths, a constant ferry of requirements back and forth between them. The new sandboxes put repositories, shells, builds, tests, and deploys inside the same workspace where the context already lives.

That's a real architectural move, and worth appraising before it's worth critiquing.

What PageSpace already was, before sandboxes

The article is explicit about this. PageSpace wasn't a code editor. It was already a shared memory and coordination layer for software development — product ideas, requirements, discussions, tasks, decisions, research, documentation, and agent work all living together. The author had been using it to build landing pages and websites, and to coordinate with their team and agents on more complex applications backed by GitHub repositories. The code itself wasn't there yet, but everything around the code was.

That's the underrated pre-history. Most teams already know their context problem. They have it in Notion, in Linear, in Slack, in a wiki nobody reads. PageSpace was already consolidating that mess into a single recursive workspace — a workspace where documents, folders, channels, tasks, agents, code, spreadsheets, and files share the same structure, and where something lives gives it context. Sandboxes are the missing layer that turns a coordination tool into an execution tool, without breaking the part that already worked.

The split-brain workflow, and why it was always going to break

For the last couple of years the playbook was clean on paper:

• PageSpace (or Notion, or Linear, or whatever): shared memory. Product discovery lives here. Requirements live here. Decisions live here.
• Codex, Claude Code, Cursor: execution. Code lives here. Builds run here. Tests run here.

The two halves talked through MCP or copy-paste. The agent read a page, wrote code locally, came back with a diff. Sometimes it remembered the decision you made in a discussion thread. Often it didn't.

Code is the easy part of building software. Everything else — discovery, design, coordination, user testing, research, stakeholder alignment — is prerequisite, and carries the context with it. That context shapes what gets built, how it gets built, and whether the result is actually useful. When context and execution live in two systems, the agent is always rebuilding its understanding from scratch. Some days that costs an hour of re-prompting. Some days it costs a feature that shipped wrong.

What a PageSpace sandbox actually is

The article describes sandboxes as real cloud development environments that agents can use directly. Not a chat wrapper. Not a code viewer. A running machine with the right permissions attached to the workspace. Concretely, a sandbox can:

• clone repositories
• edit code
• install dependencies
• run shell commands
• build custom tools
• run tests and builds
• inspect failures
• deploy software

That list is the loop. An agent that can clone, edit, install, run, test, build, and deploy in the same environment where the requirements doc lives isn't autocomplete. It's a junior engineer with read access to the entire project history. The difference matters because "diff that came back from the chat" is not the same artifact as "deploy that landed on the page next to the decision that justified it."

"Everything is a page" — why the rest of the product matters too

Sandboxes aren't bolted on. They attach to the same recursive workspace where documents, folders, channels, tasks, agents, code, spreadsheets, and files share the same structure. Where something lives in that tree gives it context. Agents navigate the workspace to find what they need, the same way a new hire would.

That last sentence is the load-bearing one. The agent doesn't grep a flat filesystem. It walks the same tree a human walks. The requirements doc is a page. The decision is a page. The repository is a page. The sandbox is a page. The build log is a page. The deployed URL is a page. Everything has a URL. Everything has a place. Context is location, and that has always been the underrated part of every workspace tool that worked.

MCP was the prerequisite, not the headline

PageSpace already supported MCP before sandboxes shipped. External coding agents could already search the workspace, read pages, navigate project structure, update tasks, and create or edit content. That's why the sandbox rollout didn't require a brand new API surface — the workspace was already agent-readable. The seam was already there. Sandboxes are what runs through it.

If you're building anything agent-shaped and haven't taken MCP seriously yet, this is the reminder. The pieces of your system that are agent-readable today are the pieces that survive a model rotation tomorrow.

How to actually use this today

The concrete steps are short because the product does the wiring for you:

# 1. Open the PageSpace workspace you're already using
#    Same project as your docs, decisions, and tasks.

# 2. Create a sandbox page
#    Link a GitHub repository to it. The sandbox now has the
#    repo as its working tree.

# 3. Link the requirements and decision pages
#    The agent will read them as context before it touches code.

# 4. Hand the sandbox a task
#    The agent clones, edits, installs, tests, builds, deploys.
#    Failures land on the page as sub-pages you can comment on.

The loop is the same loop you'd run with a local agent. The difference is that inputs and outputs both live in the same place. The diff is a page. The build log is a page. The deployed URL is a page. There's no "where did that file go" step, and there's no second tool to keep in sync with the first one.

The part that doesn't change when the tool does

Here is the honest bit. PageSpace is the right call today. It might not be the right call in six months. The agent that's cleverest this quarter will be beaten by the one that's cleverest next quarter. Codex becomes Claude Code becomes whatever ships at the next launch event. The workspace layer will churn too.

The piece underneath all of it — the UI your users actually touch — is the part that should not churn with the model. The same component, rendered on web, iOS, and Android from one API. That's the durable substrate. The agent reads your docs; the UI renders your product. When the model rotates, the UI does not need a migration.

So: use PageSpace sandboxes. Use MCP. Use whichever model is winning this week. Build the product layer once, on a layer that doesn't care which agent is driving it.

What this gets us

Three concrete enables when context and execution share a tree:

• An audit trail you can actually read. Every decision, every diff, every deploy lives on a page with the people who made the call next to it. Six months later, the why is one click away.
• Agents that improve across runs. Because the workspace remembers, the agent on attempt three reads the failure log from attempt two. No re-prompting. No copy-paste of the previous error into a fresh chat.
• Onboarding that takes an afternoon. A new engineer — or a new agent — gets the entire project history by walking the tree, the same way the human team does.

Closing

The hard part of building software was never the typing. It was the remembering. PageSpace's sandboxes collapse the gap between where the context lives and where the code runs. Use it. And underneath it, build the UI once, on a layer the agents can't churn.