Your agent can do more. So can you.

Your host

Runs on hardware you control

Your computer starts and supplies the workspace: its container support, graphics card, sound, USB devices and your developer sign-in. The workspace is kept apart from the rest of the computer.

What you get Hardware you already control, with the devices and sign-in you already have. The setup guide prepares your computer.

Container

One boundary to reason about

Everything your agent does happens inside this workspace, with its own files, programs and settings, built from the project’s configuration.

What you get One boundary to reason about: the agent works in this workspace, plus what you share into it.

Workspace folder

Not your whole computer

The agent’s reach is the project folder plus only what you deliberately share with it. Sign-in sharing is on by default and can be turned off or limited to named providers.

What you get A clear edge: the project folder and what you hand over, not everything on your computer.

Your agent

Its reach, stated up front

Your agent works in the project folder with three limits stated up front: only what you share, only the agent tools you connect, and only the devices the workspace actually has.

What you get Three limits you can read, instead of guessing from behaviour.

GPU

Run and test graphical apps inside

The workspace asks your computer for graphics acceleration and uses what is available. On a Mac it runs through a managed Linux machine. Every platform is Beta.

What you get Your agent can run and test graphical apps where your computer provides a graphics card.

Audio

Sound when a task needs it

Sound works in three ways: a virtual device inside the workspace, your computer’s own microphone and speakers, or a connection you add later. Choose by whether the agent needs your real hardware.

What you get Your agent can play or record sound when a task needs it, where your computer allows microphone access.

USB

Attach devices, no rebuild

USB devices can be attached when the workspace is created, or attached and removed while it runs. Each attachment can be checked per device.

What you get Plug in a device the task needs and attach it without rebuilding, when the workspace was started to allow that.

Docker

Its own containers, apart from yours

The workspace can run its own container service, separate from the one on your computer. Using your computer’s own is a separate, deliberate choice.

What you get Your agent can build and run containers for a task, such as a database or a test service, without touching your computer’s.

Kubernetes

Deploy real services, no cluster to manage

A real test cluster runs inside the workspace, with its own web address and certificates. Your agent deploys to it and reads the result back. It needs Linux with container support and a local name service.

What you get Your agent can deploy a real service and watch it start, secure addresses included, without a separate cluster for you to manage.

Virtual machines

Cross-platform tests on machines you provide

Virtual machines run inside the workspace, where your computer supports them, so your agent can create, start and inspect them.

What you get Your agent can create Windows, macOS or Linux machines from your own installation media for a cross-platform test, then remove them.

Credentials

Push under your own identity

The launcher shares your developer sign-in with the workspace, on by default unless the project says otherwise, so Git, Docker and Kubernetes work as you. You can turn it off or limit it to named providers.

What you get Your agent can push a commit or call a service as you, without you entering credentials again each time, and you can turn this off per project.

Shared terminal

Watch the same session live

With the web terminal bridge enabled, the agent can expose a terminal it owns and share the link so you can watch the same session live.

The link grants typing as well as viewing, so agree with the agent on who is typing before you start.

• Console

What you get A live, exact view of the terminal the agent is driving, with the option to type into it yourself once the agent hands it over.

Terminal recording

Read back what ran

Terminals the agent opens can be created as persistent sessions, detached when a client session ends, and reattached later to read back what ran.

A persistent terminal stays available while its server keeps running.

• Console

What you get A record of what the terminal actually showed, that you can reattach to and read back instead of trusting a summary.

Screen video · full

An audit copy you can replay

Browser, remote desktop and Android sessions can record a plain screen video that follows the full captured timeline, useful when the continuous sequence of what happened matters.

Keep this recording as the audit copy: stop it and retrieve the file before the session ends; VNC and RDP recordings also report frame statistics, such as dropped frames, to inspect.

• VNC
• RDP
• Android
• Browsers
• Virtual desktops

What you get The complete, unfiltered recording to fall back on when the condensed copy needs checking against the source.

