Slack과 Teams에서 에이전트에게 일을 넘기기

오전 중반, #payments의 한 스레드. 누군가 @Archyl에게 webhook sender를 호출하는 것이 무엇인지 묻고, 봇이 답합니다. Checkout과 Billing container이며, 둘 다 Payments API를 거친다고요. 메시지 두 개 뒤에는 이런 스레드가 늘 끝나는 한마디가 옵니다. "거기 재시도 넣어야겠네요, 누가 맡아 줄 수 있어요?"

그러고 나면 스레드는 조용해집니다. 누군가 Archyl을 열고, 프로젝트를 찾고, 에이전트 프로필을 고르고, 메시지 세 개 위에 한 글자도 다르지 않게 이미 적혀 있는 작업을 다시 타이핑해야 합니다.

6월부터 Archyl 봇은 Slack과 Microsoft Teams에서 질문에 답해 왔습니다. 오늘부터는 행동도 할 수 있습니다. 같은 스레드에서 관리형 에이전트에게 일을 넘길 수 있습니다.

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

에이전트는 이 명령을 입력한 사람으로서 실행되고, 봇은 pull request가 생길 때까지 스레드에서 실행을 따라갑니다.

스레드 하나로, 처음부터 끝까지

앞의 대화는 이렇게 이어집니다. Archyl의 메시지는 봇이 실제로 게시하는 형식입니다. 이름, 질문, pull request는 예시입니다.

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"은 실행 페이지로 연결됩니다. 거기서는 계획이 체크리스트로 채워지고, 모든 도구 호출이 활동 피드에 나타납니다. 누구도 그 페이지를 열어 둘 필요는 없습니다.

20분 뒤, 에이전트가 혼자 내려서는 안 되는 결정에 부딪힙니다.

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

Marie는 링크를 눌러 제안된 답변 중에서 "only 5xx and timeouts"를 고르고, 하던 일로 돌아갑니다. 실행이 끝나면 이렇게 옵니다.

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

프로필에서 계획 먼저 검토가 켜져 있으면, 코드가 바뀌기 전에 한 번 더 멈춥니다. "📋 The agent proposed a plan and is waiting for your review"라는 메시지가 링크와 함께 옵니다. 실행이 실패하거나 시간 또는 비용 한도에 도달하면, 마지막 메시지가 그 이유를 알려 주고 그때까지 한 작업을 담은 초안 pull request로 연결합니다.

Slack에서는 이런 업데이트마다 실행을 시작한 사람을 @멘션하므로, 그 사람의 알림에 도착합니다. Teams에서는 업데이트가 멘션 없이 같은 스레드의 답글로 도착합니다.

메시지 사이에 일어난 일

스레드에는 메시지 세 개가 보입니다. 실행은 그보다 훨씬 많은 일을 했고, 이번 릴리스의 핵심은 바로 그 부분입니다.

파일을 건드리기 전에, 실행은 작업이 관련된 아키텍처 요소, 여기서는 Payments API 안의 webhook sender component에 대해 작업 세션을 열었습니다. 그 요소들에 리스를 잡았기 때문에, 나중에 같은 component에서 Claude Code를 시작하는 개발자는 이미 누군가 거기서 작업 중이라는 안내를 받습니다. 브리핑에는 그 요소들에 연결된 ADR, 적합성 규칙, API 계약과 함께, 이전 세션들이 그 요소에 대해 기억해 둔 내용이 담겨 있었습니다. 실행이 쓴 모든 파일은 Guard를 거쳤고, Guard는 critical 적합성 규칙을 어기는 쓰기를 거부합니다. 작업을 마치자 요약은 변경된 파일이 실제로 속한 요소의 메모리가 되었고, 기록한 결정은 각각 Architecture Change Request(아키텍처 변경 요청) 초안을 열어 누군가 검토할 수 있게 했습니다.

이 중 채팅에만 해당하는 것은 없습니다. 모든 Archyl 실행이 하는 일입니다. 달라진 것은 요청이 어디서 오느냐입니다.

