On this page
- Both host the agent and its sandbox
- What changes when the agent is on a team
- Who the agent is
- What it can reach
- How work reaches it
- Who checks its work
- How it learns how the team works
- Whether it can run the project
- What it costs
- Which model it runs
- Connecting things, side by side
- Several agents with different access
- When Managed Agents fits better
- When Wallfacer fits better
- Claude Tag is Anthropic's finished agent in Slack
- Related
Wallfacer and Claude Managed Agents
Claude Managed Agents is Anthropic's hosted agent runtime: a set of APIs for defining an agent, giving it a cloud sandbox, and running sessions against it. Wallfacer is a product your team hires agents in. Each agent has a computer, its own accounts in GitHub, Google, and Slack, a model, and the handbook it works from.
Both run the agent loop and its sandbox, so the runtime is not where they differ. The difference shows up once an agent works on a team: who it is, what it can reach, how work gets to it, who checks its work, how it learns the team's conventions, and what it costs. Managed Agents leaves those to the application you build around it, and Wallfacer ships them. Comparisons reflect Anthropic's documentation as of October 2026. Managed Agents is in public beta, so check the linked page before relying on a detail.
Both host the agent and its sandbox
- Agent loop and sandbox. Managed Agents runs Claude with a built-in toolset (shell, files, web search and fetch) in a container per session. Wallfacer runs Claude Code or Codex in a harness VM beside a separate computer that holds your code. See Platforms.
- MCP servers and secrets. Both connect remote MCP servers and keep secret values out of the transcript: vaults on Managed Agents, environment secrets and the keychain on Wallfacer.
- Memory across sessions. Managed Agents has memory stores with version history. Wallfacer agents keep a journal, objectives, and todos. See Agent Memory.
- Schedules and a record. Both run work on a schedule and keep an event log for every session.
What changes when the agent is on a team
Who the agent is
On Managed Agents. An agent is a versioned configuration (model, prompt, tools, MCP servers, skills) with a name and no accounts of its own (agent setup). In GitHub it acts as whoever owns the token your code passes in. Anthropic's GitHub guide asks for a personal access token, so unless you set up a machine user or a GitHub App, the agent's commits and pull requests appear as the person who set it up. In Slack it posts as whatever app your bridge uses.
On Wallfacer. An agent is a member of your account with a handle and a role page. It has its own GitHub bot account, a Slack app under its own name, and a Google user with a mailbox, so its commits, messages, and mail all trace back to the same agent. Offboarding disables the agent and keeps that attribution. See Agents.
What it can reach
On Managed Agents. Credentials travel with the session your code starts: the vaults and the repository token you attach. Vault secrets are swapped in only as traffic leaves the sandbox, so the agent never holds the value, and an environment can restrict outbound traffic to a list of hosts (environments). Nothing ties a vault to a particular agent. That pairing is your code's job, or a separate Anthropic workspace's.
On Wallfacer. Credentials belong to the agent. Each session receives only its own agent's GitHub token, model key, Google account, and keychain grants, and they are available in the computer's shell for the commands the agent runs. Computers have open outbound access. The real limits are the scope of each token and the bot's role on each repository.
How work reaches it
On Managed Agents. A session starts when your code calls the API, from a webhook receiver, a scheduled deployment, or one of Anthropic's recipes. The Slack quickstart bridges mentions to sessions, and the incident responder cookbook takes an alert through a pull request and a Slack approval. You deploy and host each one.
On Wallfacer. People assign the agent a GitHub issue, mention it in Slack, or email it. Playbooks start work from events and schedules. Any system that can send a webhook can feed a playbook through a collector URL, and the trigger is a sentence describing what should start it.
Who checks its work
On Managed Agents. A tool call can pause for a person to allow or deny it (permission policies). A review flow across steps is something you build; the human-in-the-loop cookbook shows approve, reject, and escalate paths made from custom tools.
On Wallfacer. Review is part of the playbook. The seeded flow opens a pull request, a reviewer agent reviews it when asked (it can run a different model from the author), and the task then waits for an approving review from a person who is neither the author nor the reviewing agent. A review that requests changes sends the work back to the implementing agent with the feedback. The merge decision stays with a person, on GitHub, under your branch protection.
How it learns how the team works
On Managed Agents. Skills and memory stores, attached to an agent or a session.
On Wallfacer. The handbook. Pages describe how the team works, a role page is the agent's job description, and both reach every session the agent runs. Editing a page changes the next task with no code change.
Whether it can run the project
Agents do better when they can build and test what they change. Microsoft's .NET runtime team reported that its coding agent's success rate rose from 38.1% to 69% after it could reach the package feeds and had build and test instructions to follow (Ten months with Copilot coding agent in dotnet/runtime).
On Managed Agents. Each session gets a fresh Linux container with up to 8 GB of memory and 10 GB of disk. Common runtimes, Postgres, Redis, and headless Chromium are installed, and you start services inside each session (cloud sandbox reference).
On Wallfacer. A computer is defined by a manifest that runs setup once, keeps your services running under health checks, and boots from a snapshot, with web preview. macOS computers have Xcode and the iOS Simulator. See Environments.
What it costs
On Managed Agents. Token prices plus $0.08 per running session-hour, with a hard budget per session and a monthly limit per workspace (pricing, budgets).
On Wallfacer. Each agent runs on Wallfacer's metered model access, your own API key, or a Claude or ChatGPT subscription seat, and each agent on metered access has a daily spend cap. See Agents.
Which model it runs
Managed Agents runs Claude. A Wallfacer agent runs Claude Code or Codex, chosen per agent, so the author and the reviewer can be different vendors while the playbook stays the same. See Models.
Connecting things, side by side
Much of the setup is the same work on both. Each row names the usual path in each product's own documentation.
| What you connect | Claude Managed Agents | Wallfacer |
|---|---|---|
| An agent | Create an agent with a model, prompt, and tools, in the Console or by API | Hire AI Employee on the Team page; the computer is created with it |
| Model | Claude models, billed to your Anthropic API account | Claude Code or Codex per agent, on Wallfacer's metered access by default; your own API key or a Claude or ChatGPT subscription seat once enabled for your account |
| Private repository | Mount it on the session as a github_repository resource with a token passed at session start (GitHub) | Set the repository on the computer; the agent's GitHub identity clones it |
| Commit and PR author | Whoever owns the token you supply, such as a machine user or a GitHub App | A dedicated bot account you create for each agent, connected with a classic repo token (GitHub identity) |
| Toolchain | A package list on the environment; Python, Node.js, Go, Rust, Java, and Ruby preinstalled | Setup commands in the manifest, captured in a snapshot |
| Databases and dev servers | Postgres 16 and Redis 7 installed but not running; you start them in the session. Reaching a dev server from outside is undocumented | Declared as manifest services, health-checked and kept running, with web preview |
| Browser | Playwright and headless Chromium preinstalled; the computer-use and browser-use tools are not available | A browser tool on every Linux computer; macOS computers use the iOS Simulator instead. See Browsing |
| macOS and iOS | Not available in the cloud sandbox (Linux x86_64, up to 8 GB memory, 10 GB disk) | macOS computers with Xcode and the Simulator |
| Environment changes | Agents are versioned; "Environments are not versioned" (environments), so keep the configuration in git | Each manifest change builds a new snapshot; roll back by promoting an earlier one through the API |
| Secrets | Vaults, attached when a session starts; a value is swapped in only as traffic leaves the sandbox | Environment secrets for builds and services; the keychain for logins granted per agent |
| MCP servers | Remote servers with vault credentials; private servers through MCP tunnels (research preview); stdio servers are not supported in the cloud sandbox | Remote servers with headers or an OAuth sign-in, plus stdio servers run inside the computer (MCP servers) |
| Network egress | limited (an allowlist) or unrestricted per environment. The Console starts new environments on limited; the API default is unrestricted | Open outbound access; no allowlist yet |
| Slack | A quickstart or cookbook bridge you deploy and host | Connect the workspace once, then add each agent as its own Slack app, which a Slack admin approves |
| Build it yourself | Each agent with a Google account has a mailbox; mail to it starts work | |
| Google Workspace | Google's Workspace MCP servers (developer preview) with an OAuth grant stored in a vault | Each agent can get its own Google user with Drive and Gmail, on a subdomain you choose |
| Events from GitHub or other tools | Your webhook receiver calls the sessions API | A webhook collector URL or an event key, then a playbook trigger written as a sentence |
| Schedules | Scheduled deployments (cron) | Schedule triggers on a playbook |
| Approval | Per tool call, or a flow you build from custom tools | A Wait step on the decision a person makes in GitHub or another system |
| Spend | A hard budget per session; a monthly limit per workspace | A daily cap per agent on Wallfacer's metered model access, $1,000 by default; Wallfacer raises it on request |
Several agents with different access
Take three hires: an engineer who can push to repository A, a reviewer who can read repositories A and B and use Linear, and a support agent with Zendesk and Slack and no GitHub at all.
On Managed Agents. You create three agents, three vaults, and an environment for each with its own allowlist, then pass each one's repository token when its sessions start. The platform does not tie a vault or a token to an agent: vaults, environments, memory stores, and webhooks are visible across the workspace, and the external_user_id on a vault is a label you choose (vaults). The separation lives in the code that starts sessions, or in a separate Anthropic workspace per employee, which is the boundary the platform enforces and also carries its own spend limit. A reviewer run as a sub-agent inside the engineer's session shares that session's sandbox and credentials, so run it as its own session (multiagent orchestration). Each employee's identity in GitHub, Slack, and Google is something you create in those systems.
On Wallfacer. You hire three agents. The engineer gets a GitHub bot account with write access to A; the reviewer gets a bot with read access to A and B; the support agent connects no GitHub identity, so its sessions carry no git credentials. Each session receives only its own agent's GitHub token, model key, Google account, and keychain grants, so the Zendesk key granted to the support agent never reaches the others. MCP servers and environment secrets belong to a computer rather than an agent, so give agents that need different tools different computers: the Linear server goes on the reviewer's. What each agent can actually do is enforced by the systems on the other end: the bot's role on the repository, what people share with its Google user, and the scope of each token.
Both products leave the external accounts to you: a GitHub machine user or App on Managed Agents, a bot account per agent on Wallfacer. Slack and Google are where the setup differs most. Wallfacer creates the agent's Slack app and Google user; on Managed Agents you build a Slack app and connect a Google account through Google's Workspace MCP servers, which are in developer preview.
When Managed Agents fits better
- You are building agents into your own product. Your customers are the end users, and you want Anthropic's primitives under an interface you design.
- Execution must stay in your infrastructure, self-serve. Self-hosted sandboxes run tool calls on machines you control, and inference can be pinned to the US (data residency). Wallfacer runs on your own hardware only as a dedicated enterprise deployment.
- You need an outbound allowlist. Managed Agents environments restrict egress by host; Wallfacer computers do not yet.
- Claude alone is enough. Outcome graders, memory stores with version history, and coordinated sub-agents within one session are Managed Agents features.
Managed Agents is not eligible for Zero Data Retention or a HIPAA BAA, because sessions store history and sandbox state server-side (overview).
When Wallfacer fits better
- Your team wants colleagues to hand work to. People reach the agent by assigning an issue, in Slack, or by email, and nobody builds or hosts a bridge.
- Each agent should be accountable as itself. One identity across GitHub, Slack, and email, with its own credentials and its own record.
- The team's process should hold. Review routed through a reviewer agent and a person, conventions in the handbook, and the same playbook whichever model performs a step.
- The work needs a real machine. Running services, previewing the app, or building for iOS on macOS.
Wallfacer has completed its SOC 2 Type II audit. It can run on your own hardware as a dedicated enterprise deployment (contact us). It does not yet offer a self-serve region choice or an egress allowlist. See Security.
Claude Tag is Anthropic's finished agent in Slack
Anthropic also ships Claude Tag, a Slack product with its own agent identity, routines that run on events and schedules, and memory per channel. It is a separate product from Managed Agents and the closer comparison when the question is an agent your team talks to in Slack.