한 팀이 대화 마흔 개를 동시에 열어 두고 있다고 상상해 보세요. 한 대화에서는 에이전트에게 고객 제안서를 준비해 달라고 합니다. 다른 대화에서는 동료가 납품 일정 추정을 요청합니다. 또 다른 사람은 같은 기능을 이번 달에 출시할 수 있는지 확인합니다.
모든 대화는 배경 설명으로 시작합니다. 고객은 누구인지, 우리가 무엇을 약속했는지, 어제 어떤 결정을 내렸는지 설명합니다. 에이전트들은 일을 시작하지만 서로 다른 일부 정보만 봅니다. 그러다 누군가 제안서에서 약속한 날짜가 개발 논의에서는 이미 제외됐다는 사실을 발견합니다.
그리고 Task가 끝납니다. 그 대화는 조용해집니다. 일주일 뒤 다른 사람이 관련 작업을 시작하며 배경을 다시 설명합니다.
에이전트를 만들면서 우리는 이 장면을 거듭 떠올렸습니다. 다음 작업을 팀이 이미 배운 것에서 시작하고 싶었습니다. 그래서 단일 세션 설계로 나아갔습니다. 지속되는 메인 대화 하나를 두고 독립 Worker들이 개별 Task를 수행합니다.
서브에이전트는 일을 나누는 데 도움을 줍니다. 단일 세션은 다른 질문에 답합니다. 시간이 흘러도 그 일에 대한 이해는 어디에 남을까요? 우리는 두 방식을 함께 씁니다. 메인 대화는 팀의 연속성을 유지하고 Worker는 각 작업을 펼칠 공간을 갖습니다.
개인에서 채널로, 다시 팀으로
Poke는 개인 에이전트에게 간단한 거점을 마련했습니다. 한 사람에게 하나의 대화입니다(2025년 9월). 개인의 이메일, 캘린더, 파일을 문자 대화에 연결했습니다. 답장 초안을 쓰거나 회의 일정을 바꾸는 요청을 이전 요청과 같은 곳에서 시작할 수 있었습니다. 하루의 일이 이어지는 동안 그 대화는 계속 돌아올 수 있는 곳이 됐습니다. 경험의 중심에는 개인과의 관계가 있었고, 우리는 서로 다른 작업 사이에 연속성을 만드는 구체적인 예를 봤습니다.
Claude Tag는 채널 하나에 Claude 하나를 들였습니다(2026년 6월 23일). 누구나 같은 에이전트를 태그하고 작업을 확인하며 동료가 멈춘 곳에서 대화를 이어 갈 수 있었습니다. Claude는 관련 정보를 점차 기억하고 관리자가 허용한 도구를 사용했습니다. 발표에서는 허가된 다른 채널과 정보원에서도 배울 수 있다고 설명했습니다. 우리가 주목한 것은 공유 대화였습니다. 원래 일을 논의하던 곳에서 그대로 일을 맡길 수 있었습니다. 우리의 설계는 여러 논의와 Task에서 정보가 돌아오는 거점을 팀의 메인 대화에 둡니다.
우리는 한 팀에 하나의 대화를 탐색하기로 했습니다. 그 범위는 여러 논의에 걸친 팀의 작업을 따라갑니다. 서로 다른 곳에서 시작한 작업이라도 납품 결정이 고객 제안서에 반영될 수 있습니다.
2026년 4월 28일, 우리는 이전 제품 Bridge에 관한 첫 관련 글을 게시했습니다. 이 탐색은 Poke보다 늦고 Claude Tag보다 이릅니다. 이후 현재 제품 Comma(2026년 10월 1일)에서 작업을 이어 갔으며, 이 설계는 지금 Comma에서 실행됩니다.
DeepSeek Harness도 2026년 10월 31일 Super-agent 탐색을 소개했습니다. 그룹 채팅에서 능동적으로 코드 작업을 따라가는 모습은 조율을 사람에게서 시스템으로 옮긴다는 같은 방향을 보여 줍니다. 이 연구용 프로토타입은 자체 설계를 따릅니다.
DeepSeek의 설계 글 8.4절은 클라우드 침해나 프롬프트 주입으로 연결된 장치가 위험해지는 문제와 모델 컨텍스트를 통한 자격 증명 유출을 열린 문제로 꼽습니다. 콘텐츠가 어디로 가는지에 대해 우리가 운영 중인 답은 IFC입니다. 출처를 선언하고 목적지 독자를 확인하며, 허용되지 않는 전송을 거부하고 필요하면 범위를 정한 사람 승인을 요청합니다.
자격 증명은 별도 경로를 따릅니다. 모델은 자격 증명 참조를 지정하고 실행 계층이 그 값을 해석해 주입합니다. 값은 모델에 반환하지 않습니다.
팀에 남는 것
새 동료가 제안서 작업에 합류한다고 생각해 봅시다. 그 동료는 팀이 계속 사용해 온 같은 메인 대화에 들어옵니다. 공유된 결정을 보고 날짜가 바뀐 이유를 물으며 세 사람에게 세 가지 요약을 받지 않고도 작업을 이어 갑니다. 워크스페이스 멤버십으로 공유 대화에 접근하고, 결정의 근거 자료에는 그 자료 자체의 권한이 계속 적용됩니다.
완료된 Task는 결과와 기록을 유지합니다. 예를 들어 어떤 고객에게 특별한 내보내기 형식이 필요하다는 사실을 알게 됐다고 합시다. 보고서는 Router로 돌아오고 이후 제안서에서 그 발견과 출처를 참조할 수 있습니다. Task가 끝나도 팀에는 배운 것을 다시 찾아갈 곳이 남습니다.
병렬 작업에서는 이 복귀 경로가 중요합니다. 한 Worker는 고객 요구를 읽고 다른 Worker는 기술적 한계를 조사할 수 있습니다. 발견이 여러 번 전달되며 팀에 도착하면 중요한 전제가 사라질 수 있습니다. 각 Task는 발견을 출처와 함께 보고합니다. Router는 같은 메인 컨텍스트에서 이를 받습니다.
그래서 우리는 에이전트 하네스를 두 역할로 나눴습니다. 하나는 팀의 지속적인 대화를 따라가고 다른 역할들은 개별 작업을 수행합니다.
Router와 Worker의 협업
워크스페이스에 상주 Router 하나를 둡니다. Router는 팀의 메인 컨텍스트를 보유하고 요청이 도착하고 결정이 바뀌며 결과가 돌아오는 동안 대화를 따라갑니다. 제안서 요청은 이미 진행 중인 납품 논의와 같은 컨텍스트에 들어옵니다. 모든 입력 메시지는 출처 대화와 메시지 식별 정보를 갖습니다. Router는 여러 논의에서 컨텍스트를 공유하면서 각 입력이 어디서 왔는지 유지합니다.
Router는 명확한 일을 Worker에 넘깁니다. 각 Task는 작업 지시와 인계 내용을 담은 새 Worker 세션에서 시작합니다. 다른 Worker의 기록은 각자의 세션에 남습니다. 여러 Worker가 서로 다른 질문을 동시에 조사할 수 있습니다.
우리는 각 Task에 목표, 목표를 수행할 컨텍스트, 기대하는 결과물을 정합니다. “이 고객을 조사해”에는 불명확한 부분이 많습니다. “고객의 내보내기 요구를 확인하고 출처와 미해결 질문을 첨부해 형식을 제안해”라면 Worker에게는 끝낼 수 있는 일이, Router에게는 활용할 결과가 생깁니다.
제안서에 내보내기 요구 확인과 납품 일정 추정이 모두 필요하다고 합시다. 서로 다른 Worker에게 맡길 수 있습니다. 하나는 고객 요구를, 다른 하나는 추정치와 전제를 반환합니다. Router는 결과를 메인 대화로 가져와 팀이 결정하게 합니다. 끝난 작업에는 돌아올 길이 있습니다.
메인 대화의 답변을 포함해 모든 가시적 답변은 명시적 전송입니다. Router는 목적지를 지정하고 해당 목적지의 검사를 통과합니다. 모델 출력이나 한 턴의 종료가 자동으로 답변을 게시하지는 않습니다. Worker가 보고하거나 다른 참여자에게 말할 때도 같은 규칙을 따릅니다. Task 자료를 읽으면 작업 컨텍스트를 얻고, 전송은 별도 동작으로 처리합니다.
정보 흐름 제어
병렬 Task는 독자 범위가 서로 다른 출처를 모읍니다. 매번 보낼 때 사용한 출처를 선언합니다. 정보 흐름 제어, IFC는 목적지의 독자가 그 출처를 읽을 권한이 있는지 확인합니다.
강제 적용을 켜면 거부된 전송은 이유를 돌려줍니다. 에이전트는 제한된 내용을 제거하고 다시 시도하거나 필요한 범위의 사람 승인을 요청할 수 있습니다. 다시 시도할 때는 출처 선언과 함께 본문도 고쳐야 합니다.
IFC는 답변을 준비하고 공유하는 사이에 팀이 확인할 수 있는 단계를 둡니다.
제안서로 돌아오면 Router는 추정치를 팀에 보여 주고 남은 결정을 물은 뒤 합의된 답을 적절한 채널로 보낼 수 있습니다. Worker의 작업에는 범위가 있습니다. 팀의 대화는 그 인계를 거쳐 계속됩니다.
새 Task는 새 Worker 세션을 엽니다. 세션을 바꿀 때 미완료 작업과 참조를 다음 세션으로 넘깁니다. 팀에는 이전 결정으로 돌아갈 방법도 필요합니다.
팀이 함께 배우는 것
재사용할 절차는 그룹이 공유하는 skill이 됩니다. 편집할 수 있는 지침과 자료입니다. 에이전트가 하는 수정은 만든 에이전트가 관리합니다. 다른 에이전트는 원본을 고치지 않고 사용할 수 있고, 읽기 전용 내장 skill은 복사해서 조정할 수 있습니다. 세션은 자기 범위의 목록을 받고 필요한 지침을 엽니다.
Router는 사람, 환경, 일반 사실, 날짜가 붙은 경험에 대한 지속 기억을 관리합니다. 필요할 때 읽거나 검색합니다. 일반 Worker는 Task 인계 내용으로 일하며, 배정된 Triage Worker는 출처에 연결된 읽기 권한만 갖습니다. 기억 쓰기는 Router가 담당합니다.
Condensed Workspace를 켜면 모든 내부 Router와 Worker 세션이 그룹의 현재 사실을 담은 같은 짧은 목록을 받습니다. 작업 공간 소유자가 직접 편집할 수 있습니다.
에이전트의 갱신은 다른 에이전트에게 유용한 현재 사실인지에 대한 권고성 검사를 받습니다. 수정 버전과 마지막 작성자를 기록합니다. 소유자는 문장을 수정하거나 삭제할 수 있어 공동 전제를 보고 고칠 수 있습니다. 거부된 갱신은 거부 ID를 붙여 다시 시도하면 명시적으로 검사를 재정의할 수 있습니다.
하나의 대화를 유지하는 비용
이 구성은 메인 세션에 부담을 줍니다. Worker들은 병렬로 실행되지만 Router는 결과를 모아야 합니다. 앞선 요청을 처리하는 동안 새 요청이 도착할 수 있습니다. 뒤에 Worker가 아무리 많아도 사람들은 대기열을 경험합니다.
직렬 대기열은 아직 해결 중인 문제입니다. 긴 조사를 위임하면 Router가 응답할 여유가 생기지만 서로 영향을 미치는 결정에는 순서가 필요합니다. 제안서에서는 최종 약속을 내보내기 전에 누군가 납품 날짜를 정해야 합니다. 공유 대화는 그 의존 관계를 더 잘 드러내고 Router에게 일을 진전시킬 책임도 더 부여합니다.
기록에도 비용이 있습니다. 끝난 Task마다 나중에 참고할 정보와 다시는 쓰지 않을 많은 정보가 쌓입니다. 기록이 커질수록 필요한 결정과 그 이유를 찾는 데 더 많은 노력이 듭니다.
동료에게 전체 논의를 다시 설명해 달라고 하지 않아도 이전 결정을 쉽게 찾게 하고 싶습니다. 결정의 이유는 팀에 결정을 바꿔야 할 때를 알려 줍니다.
우리의 탐색은 여기까지 왔습니다. 서로 다른 사람과 Task를 통해 팀은 같은 작업으로 거듭 돌아옵니다. 그래서 우리는 공유 메인 대화를 선택했습니다. 다음에 누군가 관련 논의를 열 때 팀의 앞선 노력이 그 자리에 있기를 바랍니다.
