Amazon Bedrock Web Answer, 웹 리서치를 단일 에이전트 도구로 통합

AWS는 2026년 11월 5일 Amazon Bedrock Web Answer를 출시했다. 이 서비스는 에이전트가 별도의 검색 단계 없이 단 한 번의 도구 호출로 출처가 포함된 응답을 받을 수 있게 한다. 이 서비스는 에이전트 구축과 운영을 위한 AWS 플랫폼인 Amazon Bedrock AgentCore를 통해 정식 출시됐다. 당면한 의미는 정보를 찾는 일과 답변을 제시하는 일 사이의 작업을 누가 담당하느냐에 있다.

개발자에게 익숙한 대안은 검색 결과, 페이지 추출, 모델 지침, 인용 처리를 결합하는 방식이다. Web Answer는 이 순서를 관리형 인터페이스 뒤로 옮긴다. 그 대가는 제어권이다. 팀은 리서치 실행을 AWS에 맡기는 대신, 애플리케이션이 그 결과를 사용하는 방식에 대한 책임은 계속 진다.

Google과 Anthropic은 이미 웹 연결형 답변 기능을 제공하고 있어, 이는 확립된 제품 방향의 일부다. AWS의 기여는 완성된 답변을 자사 에이전트 인프라 안에 배치한다는 점이다. 이에 따라 아키텍처 결정은 검색 제공업체 선택에서 벗어나, 어떤 리서치 작업에 별도의 맞춤형 구현이 필요한지를 판단하는 문제로 이동한다.

Amazon Bedrock Web Answer가 통합 단위를 바꾸는 방식

이 제품은 에이전트가 받는 것을 바꾼다. 추가 종합 단계가 필요한 자료가 아니라 출처가 포함된 답변을 제공한다.

Web Answer 출시 발표에 따르면, 이 서비스는 AWS가 6월에 도입한 AgentCore의 Web Search를 확장한다. AWS는 Web Answer가 검색을 계획하고, 여러 검색을 동시에 실행하며, 수집한 근거가 응답을 뒷받침하기에 충분한지 판단한다고 설명한다. 이 서비스는 미국 동부 버지니아 북부에서 출시됐다.

그라운딩은 생성된 응답을 이를 뒷받침하는 정보와 연결하는 것을 뜻한다. 이 경우 AWS는 개발자가 각 단계를 조립하도록 두는 대신, 리서치 프로세스와 함께 그라운딩을 묶어 제공한다.

이 패키징이 중요한 이유는 검색과 답변 사이의 경계가 종종 애플리케이션 유지보수 문제가 되기 때문이다. 검색 결과는 관련성이 있어도 충분한 근거를 담지 못할 수 있다. 가져온 페이지에는 답이 있을 수 있지만, 그 주변에 관련 없는 자료가 섞여 있을 수 있다.

그러면 개발자는 구절 선택, 상충하는 진술 해결, 추가 검색 필요 여부를 정하는 규칙이 필요하다. 이런 결정은 기본 모델이 바뀌지 않아도 최종 응답에 영향을 미친다.

그 작업을 위임하면 엔지니어링의 출발점이 달라진다. 애플리케이션은 질문을 던지고 반환된 답변을 평가한다. 더 이상 중간 리서치 결정마다 별도의 구현이 필요하지 않다.

공개적으로 문서화된 제품 정책에 관한 질문을 처리하는 예시 고객 지원 어시스턴트를 생각해 보자. 맞춤형 워크플로는 정책을 찾고, 이를 가져오며, 해석한 뒤, 그 결론을 적절한 출처와 연결해야 한다.

관리형 답변 도구는 이러한 활동을 서비스 경계 뒤로 옮긴다. 지원 애플리케이션은 여전히 응답이 고객의 상황에 맞는지 판단한다. 또한 사람이 답변을 검토해야 하는지도 결정한다.

이 구분은 공개 리서치가 더 큰 워크플로의 작은 일부일 때 특히 중요하다. 예를 들어 보고서를 작성하는 에이전트는 내부 분석을 계속하기 전에 최신 사실관계를 확인해야 할 수 있다.

이 경우 전체 리서치 하위 시스템을 구축하는 일은 작업에 비해 과도해질 수 있다. 완성된 답변은 더 넓은 애플리케이션이 점검하고 사용할 수 있는 제한된 기여를 제공한다.

