ElevenAgents Architect 작동 방식

ElevenAgents Architect가 대화 시작 시 알고 있는 정보, 조사 방식, 그리고 질문을 검증된 변경 사항으로 전환하는 방법입니다.

개요

ElevenAgents Architect 대화는 여러분이 구축하는 에이전트를 구동하는 것과 동일한 엔진에서 실시간 ElevenAgents 대화로 실행됩니다. Architect의 도구는 로그인한 세션에서 브라우저를 통해 실행됩니다. 각 도구는 대시보드에서 사용하는 것과 동일한 ElevenAgents API를 호출하므로, 모든 읽기 및 쓰기 작업은 여러분의 권한에 따라 확인됩니다. 권한, 승인 및 초안을 참고하세요.

ElevenAgents Architect가 기본적으로 아는 정보

모든 대화가 시작될 때 Architect는 다음 정보를 받습니다.

계정 및 워크스페이스: 요금제, 워크스페이스 및 사용량
현재 위치: 현재 페이지와 에이전트 내부에 있는 경우 열어 둔 해당 에이전트 및 브랜치. 사이드바에서는 Architect가 페이지의 스냅샷도 받고, 페이지가 변경된 경우 각 메시지 전에 업데이트를 받습니다.
에이전트 요약: 에이전트 내부에 있을 때 ElevenLabs가 생성합니다. 에이전트 이름과 소유자, 브랜치 및 트래픽 분할, 최근 7일간 통화량, 초안 상태, 연결된 에이전트, 절차, 테스트 구성 여부, 편집 가능한 브랜치를 포함합니다.
에이전트 컨텍스트: 에이전트를 구축하는 모든 사람과 공유되는 에이전트의 agents.md 문서입니다. Architect 맞춤 설정을 참고하세요.
환경설정: 구축하는 모든 에이전트에 적용되는 개인 user.md 문서입니다.
진입점에서 전달된 정보: 예를 들어 실패한 테스트, Spotlight 인사이트 또는 분류 티켓입니다. 대화 시작하기를 참고하세요.
이 채팅의 이전 메시지

Architect는 에이전트의 전체 구성, 트랜스크립트, 테스트 결과, Spotlight 데이터 또는 다른 Architect 채팅을 처음부터 가지고 있지 않습니다. 작업에 필요할 때 도구를 사용해 이를 읽습니다. 따라서 각 대화가 집중된 상태로 유지되며, Architect는 오래된 사본이 아닌 최신 데이터를 항상 기반으로 작업합니다.

조사 및 직접 지시

Architect는 두 종류의 요청을 다르게 처리합니다.

직접 지시는 “경쟁사 가격 논의를 차단하는 가드레일을 추가해 줘” 또는 “첫 메시지를 더 짧게 만들어 줘”처럼 변경 사항을 명시합니다. Architect는 관련 구성을 읽고, 편집한 다음 스테이징한 내용을 보고합니다. 기본 승인 모드에서는 에이전트 구성 편집을 묻지 않고 초안에 스테이징합니다. 라이브 트래픽이나 공유 리소스에 영향을 주는 작업은 승인을 기다립니다.

조사는 “환불 통화가 왜 에스컬레이션되나요?” 또는 “환불 해결률을 어떻게 개선하나요?”처럼 해결책을 지정하지 않고 질문합니다. Architect는 변경하기 전에 조사합니다.

조사할 할 일 목록을 작성하며, 항목이 완료되면 작성기 위에 계속 표시됩니다.
개별 트랜스크립트를 읽기 전에 대화 수, 주제, 평가 결과처럼 비용이 적게 드는 신호부터 확인합니다.
대화를 병렬로 분석하고, 발견한 내용을 근본 원인별로 그룹화합니다.
추론 과정이 표시됩니다. 각 추론 단계는 Ns 동안 생각함으로 접혀 있으며 펼칠 수 있습니다.
실제로 읽은 대화 수를 포함하여 발견한 내용을 보고합니다. 표본을 전체 결과인 것처럼 제시하지 않습니다.

계획 모드

더 큰 변경 작업의 경우 작성기를 Plan으로 전환하세요(모드 전환은 Shift+Tab을 누르세요). 계획 모드에서 Architect는 읽기 전용 도구로 조사하고, 작성 과정을 볼 수 있는 계획을 작성한 뒤 Approve plan 또는 Reject를 요청합니다. 승인하기 전에는 아무것도 변경하지 않습니다. 메모와 함께 계획을 거부하면 Architect가 수정한 뒤 다시 요청합니다.

전체 화면 Architect 탭에서는 계획이 작성기 위 패널에 표시됩니다. 사이드바에서는 채팅 내 카드로 표시됩니다.

