persistent agent state는 새 worker가 완료된 작업을 다시 실행하거나 chat history를 보고 추측하지 않고 task를 재개하는 데 필요한 구조화된 record입니다. 현재 step, 완료된 operation, 대기 중인 signal, retry state, 다음에 허용되는 transition을 식별해야 합니다.
state는 memory, business data, artifact, audit history와 다릅니다. 다섯 가지를 모두 vector-store document 하나로 취급하면 복구가 모호해지고 access control이 어려워집니다.
저장 정보의 다섯 유형을 분리하세요
| 유형 | 답해야 하는 질문 | 일반적인 저장소 |
|---|---|---|
| Workflow state | 이 실행은 어디에 있고 다음에는 무엇을 할 수 있는가? | relational row 또는 workflow engine |
| Business state | order, customer, deployment에 관해 무엇이 사실인가? | 기준 application database 또는 provider |
| Memory | 이후 판단에 어떤 이전 context가 도움이 될 수 있는가? | relational record, search index 또는 vector store |
| Artifact | 생성된 file, report, code bundle은 어디에 있는가? | metadata가 있는 object storage |
| Audit record | 누가 언제 무엇을 결정하고 실행했는가? | append-only event 또는 audit table |
invoice status는 business state에 속합니다. workflow가 finance approval을 기다린다는 사실은 workflow state에 속합니다. customer preference의 summary는 memory에 속할 수 있습니다. PDF는 object storage에 속합니다. approval decision은 audit record에 속합니다.
더 넓은 agent 아키텍처 가이드는 이 저장소가 도구 및 durable execution에 어떻게 연결되는지 보여 줍니다.
prose summary가 아니라 state machine을 저장하세요
명시적인 state와 허용된 transition을 사용하세요.
stateDiagram-v2
[*] --> Created
Created --> Running
Running --> WaitingForApproval
WaitingForApproval --> Running: approved
WaitingForApproval --> Cancelled: rejected or expired
Running --> RetryScheduled: retryable failure
RetryScheduled --> Running
Running --> Completed
Running --> Failed
task row에는 state, state_version, current_step, attempt, wake_at, approval_id, timestamp를 둘 수 있습니다. 완료된 부작용은 자유 형식 model text에 넣지 말고 operation record를 통해 참조해야 합니다.
허용되는 transition을 코드에 정의하고 stale update를 거부하세요. model이 transition을 제안할 수는 있지만 waiting_for_approval이 approval record 없이 completed가 될 수 있는지는 state 계층에서 결정해야 합니다.
concurrent worker 사이의 충돌을 안전하게 처리하세요
queue는 같은 작업을 두 번 전달할 수 있고, lease는 만료될 수 있으며, 느린 worker는 다른 worker가 같은 task를 재개한 뒤에 완료될 수 있습니다. version column으로 optimistic concurrency를 구현하거나 owner와 expiry가 있는 lease를 사용하세요. state update에는 자신이 읽은 version을 포함하고 다른 worker가 이미 진행했다면 실패해야 합니다.
lease와 workflow state는 분리하세요. crash가 난 worker는 task를 failed로 바꾸지 않고 lease만 잃어야 합니다. 다음 worker가 lease를 얻고 저장된 state를 읽어 재개할 수 있습니다.
영향 전후에 checkpoint를 기록하세요
쓰기 전에는 의도를 저장하고, 완료를 검증한 뒤에는 그 사실을 저장하세요. timeout으로 결과를 알 수 없다면 step이 실패했다고 가장하지 말고 reconciling 같은 state로 이동하세요.
durable execution 가이드는 idempotency와 reconciliation을 자세히 다룹니다. state store의 역할은 operation reference를 보존하고 결과가 해결되지 않은 동안 안전하지 않은 transition을 막는 것입니다.
사람의 대기를 일급 record로 저장하세요
approval record에는 정확한 action, resource, requested scope, requester, approver, expiry, decision, policy version이 포함되어야 합니다. 몇 시간 뒤 workflow가 재개되면 approval이 현재 parameter에 적용되는지, 해당 사용자가 여전히 접근 권한을 갖고 있는지 다시 확인하세요.
기다리는 동안 server process를 잠든 상태로 두지 마세요. condition을 저장하고 signal이나 scheduled job이 다음 transition을 queue에 넣게 하세요. Temporal의 durable execution 모델은 이런 대기에 event history와 signal을 사용하지만 database와 queue로도 같은 설계를 구현할 수 있습니다.
기존 실행을 버리지 않고 state version을 관리하세요
장시간 실행되는 task는 deployment보다 오래 지속될 수 있습니다. workflow definition version을 저장하고 active state를 위한 migration을 설계하세요. 새 worker는 이전 payload를 읽을 수 있는지, migration할지, 이전 handler를 계속 사용할지 알아야 합니다.
model context 전체를 version이 없는 JSON blob 하나에 넣지 마세요. JSON은 step별 payload에 유용하지만 scheduling, authorization, retention, operation에서 사용하는 안정적인 field는 명시하고 index를 만들어야 합니다.
모든 record에 retention rule을 부여하세요
workflow state는 완료 후 compact할 수 있습니다. audit record는 더 오래 보관해야 할 수 있습니다. memory는 수정과 삭제를 지원해야 합니다. artifact에는 expiry와 ownership metadata가 필요합니다. business data에는 제품 고유의 policy가 적용됩니다.
삭제는 reference를 따라가야 합니다. prompt, trace, artifact에 같은 personal data를 남겨 둔 채 user memory만 제거하면 삭제가 완료된 것이 아닙니다. cleanup path가 각 사본을 찾을 수 있도록 reference와 classification을 저장하세요.
빈 process에서 재개를 테스트하세요
approval 중, provider call 후, retry backoff 중에 worker를 중지하세요. local cache나 conversation object가 없는 process에서 재개합니다. 저장된 state와 기준 backend record에서 다음 작업을 도출할 수 있어야 합니다.
아래 프롬프트는 변경을 제안하기 전에 이 inventory를 수행합니다. 필요한 사실이 log line이나 prompt에만 있다면 구체적인 persistence gap입니다.