에이전트가 도구를 호출한 뒤 성공했다고 답하지만 실제 작업은 끝나지 않았습니다. 모델 호출·도구 실행·관찰을 어떻게 연결해야 하나요?

모델이 생성한 도구 호출은 실행 요청이고, 실제 호출과 결과 검증은 런타임의 책임입니다. 모델 응답에 도구 이름이 나왔다고 실행된 것이 아니고, 도구가 요청을 접수했다고 최종 상태가 바뀐 것도 아닙니다. 현재 상태를 관찰하고 다음 행동을 선택하고 실행 결과를 다시 관찰하는 흐름에서 각 단계를 명시적으로 구분하겠습니다.

모델 출력과 실행 상태를 연결합니다

일반적인 루프는 사용자 목표와 허용된 도구를 모델에 전달하고, 모델이 호출 인자를 제안하면 런타임이 스키마·인가·예산을 검사한 뒤 실행합니다. 결과에는 호출 ID, 성공·실패·진행 중 상태, 필요한 데이터가 담겨야 합니다. 이 관찰을 다음 모델 호출에 넣어 추가 조회나 수정, 완료 보고를 선택하게 합니다. 여러 호출이 동시에 나오면 호출 ID별로 결과를 연결하며 완료 순서만으로 어느 요청의 결과인지 추측하지 않습니다.

예를 들어 문서 업로드 도구가 작업 ID만 반환했다면 완료가 아니라 접수 상태입니다. 런타임은 작업 조회나 알림으로 완료를 확인하고, 저장된 문서의 ID와 접근 가능한 위치를 얻은 뒤에야 사용자에게 완료를 보고합니다. 실패 응답도 문자열 하나로 합치지 않고 재시도 가능한 일시 실패와 잘못된 인자, 권한 부족, 실행 여부가 불확실한 timeout을 나눕니다. 모델이 오류 문구를 보고 임의로 성공을 추론하지 않게 구조를 제공합니다.

관찰의 품질이 다음 행동을 바꿉니다

도구의 출력이 지나치게 크면 필요한 결과가 묻히고, 너무 짧으면 같은 조회를 반복합니다. 실제 변경된 대상과 버전, 부분 성공, 다음 확인 방법을 충분히 반환하되 비밀값과 불필요한 원문은 제외합니다. 도구 결과 안에 명령문이 있어도 외부 데이터이지 실행 정책이 아니므로 신뢰 수준을 보존해야 합니다. 관찰과 정책을 같은 텍스트 덩어리로 합치는 것이 안전한 추론을 보장하지는 않습니다.

완료 조건은 모델의 자신감과 별개로 둡니다. 파일 작성은 존재·내용 확인, 코드 수정은 테스트와 변경 범위, 예약은 실제 예약 상태처럼 확인 가능한 결과를 사용합니다. 반복 수·시간·비용 한도를 넘거나 새 관찰 없이 같은 행동을 반복하면 중단하고 무엇이 미완료인지 보고합니다. 내부 추론 전문을 보존하지 않아도 호출 인자·결과·결정 요약과 상태 전이로 루프를 감사할 수 있습니다. 좋은 에이전트 루프는 모델이 많이 말하는 구조가 아니라 실행 사실과 보고가 일치하는 구조입니다.

실행 사례로 확인합니다

주문 조회와 재고 조회를 함께 요청한 뒤 재고 결과가 먼저 왔다면 런타임은 각 결과를 원래 호출 ID에 붙여야 합니다. 재고 수량을 주문 상태로 해석하는 오류는 모델의 추론 이전에 상관관계 관리가 깨진 것입니다. 같은 결과가 중복 전달되거나 한 결과가 누락된 경우도 명시적인 상태로 유지합니다. 다음 행동이 두 결과를 모두 필요로 한다면 둘 다 검증될 때까지 실행하지 않고, 선택 결과라면 누락 사실을 밝힌 제한된 응답을 만들 수 있습니다. 전체 루프를 하나의 성공·실패 플래그로만 표현하지 않는 이유입니다. 최종 답변 생성 중 연결이 끊겨도 완료된 외부 효과의 기록은 유지해야 재접속한 사용자에게 실제 결과를 알려 줄 수 있습니다.