The existing workflow stays
Agent-Up started around a fairly simple workflow.
I use a coding agent from my editor or terminal. The agent connects to Agent-Up through MCP, while Agent-Up manages the environment around its work: workspaces, processes, ports, Docker services, browser sessions, logs and commits.
I still think that is the right model.
Agent-Up should not replace the editor or the CLI agent. It should give them a development runtime they can reliably operate against.
But that workflow has one fairly obvious limitation.
I am still sitting in front of the machine.
The agent does not need me to stay there
Once an agent has a codebase, a worktree and a running development environment, there is no particularly good reason why that environment should disappear when I close the Agent-Up desktop application.
The repository is still there.
The application processes are still there.
Docker is still there.
And the agent may still have work to do.
What disappears is my way of interacting with it.
I want to be able to start work at my desk, leave, and later continue from another computer or my phone without rebuilding the entire development session somewhere else.
The browser session is moving to the server
This is the part I have been working on recently.
Until now, the browser experience has been closely tied to the Agent-Up desktop application.
For remote development, that is the wrong place for it.
The current headless-server work moves browser ownership into Agent-Up Server. Each workspace can have a persistent headless Chromium session which survives clients connecting and disconnecting.
There are now two distinct ways I want clients to access applications running inside a workspace.
AI mode
When the coding agent is using the browser, Agent-Up runs the browser session headlessly on the server.
The client can connect to that session through an IronRDP stream and watch what the agent is doing in real time.
This view is intentionally read-only.
You are observing the agent’s browser session, not taking control of it. The agent remains the one navigating, clicking, filling forms and inspecting the application.
This is the mode for checking in on an agent while it works.
Human mode
Sometimes I do not want to watch the agent.
I want to use the application myself.
In human mode, Agent-Up does not stream the agent’s headless browser session. Instead, the client connects directly to the services exposed by the workspace and renders them in its own WebView.
That means I can actually interact with the application: navigate around, click buttons, fill forms and test what the agent has built.
The two modes solve different problems.
AI mode lets me observe the browser session the agent is actively using.
Human mode gives me my own interactive view of the services running inside that same workspace.
There are still some rough edges around the headless browser connection, so this work is not released yet. But the important boundary has changed: the browser session no longer has to belong to the desktop application currently displaying it.
Self-host Agent-Up and connect to it
The next step follows naturally from that.
Instead of Agent-Up Server only being something running beside the desktop application, I want to be able to self-host one or several Agent-Up instances and connect clients to them over HTTPS.
The resulting setup looks roughly like this:
CLI coding agent ── MCP ──────────────┐
│
Desktop app ─────── HTTPS / stream ───┼── Agent-Up Server
│ ├── workspaces
Mobile app ───────── HTTPS / stream ──┘ ├── applications
├── consoles
├── containers
└── browser session
The existing MCP workflow does not go away.
Your CLI agent can still run from the editor and talk directly to Agent-Up through MCP exactly as before.
Remote development just gives the same server additional clients.
The phone becomes another Agent-Up client
This is where things get more interesting.
A mobile Agent-Up client is coming up as the next part of this work.
The goal is not to turn a phone into an IDE.
The codebase stays on the machine running the development environment. The applications keep running there. The browser session stays there. The agent keeps working against the same repository.
The phone becomes a control surface for that environment.
I want to be able to leave my desk, open Agent-Up later, see what happened, give an agent another task and watch it interact with the application through its browser session.
Or I can switch to human mode, connect directly to the workspace services and test the application myself.
From there, I want to review the resulting changes and use the same commit workflow Agent-Up already manages without first getting back to the development machine.
The development environment stays where it belongs.
Only my client changes.
Remote development is an additional workflow
I do not want this direction to turn Agent-Up into another hosted coding-agent platform.
The editor + CLI agent + MCP workflow remains important.
When I am at my desk, I still want the agent in my terminal, my editor beside it and Agent-Up managing the runtime.
Remote development adds another option:
I can run that same environment on a machine that stays online, connect the desktop application to it when I have a full workstation, and connect the mobile application when I do not.
Both are clients of the same Agent-Up server.
The workspace should outlive the client
Moving browser state into the server started as a requirement for headless Agent-Up.
But it changes something more fundamental.
Closing the desktop application no longer needs to mean leaving the development session behind.
The workspace, applications, browser and codebase can remain where they are while I move between clients.
That is the remote development direction I am working toward now.
The development machine stays put.
The development session comes with me.