Your agent architecture has a half-life of 6 months — Dan Farrelly, CTO, Inngest

한 줄 핵심

에이전트 아키텍처는 모델·프롬프트보다 오래 가는 실행 레이어를 중심으로 분리 설계해야 6개월마다 전체를 갈아엎지 않고 변화에 대응할 수 있다.

시간별 요약

1. 0:06
   에이전트를 6개월 이상 운영하면 새 모델, 새 프레임워크, 새 툴 호출 표준 때문에 기존 구조를 다시 짜게 되며, 이 변화는 예외가 아니라 현실이다. 따라서 처음부터 아키텍처가 의도적으로 설계됐는지, 아니면 우연히 굳어진 것인지 점검해야 한다.
2. 3:01
   에이전트 시스템은 실행 레이어, 컨텍스트 레이어, 컴퓨트 레이어의 세 층으로 나눠 봐야 하며, 이 중 실행 레이어가 가장 오래 버티는 핵심 기반이다. prompts는 짧게, models는 중기적으로 바뀌지만, execution은 올바르게 설계하면 수년간 유지될 수 있다.
3. 6:00
   실행 레이어는 실패 후 재개 가능성, 다양한 호출 패턴의 통합, 전체 세션 단위의 관측성을 책임져야 한다. 상태는 메모리나 임시 저장소가 아니라 외부의 durable state로 관리해야 하며, cron·event·API·human-in-the-loop·sub-agent를 하나의 오케스트레이션 원리로 다뤄야 한다.
4. 9:01
   sandbox는 코드 실행과 브라우징을 위한 일시적 컴퓨트 공간일 뿐, 영속 상태의 저장소로 쓰면 안 된다. background agents나 loop architectures처럼 장시간·비동기·위임형 작업이 늘어날수록, sandbox는 실행 대상이고 execution layer가 그 순서와 문맥, 지속성을 제공하는 구조가 필요하다.
5. 13:00
   좋은 에이전트 루프는 cron으로 시작해 triage agent를 호출하고, 추가 컨텍스트와 도구 실행을 거쳐 reviewer function이 결과를 다시 평가하는 개선 루프를 만든다. 이때 실행 레이어에 쌓이는 로그·입력·출력·이벤트를 기반으로 outcome-based scoring을 해야 실제 성과를 측정하고 개선할 수 있다.

실무 인사이트

• 에이전트 설계는 모델 교체를 전제로 하고, 상태·재시도·관측성처럼 오래 가는 부분을 실행 레이어에 분리해 두면 리라이트 비용을 크게 줄일 수 있다.
• 평가 체계를 thumbs up/down가 아니라 PR 생성, 보고서 저장, 팀 후속 조치 같은 실제 결과 이벤트에 연결하면 에이전트 품질을 더 정확하게 측정할 수 있다.
• 프레임워크나 sandbox에 오케스트레이션과 상태를 흡수시키지 말고, 실행·컨텍스트·컴퓨트를 분리해야 background agent와 loop 작업을 안정적으로 운영할 수 있다.