이것이 이 기능에 건 베팅입니다. 에이전트를 돌릴 호스팅된 장소는 목록에서 고르는 것이 되어 가고 있습니다. 2주 전에 짚었듯이, 이제 Anthropic, OpenAI, Cursor가 각각 하나씩 제공합니다. 런타임이 모르는 것은 당신의 시스템입니다. webhook sender가 어느 container에 속하는지, 누가 담당하는지, 어떤 규칙이 나가는 HTTP는 공용 클라이언트를 거치라고 정하는지, 그리고 지금 그 안에서 어떤 다른 에이전트가 작업 중인지. 그 지식은 아키텍처 모델 안에 있습니다. 일이 요청되는 곳은 채팅입니다. 이번 릴리스는 둘을 연결해, 스레드에서 나온 요청이 에이전트가 일을 잘 해내는 데 필요한 컨텍스트를 갖고 도착하게 합니다.

실행이 당신으로서 만들어지는 이유

봇이 질문에 답할 때는 워크스페이스를 연결한 관리자의 권한을 씁니다. 읽기에는 그것으로 충분합니다. 채널에 있는 모두가 같은 아키텍처 뷰를 얻고, 채널별로 범위를 지정했다면 그 범위로 좁혀집니다.

행동은 다릅니다. 실행은 코드를 쓰고 pull request를 엽니다. @Archyl run이 봇을 설치한 사람의 권한을 빌린다면, Slack 채널에 있는 누구든 자신은 편집할 수 없는 프로젝트를 에이전트에게 바꾸게 할 수 있고, 실행 기록에는 그 모든 실행에 관리자의 이름이 남게 됩니다.

그래서 실행은 명령을 입력한 사람으로서 만들어지고, 그 사람의 프로젝트 편집 권한 안으로 제한됩니다. 채팅 사용자가 Archyl에서 누구인지는 본인이 알려 주기 전까지 봇이 알 수 없습니다. 그래서 사람마다 한 번씩, 한 단계가 필요합니다.

Archyl에서 프로필 → 채팅 계정으로 가서 내 Slack 계정 연결 또는 내 Microsoft Teams 계정 연결을 클릭합니다.
표시된 명령 @Archyl connect <code>를 그 플랫폼에서 봇이 있는 곳 어디에서든 보냅니다.

코드는 한 번만 쓸 수 있고 15분 동안 유효하며, 로그인한 상태의 당신이 직접 발급한 것입니다. 그것이 채팅 계정이 당신의 것이라는 증명이 됩니다. Slack과 Teams는 따로 연결합니다. @Archyl disconnect로 연결을 해제할 수 있습니다. 해제해도 봇은 계속 질문에 답하지만, 당신으로서 에이전트를 시작하지는 않습니다.

이 단계를 건너뛰고 그냥 run을 입력하면, 봇은 추측하지 않고 무엇이 빠졌는지 알려 줍니다.

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>.

명령을 읽는 방식

@Archyl run [Project name] <task>, 여기에 선택 사항이 두 가지 있습니다.

프로젝트는 대괄호 안에 넣습니다. 지금은 대괄호가 필수입니다. 그래야 봇이 프로젝트 이름이 어디서 끝나고 작업이 어디서 시작되는지 추측할 필요가 없습니다. 하나의 프로젝트로 범위가 지정된 채널에서는 프로젝트를 생략할 수 있습니다: @Archyl run fix the flaky login test. 여러 프로젝트로 범위가 지정된 채널은 그 범위 안의 프로젝트만 받습니다. 다른 프로젝트를 요청하면 봇은 이 채널의 범위에서 그 프로젝트를 찾을 수 없다고 답합니다.

프로필은 작업 앞에 둡니다. 지정하지 않으면 실행은 조직의 기본 프로필을 사용합니다. 다른 프로필을 고르려면 profile:<name>을 맨 앞에 둡니다.

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

존재하지 않는 프로필 이름을 쓰면, 존재하는 프로필 목록이 답으로 옵니다.