그렇다고 관리형 답변이 더 나은 리서치를 만든다는 뜻은 아니다. 이는 개발자가 구현해야 하는 계층과 평가해야 하는 계층을 바꾼다.

이것이 Amazon Bedrock Web Answer의 핵심 사건이다. AWS는 기존에 팀이 검색 결과를 중심으로 조립해야 했던 리서치 기능을 운영하겠다고 제안하고 있다.

실질적인 질문은 반환된 답변이 애플리케이션의 목적에 충분한 가시성을 제공하느냐다. 일반적인 지원 응답과 중요한 비즈니스 권고에는 서로 다른 기준이 필요하다.

따라서 개발자는 통합 지름길을 얻지만, 보편적인 수용 규칙을 받는 것은 아니다. 제품은 답변 인터페이스를 제공하며, 애플리케이션은 여전히 그 답변을 사용할 수 있게 만드는 조건을 정의해야 한다.

검색 파이프라인을 유지하는 팀에 가해지는 압박

관리형 답변의 가장 강력한 근거는 제품 차별화에 거의 기여하지 않는 유지보수 작업에서 나온다.

검색 파이프라인은 정보를 찾고 모델을 위해 준비하는 일련의 과정이다. 이를 유지하는 팀은 성공적인 데모를 넘어서는 동작까지 지원해야 한다.

출처의 레이아웃은 바뀐다. 관련 정보는 예상치 못한 위치에 나타난다. 검색 결과는 원래 발표가 아니라 해설을 가리킨다. 응답은 중요한 단서를 빠뜨린 채 완전해 보일 수 있다.

이는 일상적인 엔지니어링 문제지만, 에이전트의 수명 전반에 걸쳐 누적된다. 새로운 질문 범주마다 선택, 추출 또는 출처 표기의 다른 약점이 드러날 수 있다.

AWS의 제안은 팀이 왜 계속해서 그러한 단계를 직접 소유해야 하는지 설명하도록 압박한다. 그 답은 맞춤형 검색이 사용자가 실제로 필요로 하는 무언가를 제공하는지에 달려 있다.

특화된 리서치 제품에는 출처 순위와 문서 선택에 대한 세밀한 제어가 필요할 수 있다. 가끔 공개 질문에 답하는 비즈니스 애플리케이션은 운영 작업 감소를 더 높게 평가할 수 있다.

이 차이는 제품 기능과 지원 인프라를 구분한다. 리서치 자체가 제품이라면, 그 내부 결정은 경쟁 우위가 될 수 있다.

리서치가 다른 작업을 지원하는 역할이라면, 같은 장치를 유지하는 것은 사용자의 핵심 경험을 개선하지 못하면서 노력을 소모할 수 있다. 관리형 답변은 팀이 그 노력을 배분할 또 다른 방식을 제공한다.

이 압박은 애플리케이션 설계자에게도 미친다. 답변 요청이 쉬워지면 제품은 더 많은 워크플로에 공개 리서치를 도입할 수 있다.

이는 리서치가 상호작용에 언제 포함돼야 하는지를 결정해야 하는 새로운 책임을 만든다. 외부 정보를 자동으로 추가하면 사용자의 자체 문서에 의존하는 작업에서 주의가 분산될 수 있다.

예를 들어 내부 계획 어시스턴트는 기밀 프로젝트 메모와 함께 최신 공개 제품 정보가 필요할 수 있다. 애플리케이션은 각 기여의 출처와 권위를 구분해야 한다.

공개 답변이 내부 결정에 대한 근거가 되어서는 안 된다. 반대로 내부 맥락을 독립적으로 검증된 공개 정보처럼 제시해서도 안 된다.

이 구분은 공개 리서치와 개인 지식 기반 사이의 더 넓은 분리와 닮아 있다. 둘 다 답변에 정보를 제공할 수 있지만, 서로 다른 정보 요구를 충족한다.

따라서 구매자에게 평가 질문은 데모가 유창한 텍스트를 생성하는지를 넘어선다. 어떤 유지보수 책임이 사라지고 어떤 책임이 팀에 남는지를 이해해야 한다.

관리형 서비스는 구현 작업을 줄일 수 있지만, 애플리케이션 통합, 접근 결정, 응답 검토는 그대로 남는다. 이러한 잔여 작업은 도입 평가에 포함돼야 한다.