실습 예시: 환불 해결 개선

이 예시는 폭넓은 질문에서 검토 준비가 된 변경 사항까지 하나의 대화를 따라갑니다. 대화에 표시되는 각 단계와 비교할 수 있도록 도구 이름을 표시했습니다. Architect는 자체적으로 단계를 선택하므로 실제 대화의 순서와 세부사항은 다를 수 있습니다.

에이전트의 Architect 탭에서 보낸 요청입니다.

환불 해결률을 어떻게 개선하나요?

조사 계획 수립

Architect는 문제 측정, 실패한 환불 대화 찾기, 근본 원인 식별, 수정안 제안 및 테스트를 위한 할 일 목록(write_todos)을 작성합니다.

문제 측정

Architect는 에이전트의 주제(get_agent_topics, get_topics_summary)를 읽어 환불 주제와 성공률을 파악한 다음, 평가에 실패한 최근 환불 대화를 집계하고 나열합니다 (count_conversations, list_conversations).

대화 읽기

Architect는 환불 요청 트랜스크립트를 검색하고(search_conversation_messages, semantic_search_conversations), 실패한 대화 묶음을 병렬로 분석합니다 (analyze_conversation_subagent). 각 분석은 사용자가 원한 것, 에이전트가 잘못 처리한 지점, 그리고 그 일이 발생한 턴을 보고합니다.

근본 원인 찾기

Architect는 실패 사례를 현재 구성과 비교합니다(get_agent_config, list_procedures, get_procedure). 예를 들어 다음과 같은 결과를 보고합니다. “실패한 환불 통화 40건 중 31건에서 에이전트는 주문 번호를 묻기 전에 lookup_order를 호출했고, 오류가 발생한 뒤 에스컬레이션했습니다.”

브랜치에서 변경

Architect는 변경 사항을 라이브 에이전트와 분리하기 위해 브랜치를 생성합니다(create_branch). 이후 조회 전에 주문 번호를 묻도록 환불 절차를 편집합니다(update_procedure). 편집 내용은 해당 브랜치의 초안에 스테이징됩니다. 라이브 발신자에게는 아무런 변경이 적용되지 않습니다.

변경 사항 테스트 작성

Architect는 실패 사례를 포착하는 테스트를 작성합니다. 주문 번호 없이 환불을 요청하는 발신자 시뮬레이션 (create_simulation_test), lookup_order가 먼저 호출되지 않는지 확인하는 도구 호출 테스트 (create_tool_test), 실제 실패 대화 중 하나에서 생성한 테스트(generate_test_from_conversation)입니다. Architect는 시뮬레이션에서 부작용이 있는 도구를 모킹하므로 실제 환불은 처리되지 않습니다.

변경 전후 테스트 실행

Architect는 변경 사항이 없는 에이전트를 대상으로 테스트를 실행하고(원래 브랜치에서 run_tests 또는 include_draft: false를 사용한 run_agent_tests), 이후 변경 사항이 포함된 초안을 대상으로 테스트를 실행합니다(run_agent_tests). 그리고 결과를 읽습니다(get_test_suite_summary, get_test_suite_failures). 예상 결과는 새 테스트가 변경 사항 없이는 실패하고 변경 사항을 적용하면 통과하는 것입니다. 테스트가 계속 실패하면 Architect는 실패 내용을 읽고 변경 사항을 조정한 뒤 다시 실행합니다.

변경 사항 제시

Architect는 근본 원인, 변경 사항 및 테스트 결과를 요약하고 게시 대화상자를 엽니다 (request_draft_publish). 차이를 검토하고 Publish를 선택하면 해당 변경 사항이 브랜치의 새 버전으로 커밋됩니다. Architect는 대신 게시할 수 없습니다.

제안 열기

Architect는 브랜치 기록과 병합 미리보기를 읽고(get_branch_history, merge_branch_preview) main으로의 병합 제안을 엽니다(create_merge_proposal). 설명에는 실제 커밋과 테스트 실행을 바탕으로 작성된 Summary, Testing, How to review의 세 섹션이 포함됩니다. Architect가 검토자를 제안할 수는 있지만(suggest_merge_proposal_reviewers), 선택은 여러분이 합니다.

점진적 롤아웃 제안

Architect는 제안이 검토되는 동안 라이브 트래픽의 적은 비율(일반적으로 5%)을 브랜치로 보낼 것을 제안합니다(set_traffic_split). 이는 라이브 트래픽을 변경하므로 승인을 기다립니다.

검증은 게시하거나 검토하도록 요청받기 전에 대화 내에서 수행됩니다. 제안이 검토자에게 도달할 때는 변경의 근거가 된 테스트가 이미 에이전트에 연결되어 브랜치에서 실행된 상태입니다. 검토자에게 표시되는 내용은 제안 및 검증을 참고하세요.