나머지는 모두 앱에서와 똑같이 동작합니다. 프로젝트에 대한 편집 권한이 필요합니다. 실행은 에이전트 허브 → 실행 목록에서 시작한 실행과 마찬가지로 조직의 월간 에이전트 실행 수에 포함됩니다(앱과 마찬가지로, 자체 AI 제공자를 쓰는 조직은 집계되지 않습니다). 프로필에서 다른 에이전트의 작업 존중이 켜져 있고 다른 에이전트가 같은 요소에 리스를 잡고 있으면, 봇은 프리플라이트 게이트가 실행을 거부했다고 답합니다. 게이트가 경고만 하는 경우에는 실행이 승인 대기로 보류되고, 봇이 그곳으로 가는 링크를 줍니다.

신경 쓴 작은 두 가지

신뢰할 수 없는 텍스트로 채널 전체에 알림을 보낼 수 없습니다. 작업, 프로젝트 이름, 에이전트의 질문은 모두 인용되어 채널로 돌아옵니다. 각각은 게시되기 전에 플랫폼에 맞게 이스케이프되므로, Slack의 <!channel>이나 Teams의 <at> 멘션이 들어 있는 작업이나 질문은 모두에게 알림을 보내는 대신 일반 텍스트로 도착합니다.

실행이 보고하는 스레드는 클라이언트가 바꿀 수 있는 것이 아닙니다. 실행이 어느 채널과 스레드에 게시할지는 실행이 만들어질 때 서버에 저장됩니다. API 클라이언트가 쓸 수 있는 실행의 메타데이터에 저장하지 않습니다. 또한 업데이트는 그 실행을 소유한 조직에 연결된 워크스페이스로만 갑니다.

아직 하지 못하는 것

계획 검토와 답변은 스레드가 아니라 Archyl에서 합니다. 봇은 에이전트가 기다리고 있다고 알리고 실행 페이지로 연결합니다. Slack이나 Teams에서 계획을 승인하거나 질문에 답할 수는 없습니다. 이 점은 생각보다 중요합니다. 한 시간 안에 아무도 답하지 않은 질문은 에이전트가 자기 판단으로 계속 진행하게 하고, 한 시간 안에 아무도 검토하지 않은 계획은 실행을 실패시킵니다. @멘션은 그 한 시간이 아무도 모르게 지나가지 않도록 하기 위한 것입니다.

프로젝트 이름은 정확히 하나의 프로젝트와 일치해야 합니다. 퍼지 매칭은 없으며, 두 프로젝트가 같은 이름을 쓰면 봇은 하나의 이름을 바꾸거나 앱에서 시작해 달라고 요청합니다.

Teams 업데이트는 당신을 멘션하지 않습니다. 스레드 안의 답글이므로, 얼마나 눈에 띄는지는 그 스레드를 어떻게 팔로우하고 있느냐에 달려 있습니다.

pull request에는 지원되는 호스트가 필요합니다. 실행은 github.com, gitlab.com, bitbucket.org에서 pull request를 엽니다. Bitbucket에는 초안 pull request가 없으므로, 거기서 실패한 실행은 pull request를 열지 않고 브랜치만 push합니다. 자체 호스팅 Git 서버에 있는 저장소에는 pull request가 만들어지지 않으므로, 마지막 메시지는 에이전트가 끝났다고 알리고 실행으로 연결합니다.

써 보기

채팅에서 실행을 시작하려면 Scale과 Custom 플랜에서 제공되는 관리형 에이전트와, 연결된 Slack 또는 Teams 워크스페이스가 필요합니다. 프로필 → 채팅 계정에서 채팅 계정을 연결한 다음, 누군가 작고 명확한 일을 막 요청한 스레드를 골라 @Archyl run을 입력해 보세요.

권한과 채널 범위가 어떻게 적용되는지를 포함한 전체 레퍼런스는 Slack 및 Teams 봇 문서의 "Slack 또는 Teams에서 에이전트 실행 시작하기" 섹션에 있습니다.