조직적 결과도 있다. 리서치가 관리형 인터페이스 뒤로 이동하면, 누군가가 명시적으로 답변 품질을 책임지지 않는 한 책임이 덜 보일 수 있다.

인프라 엔지니어는 요청이 성공하는지 검증할 수 있다. 제품 팀은 응답이 사용자의 업무 완료에 도움이 되는지 판단해야 한다. 분야 전문가는 종합 과정에서 단서가 유지되는지 평가해야 할 수 있다.

가장 강력한 도입 근거는 서비스가 제거하는 구체적 작업량과 구체적 부담을 제시한다. 리서치 복잡성을 없앤다는 광범위한 주장은 여전히 중요한 작업을 가린다.

AgentCore Gateway 통합, 접근과 답변을 분리하다

이 통합은 리서치 실행을 도구 경계 뒤로 옮기면서도, 누가 이를 호출할 수 있는지에 관한 결정은 별도로 유지한다.

AgentCore Gateway는 연결된 에이전트에 도구를 노출하는 구성 요소다. Model Context Protocol, 즉 MCP는 이들 에이전트가 도구를 발견하고 호출할 수 있는 표준 방식을 제공한다.

integration walkthrough에서 AWS는 Gateway 서비스 역할에 bedrock-agentcore:InvokeWebAnswer 권한을 부여하는 방법을 설명한다. 이후 관리자는 connectorId: "web-answer"를 사용해 커넥터 대상을 추가하고, 상태가 READY가 될 때까지 기다린다.

연결된 에이전트는 tools/list를 통해 도구를 발견하고 tools/call을 통해 이를 호출한다. AWS의 예시는 에이전트 개발 프레임워크인 Strands를 사용해 요청을 수행한다.

이 세부 사항은 애플리케이션에서 리서치 서비스까지의 경로를 보여 준다. 또한 도구 추가가 질문 문자열을 제공하는 것 이상을 포함하는 이유도 보여 준다.

호출자는 Gateway에 도달할 권한이 필요하다. Gateway는 관리형 백엔드를 호출할 별도의 권한이 필요하다. 이러한 관계를 혼동하면 문제 해결이 어려워지고 지나치게 광범위한 접근 권한이 생길 수 있다.

구현 팀은 이러한 경계를 따라 요청을 검토하는 것이 합리적이다. 애플리케이션이 의도한 Gateway에 도달하는지, 구성된 대상이 예상한 기능을 노출하는지 확인해야 한다.

그다음 에이전트가 적절한 질문에 도구를 선택하는지 검증해야 한다. 주변 에이전트가 대신 기억에 의존해 답변한다면, 올바르게 구성된 커넥터도 큰 가치를 제공하지 못한다.

반대 문제도 주의할 필요가 있다. 모든 요청에 외부 리서치를 호출하는 에이전트는 불필요한 대기와 관련 없는 정보를 초래할 수 있다.

따라서 AgentCore Gateway 통합은 인증 문제와 함께 도구 선택 문제를 만든다. 개발자는 최신 공개 근거가 언제 작업을 개선하는지 정의해야 한다.

AWS의 대상 구성 가이드는 관리형 기능을 노출하는 데 사용되는 커넥터 구성을 문서화한다. 이는 Gateway 대상이 에이전트의 도구 인터페이스와 서비스를 연결하는 구성 지점임을 뜻한다.

아키텍처상 의미는 관심사의 분리다. 애플리케이션은 기본 에이전트 동작을 유지하면서, 별도 기능을 통해 리서치 답변을 얻을 수 있다.

이 분리는 집중된 평가를 지원한다. 팀은 주변 에이전트가 최종 응답에 이를 어떻게 반영하는지 평가하기 전에 리서치 결과를 점검할 수 있다.

오류는 서로 다른 단계에서 들어올 수 있기 때문에 유용하다. 리서치 도구가 불완전한 답변을 반환할 수도 있고, 애플리케이션이 적절한 답변을 잘못 표현할 수도 있다.

이를 별개의 실패로 취급하면 팀이 올바른 해결책을 선택하는 데 도움이 된다. 외부 에이전트를 조정해도 반환된 답변 내부에서 빠진 근거를 신뢰성 있게 보완할 수는 없다.

마찬가지로 인용을 숨기거나 중요한 단서를 누락하는 인터페이스 문제는 리서치 설정을 바꾼다고 해결되지 않는다. 사용자에게는 전체 경로가 중요하다.

