agent_settled는 '답변 완료'라는 뜻이 아니었다
2026년 9월 30일 수정 전, 텔레그램으로 보낸 블로그 작업 요청 다섯 건이 모두 최종 답변 없이 끝났다. 요청은 다섯 건 모두 세션에 도착해 있었다. 수정 보고서가 짚은 브리지 쪽 문제는, 세션의 agent_settled 이벤트가 오면 최종 답변이 없어도 요청을 끝내고 폴백을 보내는 흐름이었다. 대상은 메신저 요청을 에이전트 세션에 넣고 답을 다시 메신저로 돌려보내는 브리지를 직접 만든 개발자다. 목표는 턴이 끝났다는 신호와 최종 답변이 생겼다는 사실을 따로 판정하는 것이다. 아래는 9월 30일 내 브리지 한 건의 수정 기록이다. 모든 에이전트 런타임의 이벤트가 이렇게 동작한다는 뜻은 아니다. 기록된 증상: 다섯 요청이 모두 도착했는데 답이 없었다 수정 보고서에 남은 원인은 이렇다. 기존 흐름은 요청의 user 메시지가 시작된 뒤 agent_settled 가 오면, 최종 assistant 텍스트가 없어도 바로 요청을 끝내고 폴백을 전송했다. 실제 요청 파일과 상태 파일이 만들어진 간격도 4~7초뿐이었다. 보고서가 대조한 세션 기록에서 다섯 요청은 모두 세션에 들어가 있었다. 한 건은 Claude 인증 차단, 나머지 네 건은 로드된 런타임의 OpenAI chunk 누락 오류가 난 뒤 assistant 최종 메시지가 없었다. 마지막 요청도 세션에서 유실된 것이 아니었다. 요청 표시가 세션 기록에 있었고, 바로 다음 줄에 provider 모듈 오류가 있었다. 정리하면 이 사고에서 두 가지가 겹쳤다. 하나는 provider 쪽 오류로 답변이 만들어지지 않은 것이다. 다른 하나는 브리지가 그 상황을 곧바로 "끝"으로 처리한 것이다. 두 오류가 왜 났는지는 이 보고서에 없다. 이 글은 두 번째, 브리지의 판정만 다룬다. 보고서는 이번 증상과 별개로 위험이 하나 더 있었다고 적었다. 기존 주입은 세션이 바쁜 상태로 바뀌는 경쟁 상황에 필요한 deliverAs 를 지정하지 않았다. 확장 API의 실제 비동기 실패는 fire-and-forg...