Screen video · condensed

A shorter file for review

A beta condensed recording keeps only the spans of visible activity, to shorten how long review takes.

Over VNC and RDP it also leaves transition screenshots and event manifests beside the video file.

• VNC
• RDP
• Android
• Virtual desktops
• Beta

What you get A shorter file to watch when you are reviewing, with the full recording kept for auditing.

Screenshots · manual

See what the screen showed

The agent takes a screenshot when it needs to see the screen: a browser page, a remote or virtual desktop over VNC or RDP, or an Android device.

Each one is published as a resource you open, showing the screen as the agent saw it.

• VNC
• RDP
• Android
• Browsers
• Virtual desktops

What you get A picture of what the screen showed when the agent looked, to compare with the result it expected before the next step.

Screenshots · auto

A visual trail of what changed

When condensing is enabled, each meaningful segment leaves a small set of labelled screenshots (start, one or more mid-points and end) captured as the picture changes, not on a timer.

Each screenshot and its manifest publish as files by reference, so you open them rather than scrub through a video.

• VNC
• RDP
• Virtual desktops
• Beta

What you get A quick visual trail of the moments that actually changed, without opening a video player or scrubbing a timeline.

Your agent

Inspectable, structured results

Your agent works through named actions that return clear results, alongside the shell it already has. Each result can be checked before the next step. Which tools it has depends on what its client connects.

What you get The tools available follow what your client connects.

Reflection · Not available

It knows what else the host is running

Reflection is Not available yet. It is meant to give your agent awareness of your computer and its own workspace: how busy they are and what other agents are doing, so it can wait for another agent instead of competing for the same resources.

What you get An agent that paces its heavy work around the others sharing your computer. Not available yet.

Terminals

Shells you can rejoin and share

Terminals stay open for a shell, an interactive session or a long build, and a named one can be reopened later. A person can join the same terminal in a browser and share the typing.

What you get A named terminal can be reopened later, and its browser link lets a person watch and type.

Agent Siblings

It starts and stops siblings

Siblings let your agent start, stop and check other workspaces of the same project from inside its own, without you running the launcher. It works on its own project.

What you get The agent can start and stop a sibling; removing one is left to you on purpose.

Tool Installs

Install declared tool versions

Tool Installs let the agent install a tool at the version the project lists, or search and install system packages where that tool is added. A reported success means the install finished cleanly.

What you get Read the tool or package back afterwards to confirm the result.

Containers

Docker, from create to remove

Create a container, run a command in it, read its logs, inspect it and remove it, on whichever container service the agent connects to. Cleaning up is a separate step.

What you get A container the agent created keeps running after the session until something removes it.

Kubernetes

Deploy, then read status back

Kubernetes lets the agent deploy to a local cluster and read back how each service is doing. A release recorded as deployed means the change was applied; the service status shows whether it is ready.

What you get Service status shows how many copies are ready when it is read.

Browsers

Drive Chromium or Firefox

Browsers drive Chromium or Firefox: open a page, click, inspect and capture it. Each screenshot comes back as a file, not as an image in the conversation.

What you get A returned result means the action completed. Open the screenshot to see the page itself.

Virtual Machines

Create, snapshot, shut down

Virtual machines are created from your own installation media, then inspected, saved as snapshots or shut down.

What you get Read each machine’s state back after a change.

Virtual Desktops

Control a remote screen

Virtual Desktops give the agent mouse, keyboard and clipboard control of a managed or remote Linux, Windows or macOS screen, with screenshots and recordings after an action.

What you get The next screenshot shows how the application reacted.

Android Devices

Reachable Android devices

This tool lists the Android devices and emulators you have made reachable, with what the agent needs to choose one. Android control is Beta.

What you get Each listed device is reachable.

Telemetry · Not available

Not in the private beta

Telemetry is Not available in the private beta.

What you get Nothing here to enable or verify yet.

Evidence

Results you read after the fact