변경 전후 테스트 실행은 권장되는 방식이지만, Architect가 모든 변경에 자동으로 실행하지는 않습니다. 확실히 실행하려면 예를 들어 “새 테스트가 main에서는 실패하고 브랜치에서는 통과하는 것을 보여 줘”처럼 직접 요청하세요.

Architect 작업 추적 — Architect가 수행한 각 도구 호출이 포함된 요청 작업 추적

슬래시 명령어

작성기에서 /를 입력하면 현재 페이지에서 사용할 수 있는 명령어를 볼 수 있습니다.

명령어	기능
`/start`	Architect가 목표를 알 수 있도록 이 에이전트의 컨텍스트(`agents.md`)를 설정합니다.
`/generate`	설명을 바탕으로 새 에이전트를 생성합니다.
`/debug`	최근 실패한 대화를 디버깅합니다.
`/test`	테스트를 실행하고 결과를 요약합니다.
`/explain`	이 에이전트가 하는 일을 쉬운 말로 설명합니다.
`/optimize`	프롬프트 및 구성 개선 사항을 제안합니다.
`/review`	에이전트 성능을 검토하고 개선 사항을 찾습니다.
`/branch`	이 에이전트의 새 브랜치를 생성합니다.
`/experiment`	브랜치를 생성하고 A/B 테스트로 배포합니다.
`/rollback`	최근 구성 변경을 검토하고 필요하면 되돌립니다.
`/remember`	에이전트 정보를 지식 베이스 문서로 저장합니다.
`/dashboard`	채팅에서 맞춤 분석 대시보드를 구축합니다.
`/clear`	이 대화를 지우고 새로 시작합니다.
`/feedback`	이 세션에 대한 비공개 피드백을 ElevenLabs에 보냅니다.

대부분의 명령어는 에이전트 내부에 있을 때만 적용됩니다. /clear 및 /feedback은 Architect 탭 홈 페이지에서 사용할 수 없습니다.

채팅 내 대시보드

Architect는 “이번 주 에스컬레이션을 이유별로 분류하고 추세를 보여 줘”처럼 데이터로 질문에 답하는 대시보드를 대화 내에서 구축할 수 있습니다. /dashboard를 사용하거나 직접 요청하세요.

Architect는 도구로 데이터를 수집하고 코드로 형태를 만든 다음, Spotlight와 동일한 지표 타일, 차트, 목록, 텍스트 카드로 구성된 대시보드를 렌더링합니다. 대시보드에는 다음이 포함될 수 있습니다.

헤드라인 값, 변화량, 스파크라인이 포함된 지표 타일
상위 N개 분석을 위한 영역, 선, 막대, 누적 영역, 도넛, 순위 막대 목록 등의 차트
상태 라벨, 날짜, 개별 대화 같은 ElevenAgents 페이지 링크가 포함된 목록
결과 및 권장 사항을 위한 텍스트 카드

전체 화면 Architect 탭에서는 대시보드가 대화 안에 인라인으로 렌더링됩니다. 사이드바에서는 채팅 옆 패널로 열립니다.

대시보드 데이터는 생성된 브라우저 탭의 메모리에만 유지되며 채팅과 함께 저장되지 않습니다. 페이지를 새로고침하거나 다른 탭에서 채팅을 열거나 여러 개의 큰 대시보드를 만들면, 이전 대시보드는 데이터 대신 메시지를 표시합니다. Architect에게 다시 만들도록 요청하세요. 대시보드는 읽기 전용 스냅샷입니다. 필터가 없고 실시간으로 업데이트되지 않습니다.

코드 실행

Architect는 예를 들어 수백 개 대화의 주별 해결률을 계산하기 위해 도구의 데이터를 집계, 그룹화, 비교하는 짧은 Python 프로그램을 실행할 수 있습니다. 코드는 Python 표준 라이브러리만 포함된 브라우저 샌드박스에서 실행됩니다. 네트워크 액세스나 ElevenLabs 계정 액세스 권한이 없으며, 시간 제한은 20초입니다. 코드 실행 기능은 점진적으로 배포 중이며 모든 워크스페이스에서 이용하지 못할 수 있습니다.

대용량 응답

긴 대화 목록처럼 도구가 대화에 담을 수 있는 것보다 많은 데이터를 반환하면, Architect는 전체 응답을 브라우저 탭의 메모리에 보관하고 요약을 기반으로 작업합니다. 필요할 때 나머지 내용을 검색하고 읽을 수 있습니다. 이 경우 도구 호출에 표시되는 알림으로 확인할 수 있습니다. 이러한 응답은 저장되거나 업로드되지 않습니다.