Why AI Agents Fail: 3 Failure Modes That Cost You Tokens and Time

Context

AI Agent는 전통 소프트웨어와 달리 스택 트레이스 없이 조용히 실패한다: 도구가 반환한 데이터가 컨텍스트 윈도우를 초과하거나, 외부 API 응답 대기로 무한 차단되거나, 동일한 도구를 반복 호출하며 토큰을 낭비한다. 이 문제들은 에러 로그 없이 불완전한 답변, 지연된 응답, 비용 증가로만 표출된다.

Technical Solution

• Memory Pointer Pattern: agent.state에 대용량 데이터(200KB+)를 저장하고 짧은 포인터(52바이트)만 LLM 컨텍스트에 전달하여 도구 간 데이터 접근 시 포인터 해석 방식 사용
• Async handleId Pattern: MCP 도구가 장시간 실행되는 작업에서 즉시 job ID를 반환하고, 별도의 check_status 도구로 폴링하도록 설계하여 Agent 블로킹 방지
• DebounceHook + Clear Tool States: 도구 응답에 SUCCESS/FAILED 터미널 상태를 명시하고 lifecycle hooks로 반복 호출 감지 및 차단
• Framework-Agnostic 설계: 패턴을 LangGraph, AutoGen, CrewAI 등 tool calling과 lifecycle hooks를 지원하는 모든 프레임워크에 적용 가능하도록 작성
• GitHub 리포지토리 제공: github.com/aws-samples/sample-why-agents-fail에서 Strands Agents + OpenAI(GPT-4o-mini) 기반 3개 데모 코드 및 Jupyter Notebook 제공

Impact

• 컨텍스트 윈도우 오버플로우: 토큰 소비 20M에서 1,234로 감소(Materials Science 워크플로우 사례)
• 데이터 포인터 도입: 214KB 전체 로그 대신 52바이트 포인터만 컨텍스트 전달
• 도구 호출 감소: 명확한 터미널 상태로 반복 호출을 14회에서 2회로 단축
• MCP 타임아웃 시나리오: Async handleId 패턴으로 Slow API(15초) 호출 시 18초 블로킹에서 약 4초(즉시 응답 + 폴링)로 단축

Key Takeaway

AI Agent의 침묵하는 실패는 컨텍스트 오버플로우, API 블로킹, 반복 호출이라는 3가지 명확한 패턴으로 체계화될 수 있으며, 각각에 대해 Agent 상태 관리, 비동기 패턴, 상태 검증을 통해 토큰 낭비와 지연을 근본적으로 제거할 수 있다. 이 패턴들은 특정 프레임워크에 종속되지 않으므로 기존 Agent 시스템에 즉시 적용 가능하다.