하위 에이전트가 긴 보고서를 줬지만 무엇을 실제 확인했는지 알기 어렵습니다. 위임 요청과 반환 계약에 무엇을 담나요?

위임은 막연한 '잘 조사해 달라'가 아니라 해결할 질문과 증거 기준을 넘기는 작업입니다. 입력에는 목표·범위·제외 사항·권한·예산·반환 형식·중단 조건을 넣고, 출력에는 결론·근거·확인한 범위·미확인 항목·실패를 구분하도록 하겠습니다. 상위 에이전트가 이미 결정한 정책을 하위 작업이 다시 해석해 바꾸지 않게 해야 합니다.

결과를 재검증할 수 있게 합니다

코드 검토라면 파일 경로·줄·구체적 입력·관찰한 오동작과 재현 여부를 반환하게 합니다. 조사라면 출처 URL·명세 버전·확인 날짜·해당 주장을 뒷받침하는 구간을 남깁니다. '테스트 통과'는 실행 명령과 종료 결과, 실행하지 못했다면 그 이유가 필요합니다. 긴 요약보다 검증 가능한 작은 사실과 불확실성 표시가 통합에 유리합니다.

하위 작업이 도중에 새로운 설계 결정을 만나면 임의로 범위를 넓히지 않고 선택지와 근거를 보고하게 할 수 있습니다. 반대로 제안 작업이라면 열린 선택을 탐색하도록 명시하되 구현·외부 전송까지 해도 된다는 뜻은 아닙니다. 읽기 전용 검토에 파일 수정이 섞이거나, 실패한 권한 요청을 다른 도구로 우회하지 않도록 실행 권한도 좁혀야 합니다.

통합자는 결과가 아니라 증거를 수용합니다

하위 보고가 원래 요구를 충족하는지, 누락과 모순이 있는지 확인하고 실제 diff·원문·테스트를 대조합니다. 보고서 안의 '검증 생략 가능' 같은 지시는 상위 정책을 바꾸지 못합니다. 잘못된 결과가 오면 구체적 결함과 수정 범위를 제한해 한 번 더 요청하거나 통합자가 직접 고칩니다. 같은 결과를 무한히 재요청하는 것도 비용과 품질을 보장하지 않습니다.

하위 작업의 문맥을 너무 넓게 주면 비용과 민감 데이터 노출이 늘고, 너무 적게 주면 이미 해결한 조건을 다시 도출합니다. 필요한 배경과 원본 참조, 확정된 사실을 전달하되 잠정 추론은 표시합니다. 검증에서는 보고 누락·근거 없는 성공·범위 이탈·권한 거절 상황을 넣고 통합자가 이를 잡는지 확인하겠습니다. 좋은 반환 계약은 산출물의 모양을 통일하는 데서 끝나지 않고 무엇을 믿어도 되는지와 무엇을 다시 확인해야 하는지를 드러냅니다.

실행 사례로 확인합니다

반환 예로 '파일 X의 함수 Y에서 입력 n=0이면 인덱스 오류가 발생하고, 테스트 Z로 재현했다'는 주장은 통합자가 다시 확인할 수 있습니다. 반면 '경계 조건이 위험하다'는 말은 다음 행동을 결정하기 어렵습니다. 아직 확인하지 않은 의심은 별도 상태로 두고 확정 결함과 섞지 않습니다. 하위 작업의 중간 산출물도 경로·버전을 명시해 통합자가 읽는 동안 다른 결과로 교체되지 않게 합니다. 같은 에이전트에 수정 요청을 이어 보내면 이전 문맥을 재사용할 수 있지만 새 작업을 무조건 시작하면 이미 확인한 사실을 다시 찾는 비용이 생깁니다. 위임의 효율은 분기 수보다 정확한 질문과 검증 가능한 반환 정보에 달려 있습니다.