Calls return an exit status, log lines, a screenshot, a recording or a cluster status you can read afterwards. Screenshots and recordings are saved as files on the machine that ran the tool.

What you get Each result keeps its own lifetime, separate from the conversation that asked for it.

First container · main

A second task, no stashing

Starting a branch gives it its own copy of the files and its own workspace, with your agent inside. The ignored or untracked files you pick are carried over the first time. Choosing the branch you are already on can start in place.

What you get Work on a second task without putting the first aside: each branch keeps its own files and its own running workspace.

Siblings · fix-login, docs

Many agents, own copies

Siblings start from the same definition, started by your agent, each with its own files and its own agent. Shared folders, sign-in and ports are shared by default, and a port policy can keep ports apart. A second workspace on one branch shares that branch’s files.

What you get Several agents work at once on separate branches without overwriting each other’s files, each result reviewed as its own branch.

Your cluster · pod

More room on your cluster

When one machine is not enough, the same definition starts a workspace on a cluster you set up yourself. It is prepared once with its own plan and an explicit approval, then used like any other.

What you get More room for parallel work on a cluster you already run, from the same definition, with its own requirements prepared once.

Project definition

One setup, many workspaces

One project definition starts every workspace on the project. The image, shared folders, runtime choices and dev tools are declared in it and reviewed before you approve it, once per project. Every branch, sibling and cluster workspace starts from it.

What you get Set a project up once and open as many workspaces as the work needs.

Start

Your agent, inside its own container

The launcher starts the container from the project configuration you reviewed, and the coding agent you use runs inside it. The agent tools it can call are the servers its client connects.

What you get A workspace ready for the task, with the agent and its tools inside the container rather than on your host.

Spec to code

From the task to a written change

The agent reads the task and the project, plans the change, works out its shape and writes the code in its own checkout. The dev tools the project declares were installed with the container. Where the terminal browser link is enabled, you can open the terminal the agent is using, watch it work and type to steer it; agree with the agent who is typing.

What you get A change written against the project as it is, with you able to step into the same terminal while it happens.

Local cluster

A real cluster inside the workspace

A local k3d cluster is set up inside the workspace, with its own ingress and certificates. The agent builds an image with the nested Docker, imports it and applies the manifests, then reads pod status back. It runs on Linux with Docker, a local DNS forwarder and network access, and needs its feature on your credential.

What you get A deploy confirmed from pod status, with no separate cluster for you to manage.

Browsers

One check across Chromium and Firefox

The agent starts Chromium and Firefox, sets up a managed Linux desktop so their windows are visible, and groups the browsers so one call reaches all of them. Each screenshot or video comes back as a resource you open, not an image pasted into the chat.

What you get The same journey compared in each browser, with the screenshots and videos to review it.

Android · Beta

The app on an Android emulator

The Android SDK and emulator install through aidc on amd64 hosts, and the emulator starts with the SDK. Once ADB sees it, the agent installs the app, taps and types through it, then opens the page in the device’s browser app. Android control is Beta.

What you get The native app and the web app checked on Android, with screenshots and recordings to review.

Virtual machines

Desktop apps on each guest system

When virtual machines are enabled (libvirt on), the agent creates Windows, macOS and Ubuntu VMs from OS-family templates and your own installation media. It installs and tests the desktop app over VNC or RDP, where the next screenshot shows how the app reacted. Then you open the screenshots and recordings the browser, Android and VM checks left and review them yourself.

What you get Each guest system checked on screen, and the evidence your tests left, in front of you to judge what happens next.

Ship and clean up

You review, then it ships and cleans up

You review the change on its branch; the git tools support that review and the approval stays yours. The agent commits and pushes its feature branch; direct pushes to main, master and develop are refused. It pushes the image to an allowed registry and upgrades a helm-style release. Then it shuts down the VMs and powers off the emulator.

What you get A branch you reviewed and a release to verify, with the test machines gone and the evidence kept as files.