In-Context Prompting이 절차적 작업에서 Agent Orchestration을 대체한다
In-Context Prompting Obsoletes Agent Orchestration for Procedural Tasks
TL;DR Highlight
LangGraph 같은 에이전트 오케스트레이션 프레임워크 쓰지 말고, 절차 전체를 시스템 프롬프트에 넣으면 품질도 높고 실패율도 낮다.
Who Should Read
LangGraph, CrewAI 같은 에이전트 프레임워크로 고객 서비스 봇이나 절차적 워크플로우를 구축 중인 백엔드/AI 개발자. 프레임워크 도입 여부를 결정해야 하는 시니어 개발자나 AI 아키텍트.
Core Mechanics
- LangGraph 같은 외부 오케스트레이터 대신, 절차 전체(모든 노드·엣지·조건)를 시스템 프롬프트에 직접 넣고 모델이 스스로 흐름을 관리하게 하는 방식이 일관되게 더 좋은 성능을 냄.
- 테스트한 3개 도메인(여행 예약 14노드, Zoom 기술지원 14노드, 보험 청구 55노드) 모두에서, 5개 평가 지표 전부 in-context 방식이 LangGraph보다 높아 15/15 비교에서 완승.
- 오케스트레이션이 실패율을 대폭 높임. 여행 예약에서 24% vs 11.5%, Zoom 지원에서 9% vs 0.5%(18배 차이), 보험에서 17% vs 5%. 이 실패들은 아키텍처 구조 자체에서 발생하는 것.
- 오케스트레이터가 실패하는 이유는 3가지: 노드마다 별도 LLM 호출로 추론이 쪼개져 전체 맥락 파악 불가(reasoning fragmentation), 라우팅 LLM 호출 자체의 실수, 노드 템플릿 주입이 모델의 자연스러운 대화를 방해.
- LLM 호출 횟수도 오케스트레이터가 1.2~1.7배 더 많음. 보험 도메인 기준 17.3회 vs 10.0회. 더 많이 호출하고도 품질은 낮은 것.
- 비용은 in-context 방식이 1.3~1.4배 더 비쌈(절차 전체를 매 API 호출마다 포함하기 때문). 보험 도메인 기준 $0.22 vs $0.17. 하지만 품질 차이를 고려하면 충분히 감수할 만한 수준.
Evidence
- Claude 심사 기준으로 15개 비교 전부 in-context 우세, p < 0.005 (Mann-Whitney U, Holm-Bonferroni 보정), 효과 크기 d = 0.37~1.01. GPT-4.1 독립 심사로 재검증 시 15개 중 11개 유의미하게 in-context 우세, 오케스트레이션이 우세한 경우는 0개.
- 일관성(Consistency) 점수: in-context 4.83~4.99 vs LangGraph 4.32~4.55. 가장 차이가 큰 지표로, 오케스트레이터의 노드별 분리 생성이 전체 대화 흐름 파악을 방해한다는 근거.
- Zoom 도메인 실패율: LangGraph 9%(18건) vs in-context 0.5%(1건), 18배 차이. 기술 진단 라우팅의 각 분기점이 추가 실패 지점이 되는 구조적 문제를 보여줌.
- 보험 55노드 도메인에서 인슈어런스 대화당 평균 턴 수: LangGraph 26.4회 vs in-context 19.0회. 오케스트레이터가 추가 라우팅 결정을 반복하며 불필요한 턴을 생성하는 것.
How to Apply
- LangGraph나 CrewAI로 고객 서비스 봇을 만들려고 한다면, 먼저 워크플로우 전체(노드, 엣지, 조건, 종료 상태)를 구조화된 텍스트로 직렬화해서 시스템 프롬프트에 통째로 넣고 테스트해보라. 프레임워크 없이 단순 API 호출만으로도 더 좋은 결과가 나올 수 있다.
- 절차가 context window에 들어가는지 확인하라. 논문에서 55노드 절차가 ~4,000 토큰이었고 200K 컨텍스트의 2%만 차지했다. 절차를 시스템 프롬프트 앞부분에 위치시키면 'Lost in the Middle' 문제도 피할 수 있다.
- 비용이 걱정된다면 (in-context 방식이 1.3~1.4배 비쌈), 논문에서 언급한 companion 방향인 절차를 소형 모델 가중치에 fine-tuning하는 것을 고려하라. 해당 연구에서 8B 모델을 컴파일해 LangGraph 오케스트레이터 수준 품질을 128~462배 낮은 비용으로 달성했다고 함.
Code Example
# LangGraph 오케스트레이터 대신 절차 전체를 시스템 프롬프트에 넣는 in-context 방식
import anthropic
# 워크플로우를 직렬화된 텍스트로 표현
PROCEDURE = """
PROCEDURE: travel_booking_v2
========================================
Step 1: OPENING [AGENT]
Greet the user warmly and ask how you can help.
-> Go to Step 2
Step 2: USER_INITIAL [USER waits for input]
-> Go to Step 3
Step 3: ASSESS [AGENT - DECISION POINT]
Assess the conversation state.
REQUIRED INFO: Destination, Travel dates, Number of travelers, Budget range.
ROUTES:
- If missing_info: Go to Step 4 (ask for missing info)
- If needs_clarification: Go to Step 5 (ask for clarification)
- If info_complete: Go to Step 6 (present options)
- If user_abandoning: Go to Step 7 (close gracefully)
Step 4: GATHER_INFO [AGENT]
Ask for the specific missing required information.
-> Go to Step 3
Step 5: CLARIFY [AGENT]
Ask for clarification on unclear information.
-> Go to Step 3
Step 6: PRESENT_OPTIONS [AGENT]
Present 2-3 tailored travel options based on gathered info.
-> Go to Step 8
Step 7: ABANDON [TERMINAL - EXIT]
Close gracefully.
Step 8: HANDLE_RESPONSE [AGENT - DECISION POINT]
ROUTES:
- If option_selected: Go to Step 9
- If needs_revision: Go to Step 6
- If user_abandoning: Go to Step 7
Step 9: FINALIZE [AGENT]
Confirm choice, summarize details, ask if ready to book.
-> Go to Step 10
Step 10: SUCCESS [TERMINAL - SUCCESS]
Confirm booking, provide tips, close warmly.
"""
SYSTEM_PROMPT = f"""You are a helpful travel booking assistant.
You must follow this procedure step by step. Determine which step you're at
based on the conversation context and respond accordingly.
At decision points, choose the route that best matches the user's situation.
{PROCEDURE}
IMPORTANT RULES:
- Follow the procedure from Step 1 through to a terminal state
- At decision points, determine the best route based on context
- Do NOT mention step numbers or that you're following a script
- Be natural and conversational while adhering to the procedure
"""
client = anthropic.Anthropic()
conversation_history = []
def chat(user_message: str) -> str:
conversation_history.append({"role": "user", "content": user_message})
# 단일 API 호출 - 라우팅을 위한 추가 호출 없음
response = client.messages.create(
model="claude-sonnet-4-5-20250929",
max_tokens=1024,
system=SYSTEM_PROMPT, # 절차 전체가 시스템 프롬프트에 포함
messages=conversation_history
)
assistant_message = response.content[0].text
conversation_history.append({"role": "assistant", "content": assistant_message})
return assistant_message
# 사용 예시
print(chat("Hi, I want to book a trip to Japan for 2 people"))Terminology
관련 논문
Tilde.run – AI Agent를 위한 트랜잭션 기반 버전 관리 파일시스템 샌드박스
AI 에이전트가 실제 프로덕션 데이터를 건드려도 롤백할 수 있는 격리된 샌드박스 환경을 제공하는 도구로, GitHub/S3/Google Drive를 하나의 버전 관리 파일시스템으로 묶어준다.
Specsmaxxing – AI 사이코시스 극복기, 그리고 내가 YAML로 스펙을 쓰는 이유
AI 코딩 에이전트와 일할 때 컨텍스트가 날아가거나 요구사항이 흐려지는 문제를 해결하기 위해, 인수 조건(Acceptance Criteria)을 YAML로 구조화해서 스펙을 관리하는 방법론과 오픈소스 툴킷(acai.sh)을 소개하는 글이다.
MLJAR Studio – 분석 결과를 Notebook으로 저장하는 로컬 AI 데이터 분석 도구
데이터를 클라우드에 올리지 않고 로컬에서만 실행되는 AI 데이터 분석 도구로, 자연어 질문을 Python 코드로 변환해 Jupyter Notebook 형태로 결과를 저장해준다. 데이터 보안이 중요한 환경에서 AI 분석 자동화를 원하는 팀에게 의미 있는 선택지가 될 수 있다.
AI를 이용한 클라이언트 사이드 Tool Calling으로 PDF 폼 자동 작성하기
SimplePDF Copilot은 채팅으로 PDF 폼을 자동으로 채워주는 AI 도구로, 클라이언트 사이드 tool calling을 활용해 문서 데이터가 외부 서버로 나가지 않도록 구성할 수 있다는 점이 핵심이다.
Pu.sh – 400줄 Shell 스크립트로 만든 완전한 Coding Agent Harness
npm, pip, Docker 없이 curl과 awk만으로 동작하는 400줄짜리 Shell 기반 코딩 에이전트 실행 환경으로, 의존성 없이 API 키 하나만 있으면 바로 쓸 수 있다.
Ramp의 Sheets AI가 재무 데이터를 외부로 유출한 취약점 분석
Ramp의 스프레드시트 AI 에이전트가 외부 데이터셋에 숨겨진 프롬프트 인젝션에 속아 악성 수식을 자동 삽입하고 기밀 재무 데이터를 외부 서버로 유출할 수 있었던 취약점이 공개됐다. AI 에이전트가 신뢰할 수 없는 데이터를 처리할 때 얼마나 위험한지를 보여주는 실제 사례다.
Related Resources
Original Abstract (Expand)
Agent orchestration frameworks -- LangGraph, CrewAI, Google ADK, OpenAI Agents SDK, and others -- place an external orchestrator above the LLM, tracking state and injecting routing instructions at every turn. We present a controlled comparison showing that for procedural tasks, this architecture is dominated by a simpler alternative: putting the entire procedure in the system prompt and letting the model self-orchestrate. Across three domains -- travel booking (14 nodes), Zoom technical support (14 nodes), and insurance claims processing (55 nodes) -- we evaluate 200 conversations per condition using LLM-as-judge scoring on five quality criteria. The in-context approach scores 4.53--5.00 on a 5-point scale while a LangGraph orchestrator using the same model scores 4.17--4.84. The orchestrated system fails on 24% of travel, 9% of Zoom, and 17% of insurance conversations, compared to 11.5%, 0.5%, and 5% for the in-context baseline. While external orchestration may have been necessary for earlier models, advances in frontier model capabilities have made it unnecessary for multi-turn conversations following a defined procedure.