따라서 통합은 접근, 호출, 반환된 근거, 해석, 제시라는 책임 사슬로 검토해야 한다. 관리형 도구는 이 사슬의 일부를 차지한다.

그 가치는 팀이 평가할 수 있는 명확한 리서치 경계를 제공하는 데 있다. 그렇다고 그 경계 주변의 애플리케이션을 이해할 필요가 사라지는 것은 아니다.

Web Answer와 Web Search의 차이는 제어에 관한 결정

선택은 애플리케이션이 완성된 결론을 필요로 하는지, 아니면 그 결론에 도달하는 데 사용된 자료를 직접 제어해야 하는지에 달려 있습니다.

Web Answer와 Web Search의 중요한 차이는 종합 결과의 소유권에 있습니다. 종합은 검색된 근거를 하나의 응답으로 결합하는 과정입니다.

검색 인터페이스는 애플리케이션에 처리할 자료를 제공합니다. 답변 인터페이스는 애플리케이션이 검토하고 통합할 수 있는 결론을 제공합니다.

어느 접근 방식도 모든 작업에 자동으로 적합하지는 않습니다. 목표가 분명한 사실 질문은 새로운 근거가 나타날 때마다 방향이 바뀌는 탐색적 조사와 다릅니다.

범위가 좁은 질문에는 완성된 답변이 유용한 종료 지점을 제공할 수 있습니다. 이를 둘러싼 에이전트는 응답을 검토하고 더 큰 작업을 계속할 수 있습니다.

조사의 경우 중간 근거는 결론만큼 중요할 수 있습니다. 연구자는 상충하는 설명을 비교하거나 초기 전제를 반박하는 문서를 살펴보고자 할 수 있습니다.

맞춤형 검색은 모델이 무엇을 볼지에 관한 작업별 결정도 가능하게 합니다. 애플리케이션이 정의된 조사 절차를 재현해야 할 때 이러한 제어가 중요합니다.

관리형 답변은 그러한 결정의 더 많은 부분을 위임합니다. 구현 작업을 줄인다는 장점이 있지만, 조사 과정에 직접 관여하는 정도는 낮아진다는 한계가 있습니다.

이 때문에 Web Answer와 Web Search를 새로운 도구와 오래된 도구 간의 경쟁으로 볼 필요는 없습니다. 두 방식은 서로 다른 추상화 수준을 제공합니다.

Google의 search grounding은 Gemini가 검색 쿼리를 생성하고, 결과를 처리하며, 인용이 포함된 응답을 생성하도록 합니다. 해당 문서는 모델이 검색이 답변을 개선할지 여부를 결정하는 워크플로를 설명합니다.

Anthropic의 web search tool도 마찬가지로 Claude에 최신 웹 콘텐츠 접근 권한을 제공하고 인용을 반환합니다. 해당 문서는 도메인 제어와 선택적 필터링 기능도 설명합니다.

이러한 제품은 유용한 경쟁 맥락을 제공하지만, 존재 자체가 동등한 성능을 입증하지는 않습니다. 각 인터페이스와 주변 플랫폼은 서로 다른 통합 결정을 만들어 냅니다.

이미 AgentCore를 사용 중인 팀에게 AWS의 접근 방식은 에이전트 인프라에서 사용하는 일반적인 도구 경계와 같은 방식으로 조사 기능을 제공합니다.

다른 스택을 사용하는 팀에게 새로운 인프라 의존성을 도입하려면 그 자체로 정당화가 필요합니다. 사용자에게 비슷하게 보이는 기능이 유사한 운영 요구 사항을 의미하는 것은 아닙니다.

따라서 관련 비교는 워크로드에서 시작해야 합니다. 어떤 질문에 최신 출처가 필요한가? 애플리케이션은 얼마나 많은 근거를 공개해야 하는가? 불확실한 결과는 누가 검토하는가?

짧은 사실 응답을 생성하는 제품은 탐사 보고서를 생성하는 제품과 다른 아키텍처를 선호할 수 있습니다. 이 차이는 조달 및 엔지니어링 검토 과정에서도 분명하게 유지되어야 합니다.

Amazon Bedrock Web Answer는 이러한 결정 과정에 하나의 선택지를 추가합니다. 맞춤형 검색 워크플로를 유지해야 하는 이유를 없애지는 않습니다.

