Hand Work to an Agent From Slack and Teams

A thread in #payments, mid-morning. Someone asks @Archyl what calls the webhook sender, and the bot answers: the Checkout and Billing containers, both through the Payments API. Two messages later comes the line every one of these threads ends on: "we should add retries to that, can someone pick it up?"

Then the thread goes quiet. Somebody has to open Archyl, find the project, pick an agent profile, and retype a task that already exists, word for word, three messages up.

Since June, the Archyl bot has answered questions in Slack and Microsoft Teams. As of today it can also act. The same thread can hand the work to a managed agent:

@Archyl run [Payments API] add retries with backoff to the webhook sender

The agent runs as the person who typed that, and the bot follows the run in the thread until there's a pull request.

One thread, start to finish

Here is the rest of that exchange. The messages from Archyl are the formats the bot actually posts. The names, the question and the pull request are examples.

Marie:   @Archyl run [Payments API] add retries with backoff to the webhook sender

Archyl:  🚀 Agent `backend-fixer` started on Payments API. Follow it in Archyl
         — I'll post here when it needs you or when it's done.

"Follow it in Archyl" links to the run page, where the plan fills in as a checklist and every tool call shows up in the activity feed. Nobody has to keep it open.

Twenty minutes later the agent hits a decision it shouldn't make alone:

Archyl:  @Marie ❓ The agent has a question:
         > Should retries also cover 4xx responses from receivers, or only
         > 5xx and timeouts?
         Answer in Archyl.

Marie clicks through, picks "only 5xx and timeouts" from the suggested answers, and goes back to what she was doing. When the run ends:

Archyl:  @Marie ✅ The agent finished and opened a pull request:
         https://github.com/acme/payments-api/pull/412
         See the run.

If the profile has Review the plan first switched on, there's one more stop before any code changes: "📋 The agent proposed a plan and is waiting for your review", with a link. If the run fails or hits its time or cost limit, the last message says why, and links the draft pull request that holds the work done so far.

In Slack each of those updates @mentions the person who launched the run, so it lands in their notifications. In Teams the updates arrive as replies in the same thread, without a mention.

What happened between those messages

The thread shows three messages. The run did a good deal more, and that part is the point of this release.

Before it touched a file, the run opened a work session on the architecture elements the task touches, here the webhook sender component inside the Payments API. It took leases on them, so a developer who starts Claude Code on the same component later is told someone is already working there. Its briefing carried the ADRs, conformance rules and API contracts attached to those elements, plus whatever earlier sessions remembered about them. Every file it wrote went through the Guard, which refuses a write that breaks a critical conformance rule. When it finished, its summary became memory on the elements the changed files actually belong to, and any decisions it recorded opened a draft Architecture Change Request for someone to review.

None of that is specific to chat. It's what every Archyl run does. What changed is where the request comes from.

That's the bet behind this feature. A hosted place for an agent to run is becoming something you pick from a list: as we noted two weeks ago, Anthropic, OpenAI and Cursor each offer one now. What a runtime doesn't know is your system: which container the webhook sender belongs to, who owns it, which rule says outbound HTTP goes through the shared client, and which other agent is in there right now. That knowledge lives in the architecture model. Chat is where the work gets asked for. This release connects the two, so a request made in a thread arrives with the context an agent needs to do it well.

Why the run is created as you

When the bot answers a question, it uses the permissions of the admin who connected the workspace. That works for reading. Anyone in the channel gets the same view of the architecture, narrowed per channel if you've scoped it.

Acting is different. A run writes code and opens a pull request. If @Archyl run borrowed the installer's permissions, anyone in a Slack channel could get an agent to change a project they can't edit themselves, and the run history would name the admin for every one of those runs.

So runs are created as the person who typed the command, bounded by that person's edit access to the project. The bot can't tell who a chat user is on Archyl until they say so, which means one step per person, once:

In Archyl, go to Profile → Chat accounts and click Link my Slack account or Link my Microsoft Teams account.
Send the command it shows, @Archyl connect <code>, anywhere the bot is present on that platform.

The code is single-use and valid for 15 minutes, and it was minted by you while signed in, which is what proves the chat account is yours. Slack and Teams are linked separately. @Archyl disconnect removes the link; the bot keeps answering your questions, and stops launching agents for you.

If you skip this and type run anyway, the bot tells you what's missing instead of guessing:

I don't know who you are on Archyl yet, and agents run as the person who asks.
Generate a code in Profile → Chat accounts, then send @Archyl connect <code>.

How the command is read

@Archyl run [Project name] <task>, with two optional pieces.

The project goes in brackets. For now the brackets are required, so the bot never has to guess where your project name ends and the task begins. In a channel scoped to a single project you can leave the project out: @Archyl run fix the flaky login test. A channel scoped to several projects only accepts projects inside its scope. Ask for anything else and the bot says it can't find that project in this channel's scope.

The profile goes before the task. Without one, the run uses your organization's default profile. To pick another, put profile:<name> first:

@Archyl run [Web] profile:frontend-fixer align the pricing cards

A profile name that doesn't exist gets a reply listing the ones that do.

Everything else behaves the way it does in the app. You need edit access to the project. The run counts toward your organization's monthly agent runs, like a run started from Agent Hub → Runs (and, as in the app, organizations on their own AI provider aren't counted). If the profile has Respect other agents' work on and another agent holds a lease on the same elements, the bot replies that the preflight gate refused the run. If the gate only warns, the run is held for approval and the bot links you to it.

Two small things we were careful about

Untrusted text can't ping the room. The task, the project name and the agent's questions all end up quoted back into the channel. Each is escaped for its platform before it's posted, so a task or a question containing <!channel> in Slack, or an <at> mention in Teams, arrives as plain text rather than notifying everyone.

The thread a run reports to isn't something a client can change. Which channel and thread a run posts into is stored on the server when the run is created, not in the run's metadata, which API clients can write. Updates also only go to a workspace connected to the organization that owns the run.

What it doesn't do yet

Plan review and answers happen in Archyl, not in the thread. The bot tells you the agent is waiting and links to the run page. You can't approve a plan or answer a question from Slack or Teams. That matters more than it sounds: a question nobody answers within an hour lets the agent carry on with its own judgment, and a plan nobody reviews within an hour fails the run. The @mention is there so the hour doesn't pass unnoticed.

Project names have to match exactly one project. There's no fuzzy matching, and if two projects share a name the bot asks you to rename one or launch from the app.

Teams updates don't mention you. They're replies in the thread, so how visible they are depends on how you follow that thread.

A pull request needs a supported host. Runs open pull requests on github.com, gitlab.com and bitbucket.org. Bitbucket has no draft pull requests, so a run that fails there pushes its branch without opening one. A repository on a self-hosted Git server gets no pull request, so the final message says the agent finished and links the run.

Try it

Launching runs from chat needs managed agents, which are on the Scale and Custom plans, and a connected Slack or Teams workspace. Link your chat account under Profile → Chat accounts, then pick a thread where someone just asked for something small and well defined, and type @Archyl run.

The full reference, including how permissions and channel scopes apply, is in the docs under Launching agent runs from Slack or Teams.