Moving off Conductor Cloud? Hire the agent instead of hosting the workspace

On November 4, Conductor announced that it is joining Meta. Conductor Cloud goes read-only on November 13 and shuts down on November 20. Export your work before the shutdown.

If you’re looking for what comes next, Wallfacer takes a different approach. Conductor gave you a place to run an agent. Wallfacer gives you an AI employee with its own computer and accounts, a handbook that teaches it how your team works, and work you can assign from GitHub, Slack, or email.

Give the agent a job

Assign it a GitHub issue. It creates a branch, runs the stack on its computer, implements the change, and opens a pull request under its own name. It responds to review comments and comes back to you when it needs a decision.

The agent has a name and a role you define. Its handbook contains the context it needs and the procedures your team follows. You can give it work directly or start it through a schedule, webhook, or GitHub trigger. You do not need to open a workspace to start each task.

What moves from Conductor

First, save your existing work. Right-click a cloud workspace and choose Transfer to local to move it and its chats to your Mac. Download a full archive from Settings → Account → Export data.

Then use your existing setup to prepare the agent:

Your Conductor chats stay in your export. There is no chat importer; new work starts as new tasks in Wallfacer.

Use your coding agent to migrate

Open the repository you want to migrate in your coding agent and paste this prompt. Replace <path> with the location of your Conductor export.

Read https://www.wallfacer.ai/llms-full.txt and the README at
https://github.com/WallfacerTech/wallfacer-cli, install and sign in to
the wallfacer CLI, then read this repository's .conductor/settings.toml,
conductor.json, CLAUDE.md, AGENTS.md, .claude/commands/, any MCP config,
and my Conductor export at <path>.

Turn them into a Wallfacer computer (an agent-env.yml with sources,
setup from the install and setup scripts, one service per run action
with its port, env, ${secrets.NAME} references for every secret, and
mcp_servers), handbook pages carrying the conventions from the
instruction files, and one playbook per routine; create them in my
account with the CLI, store secret values with wallfacer secrets and
never in the manifest or in this chat, and finish with a list of
everything that did not transfer, including chats.

Your process defines what happens next

A playbook spells out the steps: implement the issue, run the checks, open the pull request, wait for review, and address requested changes.

Where a step requires a human decision, the agent waits. That signal can be an approving GitHub review, a label, or a reply in Slack. Your team defines what allows the work to continue, so approvals can stay where you already make them.

The task records the work as it happens: the agent’s turns, commits, questions, and replies, with each participant identified. You can see which steps ran, where the agent stopped, and what decision it needs.

The whole team can work with it

Tasks are shared across the account. Anyone can open a task, talk to the agent while it works, and see who said what. In Slack, the conversation stays in a thread the channel can follow.

When you hand a task to a colleague, the agent keeps going. The task, branch, and conversation stay together, so your colleague can pick up the review without starting over.

A computer you can inspect

The agent works on a Linux or macOS computer configured with your repositories, setup commands, services, secrets, and MCP servers. Snapshots let tasks start from a prepared environment. macOS computers include Xcode and an iOS Simulator you can watch from the task.

You can inspect the work as it runs:

• Console: run commands on the computer from the task view to check a process, inspect a file, or run tests.
• Logs: see output from setup steps and services, including failed installs and crashed dev servers.
• Previews: open exposed service ports from your laptop or phone.
• Screenshots: review the pages the agent changed through images it adds to the task and pull request.

You can also run commands from your terminal or CI. For example, wallfacer exec --vm <id> -- make test returns stdout, stderr, and the exit code.

Each command runs in a fresh shell. There is no persistent shell, SSH access, or turn-by-turn revert. If your workflow depends on one of those, bring it up when we plan the move.

Start with one real issue

Hire one agent. Give it a role, prepare the computer your repository needs, and write a simple playbook with the required checks and review steps. Assign one real issue and let it carry the pull request through a round of review.

Use what you learn to refine the handbook and playbook. When the process works without you steering each step, give it more work.

Bring us a process and we will set up that first agent with you before November 20.