Microsoft has published three new open-source adapters that let an existing AI coding agent show up as a Slack app, a Microsoft Teams bot or a Minecraft player. The repos are amplifier-acp-slack, amplifier-acp-teams and amplifier-acp-minecraft. They are MIT licensed and part of Microsoft's Amplifier Constellation project.
All three were brand new when we read them: zero stars, and between one and four commits each. This post explains what they do, how they differ, which parts are tested, and what to check before you connect one to a real workspace.
At a glance
| Slack adapter | Teams adapter | Minecraft adapter | |
|---|---|---|---|
| Language | Rust | TypeScript (Node 22.13+) | Node and Python |
| What the agent becomes | A Slack app with its own identity | A Teams bot (single-tenant Azure Bot) | A normal player on a Java Edition server |
| Transport | Slack Socket Mode, outbound only | Bot Framework HTTPS callback | Mineflayer body plus HTTP MCP tools |
| Agent link | Standard ACP over stdio | Standard ACP over stdio | Standard ACP with HTTP MCP |
| Validation claimed | Codex and OpenCode runs, no live Slack posts for OpenCode | Local fixture tests only | Synthetic fixtures; live tests optional |
| Status | Usable on Linux | Live tenant validation pending | Experimental |
What is ACP and why adapters?
ACP here is the Agent Client Protocol, an open way for a client to talk to a coding agent over standard input and output. A client starts the agent, opens a session, sends prompts and receives replies and tool requests. The Agent Client Protocol site documents the spec. Our own coverage of Hugging Face's agent manager shows the same idea in a different product: one shell, many agents.
The Constellation adapters take the other direction. They do not build an agent. They wrap one you already run. The Slack README puts it plainly: "Slack owns the conversations; the agent owns its identity, instructions, tools and durable agent state."
That split matters. The adapter handles chat plumbing, such as deduplication, retries, threads, rate limits and formatting. The agent keeps its own model, tools and memory. You can swap the agent without rewriting the chat side.
Microsoft has been building toward this for weeks. Our post on Amplifier UI and the bounded browser agent covers an earlier piece of the same project.
The Slack adapter
The Slack adapter is the most complete of the three. You install one connector per Slack app, point it at the agent's ACP endpoint, and invite the app into channels.
Key behavior from the README:
- Install:
./install.sh --label "My agent"builds the Rust binary, sets up a user service and prints a management URL. Linux with systemd is the supported host. Windows and macOS service installs are future work. - Connection: it uses Slack Socket Mode, an outbound connection, so Slack does not need a public URL to your machine. You create the app from a prepared manifest and paste an app-level token with
connections:writeplus the bot token. - When to reply: the default "when addressed" mode replies to direct messages and mentions. A "when useful" mode asks the agent to choose between speaking and staying silent in group chats, using a speak-or-pass JSON decision. The README calls that a convention, not an ACP feature.
- Sessions: every channel and every thread gets its own ACP session. Nothing merges transcripts automatically.
- Formatting: the agent returns ordinary Markdown. The connector sends it through Slack's
markdown_textfield so tables, code and lists render. - Files: supported Slack attachments become capability-checked ACP content, and ACP image, audio or document output can become Slack files. Existing apps need
files:readandfiles:writepermissions. - Permissions: an explicitly configured human can allow or deny a single ACP request in Slack.
The README lists limits too. Proactive cross-room posting is not implemented. There is no exactly-once guarantee for external tool effects. An uncertain send is marked uncertain and is not retried in another format.
The Teams adapter
The Teams adapter connects one agent to Microsoft Teams. It needs a single-tenant Azure Bot, a Microsoft Entra app, and a public HTTPS origin for the /api/messages callback.
The security notes are detailed. The Microsoft Teams SDK handles JWT validation, and the README says both SDK auth-bypass options are explicitly false. Unconfigured registration returns 503. The dashboard and management API sit on a separate private route and use their own bearer token.
Behavior mirrors Slack. Personal chats and mentions get replies. An optional "ambient" mode can read unmentioned group messages, which adds ChannelMessage.Read.Group and ChatMessage.Read.Chat permissions to the generated manifest. Group and channel conversations must be allowlisted. Targeted private messages inside group chats are excluded from room history.
Now the caveat. The repo description reads "live tenant validation pending", and the README says: "Live Teams verification is deferred at the user's request (November 1, 2026)." Nineteen core tests run against a fixture ACP process and "make no Teams or model calls." So the code is tested locally, but nobody has shown a real Teams send. Treat it as a reference implementation until that changes.
The README also notes an advisory in the Teams SDK's older MSAL Node dependency range. The repo pins an override to 7.1.0, reports zero issues from npm audit, and says the affected user authorization-code flow is not used.
The Minecraft adapter
This one is the playful experiment, but it has a serious design. The Minecraft adapter lets independent ACP agents join a server as ordinary players. Each player has its own process, inventory, credentials, session and task limits. Mineflayer supplies the player body. The adapter gives the agent scoped game tools through HTTP MCP.
What the agent can do: observe, read terrain maps, plan routes, move, follow, gather, dig, craft, use containers and furnaces, place blocks, write signs, hand items to others, chat and stop. What it cannot do: the README says agent tools expose "no arbitrary shell, RCON, teleport or item creation." Physics and movement run without model calls, which keeps costs down.
Coordination rules are explicit:
- A human addresses a player by name, such as "BuilderOne, help design a bridge". Follow-ups continue to the same player for ten minutes.
- Agents can ask each other for work with a
telltool. By default that allows four peer requests per hour, within forty minutes of human activity. The README calls this "a public chat convention, not a hidden coordination channel." - Tasks are bounded: 12 model turns and 40 minutes per task, 30 model turns per player per hour, and at most 24 mutating calls over 220 seconds per turn.
- A Stop command cancels work and revokes the current action lease.
The README is frank about quality. It says players "may still get stuck, misjudge materials, miss a waiting condition or produce unnecessary narration," and calls the project "an experimental adapter, not a general construction solver." It also says that an agent reporting a task as done "is not independent verification of the world."
Read together, this is a small testbed for multi-agent behavior with strict budgets. Our look at MIT's Eko agents playing on a virtual island explores a related question.
Safety: what these adapters do and do not protect
Putting an agent in a shared chat changes the risk. Anyone who can message it may try to steer it. Some points from the READMEs:
- Process separation is not isolation. The Slack README says process and folder independence under one OS account "does not isolate a hostile agent implementation." The same logic applies to the other two.
- Permission prompts are narrow. Slack and Teams offer single-use approval, and Teams approvals expire after two minutes and come only from the dashboard, never from chat content.
- The agent keeps its own power. The Minecraft README says its controls "do not change tools or authority already built into the agent itself."
- Credentials stay private. All three use private install folders, bearer tokens and loopback binds.
If an agent in a channel can run shell commands, a prompt injection in a message is a real path to your machine. Run such an agent in a sandbox with narrow credentials. For a tool that checks agent actions before they run, see AgentBeam, the agent security platform from the explainx.ai team. Our guide to Hugging Face SafeAgents covers a local-proxy approach.
How to try one
- Pick an ACP agent you already trust and have authenticated, such as Codex or OpenCode.
- For Slack, run
git clone https://github.com/microsoft/amplifier-acp-slack.git, then./install.sh --label "My agent". Open the printed URL, create the Slack app from the manifest, and paste the two tokens. - Start in a private test channel. Keep the default "when addressed" mode.
- For Minecraft, use an isolated offline test server,
npm ci --ignore-scripts, copy the example configs, and runnode body.cjsandpython3 adapter.pyin two terminals. Do not run the optional live tests against a world you want to keep, because some use RCON to prepare terrain. - For Teams, wait for live validation unless you want to help test it in a throwaway tenant.
How this fits the wider agent trend
Agents are moving from a terminal into the places where teams already talk. Open-source projects like Hermes Agent and CowAgent already ship chat connectors. What is different here is the protocol-first design: the connector knows nothing about the model, only ACP. That could make a company's chat integration reusable across agent vendors.
It also raises governance questions that the READMEs only partly answer. Who audits what an agent said in a channel? How long do per-thread sessions persist? The Slack and Teams adapters store received messages and delivery receipts in a private local database, and the Teams README says so directly. Plan for retention and access review before rollout.
What to watch next
- Whether Microsoft completes live Teams validation and publishes the result.
- Whether the repos open to outside contributions, as each README says is planned.
- Whether a fleet manager appears. The READMEs repeatedly mention a future fleet experience that would attach to these interfaces.
- Whether independent users report results with other ACP agents.
None of this is a product launch. These are early repos from a large vendor, with no stars yet and no release tags. They are worth reading as a design pattern even if you never run them.