에이전트가 완료했다고 말하는 시점과 브라우저가 결과를 확인한 시점은 다를 수 있다. 나는 작업 시작과 조작, 완료를 별도 API로 만들고 미확정 입력이 남아 있으면 마지막 완료 요청을 거절하게 했다. 문장이 끝난 것을 업무가 끝난 것으로 세지 않기 위해서다.

시작에는 목표와 현재 문맥이 필요하다

begin은 실제 context와 goal을 받는다. 현재 프로필·프로젝트와 맞는지 확인하고 프로그램이나 노트북이 실행 중이면 시작을 거절한다. 목표가 없으면 MCP_GOAL_REQUIRED가 된다. 실행 ID만 먼저 만들고 나중에 목적을 붙이는 방식으로 두지 않았다.

시작 후에는 현재 탭을 선택하는 기존 작업 경로를 통과한다. 이 과정에서 실패하면 그 오류로 작업을 정리하고 호출자에게 돌려준다. ID가 생겼다는 사실만으로 첫 화면 조작까지 정상 준비됐다고 쓰지 않는다. 접수와 실행 준비의 결과를 단계별로 읽어야 한다.

아무 taskId나 다음 동작에 붙일 수 없다

call은 현재 task와 같은 ID인지, program 실행인지, running 상태인지 확인한다. 프로필과 프로젝트도 맞아야 한다. 이전에 끝난 작업의 ID를 새 입력의 허가처럼 쓰지 않는다. 다른 작업이 실행 중이면 그 작업을 가리키는 번호로 조용히 바꿔서 진행하지도 않는다.

TaskController는 현재 실행 세대를 Broker에 전달한다. 이 검사가 브라우저 행동의 수명과 연결된다. 정해진 ID 모양만 확인하는 것이 아니라 지금 그 행동을 받아도 되는 실행인지 보는 것이다. 장부의 번호와 실제 현재 작업을 묶어야 과거 문맥이 새 조작을 만들지 않는다.

미확정 결과가 있으면 완료를 거절한다

finish는 programPendingOutcome을 확인하고 남아 있으면 MCP_OUTCOME_UNPROVEN으로 멈춘다. 편의 API의 blocked 검사와 호스트의 검사가 함께 있다. 호출자가 다른 래퍼를 쓰더라도 호스트의 조건이 없어지지 않는다.

확인할 수 없는 결과를 무조건 실패로 바꾸는 것도 아니었다. 원래 입력의 결과를 읽어 확인하거나 사용자 중지로 정리할 수 있어야 한다. 다만 finish가 모든 업무 의미를 자동 추론하는 검증기는 아니다. 호출자가 단계별로 올바른 기대를 주고 필요한 결과를 확인하는 책임도 남는다.

완료 표시와 재사용 자산 생성은 나눠 둔다

정상 finish는 반복 절차의 자동 보관을 요청할 수 있다. 단계와 행동 수 같은 조건을 만족한 workflowDraft를 기존 라이브러리에 남긴다. 모든 짧은 읽기를 무조건 새 프로그램으로 만드는 것은 아니다. 다시 쓸 가치가 있는 절차인지 별도 조건을 둔다.

보관 중 오류가 나면 이벤트에 자동 보관 미완료를 적는다. 이미 수행한 업무와 재사용 자료 생성의 상태를 한 성공 문장으로 합치지 않는다. 결과는 끝났지만 다음에 재사용할 자산은 없을 수 있다. 나는 이 차이를 남겨야 다음 요청에서 없는 프로그램을 있다고 가정하지 않는다고 봤다.

검사하는 실패 조건을 구체적으로 남긴다

통합 시험에는 pendingOutcome을 가진 task를 finish해도 완료 함수가 호출되지 않는 확인이 있다. 현재와 다른 taskId의 call도 거절한다. 페이지 API 시험에서는 불확실한 Enter 뒤 finish와 추가 입력이 막히고 읽기는 가능한지 확인한다.

이 글에서는 그 시험과 현재 handler, 컨트롤러를 대조했다. 실제 외부 글을 새로 발행한 시험 보고서는 아니다. 또한 작업이 running이라는 표시는 결과가 맞다는 뜻이 아니고 succeeded라는 표시는 해당 구현이 확인한 조건의 범위다. 업무별로 어떤 기대와 결과를 사용했는지 함께 기록해야 해석할 수 있다.

완료의 책임을 상태 이름 뒤에 숨기지 않는다

업무 화면에는 완료 버튼 하나만 있어도 내부에서는 무엇을 확인했는지 설명할 수 있어야 한다. 나는 시작·실행·검증·보관을 나눠 남기는 편이 고객에게도 더 정확한 설명이라고 본다. 입력을 보낸 일과 외부 서비스에 결과가 남은 일은 같지 않다.

다른 프로그램에 적용할 때는 완료 상태를 만드는 함수를 먼저 찾고, 그 앞에 어떤 미확정 조건이 남을 수 있는지 살펴볼 수 있다. 에이전트가 완료를 요청할 수는 있어도 실행기가 확인하지 못한 결과를 말 한마디로 없앨 수 없게 한다. 그것이 이 작업 수명 설계의 중심이었다.