실용적인 아키텍처는 범용적인 선택을 강요하기보다 작업을 분리할 수도 있습니다. 일상적인 확인과 개방형 조사가 반드시 같은 조사 방법을 공유할 필요는 없습니다.

가장 강력한 결정은 위임이 도움이 되는 지점과 직접 제어가 계속 필요한 지점을 식별합니다. 이는 모든 웹 연결 작업이 그 경계 뒤에 있어야 한다고 가정하는 대신 제품 경계를 따르는 접근 방식입니다.

인용은 답변을 검토 가능하게 만들지만, 자동으로 정확하게 만들지는 않습니다

출처 링크는 검증 경로를 만들지만, 해당 출처가 모든 결론을 뒷받침한다는 사실을 보장하지는 않습니다.

AWS의 Web Answer documentation은 인라인 인용이 포함된 Markdown 답변과 구조화된 인용 정보를 설명합니다. 또한 애플리케이션이 사용자에게 결과를 표시할 때 제공된 인용을 보존하고 표시해야 한다고 요구합니다.

문서는 요청 수준 필터가 확장할 수 없는 관리자 도메인 경계를 설명합니다. 또한 지원되는 지리적 경계 내에서 지역 간 추론을 사용해 처리한다고 명시합니다.

이러한 세부 사항은 팀이 편의성과 제어를 해석하는 방식에 영향을 줍니다. 구조화된 답변을 받으면 애플리케이션이 근거를 제시하는 데 도움이 되지만, 제시는 여전히 구현의 일부입니다.

인용은 관련 페이지를 가리킬 수 있지만 문장 일부만 뒷받침할 수 있습니다. 출처가 더 이상 적용되지 않는 이전 정책을 정확하게 설명할 수도 있습니다.

요약은 실질적인 의미를 바꾸는 예외를 생략할 수 있습니다. 이러한 문제는 허구의 출처나 눈에 띄게 손상된 링크가 없어도 발생할 수 있습니다.

따라서 평가는 주장과 근거 간의 관계를 검토해야 합니다. 인용 수를 세는 것은 인용의 존재를 측정할 뿐, 응답을 정당화하는지는 측정하지 않습니다.

예시적인 정책 지원 도구의 경우, 검토자는 인용된 문서가 요청된 관할권과 상황에 적용되는지 물어야 합니다. 일반적인 진술은 정확할 수 있지만 잘못된 질문에 답할 수 있습니다.

날짜 제어는 조사 범위를 정의하는 데 도움이 될 수 있지만, 게시물의 최신성은 사실의 최신성을 보장하지 않습니다. 최근 설명이 오래된 규칙을 설명할 수 있습니다.

도메인 제한은 또 다른 유용한 경계를 제공합니다. 선택된 게시자에 조사를 집중할 수 있지만, 허용된 도메인에도 오래되었거나 불완전한 자료가 포함될 수 있습니다.

이러한 제어는 서비스가 어디를 살펴보는지 결정합니다. 최종 답변이 불확실성을 충분히 담아내거나 상충하는 정보를 해결하는지는 결정하지 않습니다.

질문을 AWS 내부에 유지한다는 AWS의 설명도 정확하게 해석할 필요가 있습니다. 인프라 경계와 답변의 신뢰성은 서로 다른 문제를 다룹니다.

조직은 처리 방식을 수용하면서도 응답의 근거가 부족하다고 판단할 수 있습니다. 또 다른 조직은 답변이 유용하다고 보면서도 다른 처리 위치를 요구할 수 있습니다.

이들은 별도의 근거를 바탕으로 별도로 결정해야 하는 문제입니다. 보안 특성을 사실 정확성의 증거로 취급하면 도입 평가가 혼동될 수 있습니다.

주변 에이전트가 조사 결과를 다시 작성할 때 또 다른 문제가 나타납니다. 에이전트는 실수로 조건을 해당 주장과 분리하거나, 더 넓은 표현에 인용을 연결할 수 있습니다.

애플리케이션은 도구 출력뿐 아니라 최종 응답을 평가해야 합니다. 사용자는 개발자가 검토한 중간 결과가 아니라 표시된 답변을 경험합니다.

팀은 근거가 부족한 질문도 테스트해야 합니다. 답변 시스템은 사용 가능한 출처가 유용한 결론을 뒷받침하지 못할 때 허용 가능한 경로를 제공해야 합니다.

