agent-workspace

Inspiration

Most coding agents still work like solo tools. They can write code, but the rest of the team has little visibility into what they are doing until a pull request appears.

I wanted to build something closer to a shared workspace: a place where developers, product managers, designers, and agents can work from the same task, see the same application, and discuss the work while it is happening.

What it does

agent-workspace turns a task link into a shared development environment.

A team member can create a task, connect its repository, and start working with an agent. The platform automatically provisions the workspace, runs the agent, starts the application, and presents a live preview.

From the same task page, teammates can:

• Talk to and steer coding agents

• Review agent activity and evidence

• Comment on the task and preview

• Open a browser-tested application preview

• Use a shared terminal when needed

• Approve work before it is delivered

• Stop and continue work without losing progress

• Push the result to GitHub as a pull request

Workspace infrastructure is handled automatically. Users should not have to understand virtual machines or manually start and stop compute just to send an agent a message.

How we built it

The product is built with Next.js and hosted on Vercel. Supabase provides authentication, Postgres, private file storage, realtime data, and credential storage. Trigger.dev runs the durable background jobs that provision workspaces, execute agent turns, recover interrupted work, and deliver changes.

Daytona provides isolated development workspaces. It sits behind our own provider-neutral workspace interface, so we can support other providers or our own runtime later without rebuilding the product.

Each workspace can run Codex, Claude, or OpenCode-based agents. Agents receive an isolated browser powered by Playwright and Chromium so they can use and test the software they are changing.

GitHub App integration handles repository access and pull-request delivery. The preview system routes running services into authenticated, sandboxed task previews. I also built Open Design integration for design revisions and handoff between design and coding agents.

Challenges we ran into

The hardest part was making the infrastructure feel invisible.

Starting an agent can involve authenticating a user, restoring a workspace, cloning repositories, starting services, checking health, restoring an agent session, and reconnecting its browser. Any one of those steps can fail or time out.

I had to make those operations durable and idempotent so retrying an action would continue the original work instead of creating duplicate workspaces, sessions, or pull requests.

Secure previews were another challenge. The application runs inside an isolated workspace, but reviewers need to access it from a normal task link without exposing the workspace directly to the internet.

I also spent a lot of time on permissions and credential isolation. Agents need temporary access to repositories and model providers, but credentials cannot be written into task directories, browser profiles, checkpoints, or logs.

Accomplishments that we're proud of

A user can create an organization, project, and task, connect GitHub, run an agent inside an isolated workspace, view the running application, collaborate with teammates, stop and resume the work, and deliver it through a pull request.

I also added agent steering, task comments, private context files, skills, and automated workspace cleanup. As well as org skills and artifacts that can be referenced and used in any task.

The complete product flow is covered by Playwright tests and runs against the real application and database.

What we learned

The biggest lesson was that agent infrastructure should disappear into the product.

Users care about asking for work, seeing progress, reviewing the result, and continuing the conversation. They should not have to think about whether a virtual machine is stopped or which background worker needs to run.

Agents also need more than repository access. Giving each agent a browser dramatically changes what it can accomplish because it can inspect the actual interface, reproduce bugs, and verify its own changes.

What's next for agent-workspace

Next, we want to make the hosted experience reliable enough for teams to use every day.

That includes improving onboarding and invitations, expanding multi-repository tasks, strengthening browser-session isolation, increasing reliability, adding richer preview annotations and notifications, and making agent progress easier for nontechnical teammates to understand.

We also plan to deepen Open Design integration, support more workspace providers, improve long-running task recovery, and add the observability and security testing needed for production use.

The longer-term goal is simple: give software teams one shared place where people and agents can plan, build, test, review, and ship together.

Built With

• daytona
• opendesign
• playwright
• postgresql
• supabase
• trigger.dev
• typescript
• vercel