예약 작업 하나가 계약서를 읽지 않은 채 끝났다. AI 게이트웨이는 처음부터 도구를 빼놓은 것이 아니었다. 도구는 두 번째 요청에서 사라졌다.
메시지와 예약 자동화를 함께 처리하는 AI 게이트웨이에 요청 미들웨어가 하나 있었다. 메신저 대화가 지식 저장소를 물으면 정해진 조회 도구를 먼저 쓰게 만드는 장치였다. 문제는 적용 대상을 메신저로 제한하지 않았다는 점이다. 예약 작업도 같은 문구를 포함하면 이 규칙에 걸렸다.
첫 번째 API 요청에는 파일 읽기와 명령 실행을 비롯한 정상 도구가 모두 붙어 있었다. 미들웨어는 지식 저장소 조회를 한 번 강제한 뒤 나머지 도구를 제거했다. 두 번째 요청에서 모델은 “필요한 도구가 없다”고 답했다. 로그도 맞고 모델의 관찰도 맞았다. 다만 둘은 서로 다른 순간을 보고 있었다. 세션 전체를 한 장면처럼 해석한 진단만 틀렸다.
수정은 권한을 더 주는 방식이 아니었다. 미들웨어가 메신저 요청일 때만 작동하도록 플랫폼 경계를 한 줄로 좁혔다. 실패를 재현한 테스트, 플러그인 검사, 실제 예약 작업의 파일 읽기, 자연 실행까지 차례로 통과했다. 그래도 모든 문제가 끝난 것은 아니다. 전체 출처 정리 작업은 약 503초 동안 API 호출 20회와 입력 토큰 169,088개를 썼다. 도구 경로는 고쳤지만 작업 비용은 여전히 나빴다.
에이전트의 도구 문제를 조사할 때 “도구가 있었나”만 물으면 부족하다. 어느 플랫폼의 몇 번째 요청이었고, 그 사이 어떤 미들웨어가 도구 목록을 바꿨는지 확인해야 한다. 시작 시점의 권한표는 실행 중 권한의 증거가 아니다.