Agent는 유효한 응답을 만들고도 요청한 일을 마치지 못할 수 있다. 유용한 산출물을 남겼지만 대화가 끝나거나 다음 단계가 연결되지 않을 수도 있다. 안전하게 이어 가려면 인수자는 산출물의 용도, 어느 요청에 답하는지, 어떤 현재 전제가 뒷받침하는지 알아야 한다.
아래 세 글은 문제의 서로 다른 부분을 본다. 설계 노트는 같은 도구로 만든 제품을 구별한다. 실제 배치 처리 장애는 식별 검사 뒤에 성공이 와야 하는 이유를 보여 준다. Flowness의 Work 설계를 읽는 글은 결과 상태를 한 실행자의 기억 밖에서도 조회 가능하게 하는 방법을 묻는다.
같은 도구 세 개, 서로 다른 제품 세 개 ↗
대기질 프로젝트가 먼저 전달할 것을 변환 기록, 조사 가능한 비교, 독립해서 읽을 설명 중에서 고른다.
성공 확정은 식별 정보 확인 뒤에 ↗
사례 식별자가 바뀐 항목을 따라 새 호출과 과거 성공 수신 기록에 같은 검수 경계가 필요한 이유를 배운다.
대화 밖에서도 다시 찾을 수 있는 일의 주소 ↗
테스트가 낡은 요구를 통과시키는 스케줄러 인계를 살펴보고 현재 작업 뷰가 무엇을 보존해야 하는지 본다.
기존 워크플로는 되돌릴 수 있는 시험에서 일부러 중단해 볼 수 있다. 다른 실행자가 최신 목표, 실제 파일과 결과, 다음 필수 행동, 실제 사용이나 수락을 기다리는 부분을 식별할 수 있는가? 절약한 작업과 기록 유지 노력을 비교하자.