이러한 경우 유창한 텍스트가 성공 기준이 되어서는 안 됩니다. 약한 자료를 바탕으로 구성된 자신감 있는 응답보다 명확한 한계 설명이 더 유용할 수 있습니다.

이러한 우려가 관리형 답변을 무효화하는 것은 아닙니다. AWS가 검색 및 종합 장비를 책임진 뒤에도 남아 있는 평가 작업을 정의할 뿐입니다.

출시 후 개발자가 살펴봐야 할 사항

다음으로 유용한 근거는 실제 배포 요구 사항 전반에 걸친 답변 품질, 운영 동작, 가용성에 관한 것입니다.

첫 번째 신호는 대표적인 질문을 대상으로 한 평가입니다. 도입을 고려하는 팀은 관리형 출력과 현재 애플리케이션이 사용하는 방식을 비교해야 합니다.

이 비교에서는 출처의 뒷받침, 관련 조건, 누락된 근거의 처리 방식을 살펴봐야 합니다. 응답은 읽기 쉬울 수 있지만 작업에 적합하지 않을 수 있습니다.

질문은 잘 작동한다는 이유로 선택된 예시가 아니라 실제 사용자 요구를 반영해야 합니다. 모호한 요청과 서로 다른 출처가 서로 다른 조건을 설명하는 사례도 포함해야 합니다.

관리형 답변이 필요한 구분을 보존하면서 구현 노력을 줄인다면 위임의 근거는 강화됩니다. 중요한 세부 사항이 반복적으로 사라진다면 직접적인 조사 제어는 계속 가치를 가집니다.

두 번째 신호는 애플리케이션의 일반적인 워크로드에서 나타나는 동작입니다. 고립된 호출 한 번의 성공만으로는 조사가 전체 사용자 상호작용에 어떤 영향을 미치는지 알 수 없습니다.

팀은 대기 시간, 실패한 요청, 외부 에이전트가 다시 시도해야 하는 빈도를 관찰해야 합니다. 이러한 측정값은 사용자가 실제로 받는 경험을 설명합니다.

관련 결과는 사용자의 작업 완료입니다. 애플리케이션이 이후 이를 보완하거나 명확히 하는 데 추가 노력을 들여야 한다면, 더 빠른 조사 응답의 가치는 제한적입니다.

반대로 신뢰할 수 없는 여러 애플리케이션 단계를 대체한다면 더 긴 조사 단계도 수용할 수 있습니다. 비교는 전체 워크플로를 따라야 합니다.

현실적인 사용 환경에서도 운영 단순화가 유지된다면 이 신호는 관리형 서비스의 근거를 강화할 것입니다. 통합이 지속적인 복구 작업을 초래하는 경우에는 그 근거를 약화할 것입니다.

세 번째 신호는 문서화된 가용성과 제어 변경 사항입니다. 특정 지리적 요구 사항이 있는 조직은 더 넓은 접근성을 가정하지 말고 지원되는 배포 방식을 추적해야 합니다.

또한 출처 제한과 응답 처리에 영향을 주는 변경 사항을 모니터링해야 합니다. 이러한 기능은 어떤 작업을 관리형 조사 경계 뒤로 안전하게 옮길 수 있는지에 영향을 줍니다.

이러한 신호는 출시 열기보다 더 유용한 도입 프레임워크를 제공합니다. 서비스의 약속을 특정 팀이 검토할 수 있는 근거와 연결합니다.

Amazon Bedrock Web Answer의 기회는 구체적입니다. 주로 뒷받침된 사실 답변이 필요한 작업에서 맞춤형 조사 장비를 제거하는 것입니다.

범위가 정해진 공개 정보 작업부터 시작하고, 만족스러운 응답에 무엇이 포함되어야 하는지 문서화하세요. 중요한 작업에 연결하기 전에 반환된 답변을 기본 출처와 비교하세요.

그 검토 과정에서 인용 처리를 명확하게 유지하세요. 유용한 답변은 애플리케이션의 나머지 부분을 거치는 동안에도 뒷받침 근거를 보존해야 합니다.

그다음 위임이 실제로 팀이 유지해야 하는 작업을 줄이는지 평가하세요. 이 판단에는 통합, 검토, 복구 작업을 포함하세요.

근거가 더 넓은 역할을 뒷받침할 때만 확장하세요. 에이전트의 어떤 질문에는 완성된 인용 답변이 필요하며, 어떤 질문에는 여전히 조사에 대한 직접 제어가 필요한가요?