Anthropic Commerce Agents로 공부하는 하나의 강한 Agent Loop를 설계하는 법
Anthropic Commerce Agents에서 읽어낸 프로덕션 AI 에이전트 아키텍처
AI 에이전트를 만들기 시작하면 꽤 자연스럽게 이런 구조를 떠올리게 된다.
사용자
↓
Router Agent
├─ Search Agent
├─ Recommendation Agent
├─ Order Agent
├─ Customer Support Agent
├─ Payment Agent
└─ Analytics Agent
업무별로 전문가를 하나씩 두는 것이다.
사람 조직을 생각하면 합리적으로 보인다.
검색은 검색 전문가에게 맡기고, 결제는 결제 전문가에게 맡기고, 고객지원은 고객지원 전문가에게 맡기면 더 잘하지 않을까?
최근 몇 년 동안 많은 AI Agent Framework가 이런 Multi-Agent Architecture를 적극적으로 지원한 이유도 여기에 있다.
그런데 Anthropic이 2026년 9월 공개한 Claude Commerce Agents의 설계는 꽤 다른 방향을 보여준다.
핵심은 오히려 단순하다.
하나의 강한 모델을 하나의 Agent Loop 안에서 계속 움직이게 하고, 그 주변에 Skills, Tools, Memory, Harness, Evals를 제대로 설계한다.
Anthropic의 표현을 아키텍처로 옮기면 대략 다음과 같다.
┌───────────────┐
│ User │
└───────┬───────┘
↓
┌───────────────────┐
│ Agent Loop │
│ │
│ Claude │
│ │
│ Think → Act │
│ ↑ ↓ │
│ Observe ← │
└────────┬──────────┘
│
┌──────────────┼───────────────┐
↓ ↓ ↓
Skills Tools Memory
│ │ │
│ ↓ ↓
│ Existing Systems DB
│
└──────────────────────────────┐
│
┌────────▼────────┐
│ Harness │
│ │
│ Safety │
│ Permissions │
│ Provenance │
│ Approval │
│ Context │
│ Caching │
└────────┬────────┘
│
↓
Snapshot Evals
Anthropic의 Commerce Agents 레퍼런스 역시 commerce-common, Shopping Agent, Merchant Agent, Skills, Tool contracts, Memory, Safety Gates, Presentation, Executor, Tests 등의 구조로 분리돼 있다. 하나의 거대한 AI 프로그램이라기보다 비결정적인 모델을 결정적인 소프트웨어 시스템이 둘러싸고 있는 구조에 가깝다.
그리고 이 구조가 중요한 이유는 Commerce에만 국한되지 않는다.
[Inference] 이 설계를 조금 확장해 보면 앞으로 일반적인 프로덕션 AI Agent의 핵심 경쟁력이 어디에 생길지도 꽤 선명하게 보인다.
1. 모델이 아니라 Agent Loop를 중심에 놓는다
먼저 Agent를 지나치게 거창하게 생각할 필요가 없다.
Anthropic이 최근 Context Engineering 글에서 사용하는 간결한 정의는 사실상 다음과 같다.
Agent
=
LLM이
Tools를 사용하면서
Loop를 도는 시스템
가장 단순화하면 코드도 이 정도다.
while not task_completed:
context = build_context(
conversation,
memory,
skills,
current_state
)
response = model.generate(
context=context,
tools=tools
)
if response.has_tool_calls():
results = execute_tools(response.tool_calls)
conversation.append(results)
else:
return response
물론 실제 프로덕션 코드는 이것보다 훨씬 복잡하다.
하지만 지능이 작동하는 핵심 구조 자체는 의외로 단순하다.
목표 이해
↓
필요한 정보 탐색
↓
Tool 실행
↓
결과 관찰
↓
다음 행동 판단
↓
Tool 실행
↓
...
↓
목표 완료
중요한 것은 이 Loop를 누가 계속 유지하느냐다.
Commerce Agents에서는 기본적으로 하나의 Main Agent가 대화를 소유한다.
앞단에 Intent Router가 있고 그 뒤에 여러 도메인 Agent가 붙어 있는 구조가 아니다. Anthropic은 실제 커머스 Agent를 설명하면서 아예 앞단의 Intent Router와 뒤쪽의 Domain-specific Agent 집합이 없는 구조를 제시한다.
여기서 첫 번째 설계 원칙이 나온다.
대화를 여러 Agent에게 분배하기 전에 하나의 강한 Agent가 전체 Context를 유지할 수 있는지 먼저 검토하라.
2. 왜 Subagent를 계속 만들면 문제가 생길까
예를 들어 사용자가 이렇게 말한다고 해보자.
다음 주 제주도 가는데 아이 둘이랑 묵기 좋은 호텔 찾아줘.
Agent가 호텔을 검색한다.
그리고 사용자가 말한다.
첫 번째 호텔은 수영장이 있어?
조금 뒤에는 이렇게 말한다.
그런데 지난번에 내가 조용한 호텔 좋아한다고 했잖아. 그것도 고려해줘.
마지막에는 이렇게 이어진다.
그럼 두 번째 호텔로 예약할게. 조식도 넣어줘.
우리가 기능 중심으로 Agent를 나눴다면 이것은 다음과 같이 움직일 가능성이 높다.
Planning Agent
↓
Hotel Search Agent
↓
Facility Agent
↓
Personalization Agent
↓
Booking Agent
문제는 각각의 Agent가 답하기 위해 필요한 Context다.
누구와 여행하는가
언제 여행하는가
현재 검색 결과는 무엇인가
첫 번째 호텔은 무엇인가
사용자 취향은 무엇인가
현재 선택한 옵션은 무엇인가
직전 대화에서는 무엇을 이야기했는가
Subagent로 넘어갈 때마다 이 정보를 같이 넘겨야 한다.
Anthropic은 이 과정을 state-lossy operation으로 설명한다.
즉 Agent 간 handoff가 일어날수록 상태가 조금씩 손실되거나 재구성돼야 한다는 것이다.
또 Anthropic은 자체 enterprise deployment 비교에서 subagent handoff가 경우에 따라 여러 배의 토큰을 사용하고 수 초의 latency를 추가할 수 있었으며, single agent + skills 구조가 one-big-prompt 방식과 subagent 방식보다 지속적으로 좋은 품질을 보였고 비용과 latency에서도 유리한 경우가 많았다고 보고한다. 이는 Anthropic이 공개한 자체 관찰 결과로, 세부 실험 데이터까지 공개된 것은 아니다.
쉽게 이야기하면 이런 문제다.
Agent A:
"여기까지 상황을 Agent B에게 설명해야지."
Agent B:
"알았어. 일단 내가 이해한 상황은..."
Agent B → Agent C:
"지금까지 사용자는..."
사람 회사에서도 부서 이동과 인수인계가 늘어날수록 커뮤니케이션 비용이 증가한다.
Agent도 다르지 않다.
3. Subagent 대신 Skill을 붙인다
그렇다고 하나의 Agent에게 모든 업무 매뉴얼을 System Prompt로 집어넣자는 이야기는 아니다.
여기서 Anthropic이 사용하는 중요한 개념이 Agent Skills다.
Skill은 간단하게 말하면:
특정 업무를 수행할 때만 불러오는 업무 매뉴얼 + 리소스 + 코드
다.
예를 들어 Shopping Agent는 다음과 같은 Skill을 가진다.
Main Shopping Agent
├─ search-discovery
├─ purchase-research
├─ planning-goals
├─ customer-care
└─ memory-personalization
Merchant Agent 역시:
Main Merchant Agent
├─ performance-insights
├─ catalog-listings
├─ inventory-operations
├─ pricing-promotions
└─ marketing-campaigns
로 나뉜다.
여기서 중요한 차이가 있다.
Subagent는:
Context
↓
Agent A
↓ handoff
Agent B
이지만 Skill은:
┌─ Search Skill
│
Main Agent ─────────┼─ Customer Care Skill
전체 Context 보유 │
├─ Pricing Skill
│
└─ Planning Skill
이다.
머리는 그대로 있고 필요한 매뉴얼만 갈아 끼우는 것이다.
Anthropic은 Agent Skills를 설명하면서 이를 신입 직원에게 제공하는 onboarding guide에 비유한다. 모든 업무별로 새로운 직원을 만드는 대신 한 명의 유능한 직원에게 필요한 업무 매뉴얼을 필요할 때 제공하는 방식이다.
이 구조의 장점은 꽤 크다.
사용자가:
상품 검색
→ 가격 비교
→ 정책 문의
→ 장바구니 변경
→ 배송 문의
를 오가더라도 Main Agent의 conversation history는 끊기지 않는다.
Skill만 바뀐다.
4. 여기서 중요한 건 Context Engineering이다
이제 Agent 개발에서 중요한 질문도 바뀐다.
과거에는:
System Prompt를 어떻게 잘 쓸까?
가 중요한 문제였다.
지금은 점점:
이 순간 모델에게 어떤 Context를 보여줘야 하는가?
가 중요해진다.
Anthropic 역시 이를 Prompt Engineering에서 Context Engineering으로의 확장이라고 설명한다. Context에는 System Prompt뿐 아니라 Tool 정의, MCP 결과, Memory, Conversation history, 외부 데이터 등이 모두 포함된다.
잘 만든 Agent라면 모든 정보를 항상 넣지 않는다.
예를 들어:
[항상 필요]
System Prompt
Tool Definitions
Grounding Rules
Safety Rules
+
[필요할 때]
Pricing Skill
Customer Care Skill
Purchase Research Skill
+
[현재 사용자]
Conversation
Current Cart
User Profile
Memory
+
[지금만 필요]
Current Page
Current Time
Search Results
처럼 Context를 계층화할 수 있다.
Anthropic은 Commerce Agents에서 경험적인 출발점으로 전체 트래픽 약 1/3 이상에서 필요할 지식은 System Prompt에, 나머지는 Skills에 두는 방법을 제안한다.
이건 의외로 중요한 기준이다.
무조건 System Prompt를 작게 만드는 것도 아니고 무조건 Skill로 분리하는 것도 아니다.
빈도에 따라 Context 위치를 결정하는 것이다.
5. Tool은 Agent의 능력이 아니라 기존 시스템으로 들어가는 문이다
두 번째로 중요한 부분이 Tools다.
Agent를 만들다 보면 개발자가 Tool 안에 비즈니스 로직을 계속 넣기 시작하는 경우가 있다.
예를 들어 상품 재고를 조회하기 위해 Tool이:
상품 DB 조회
↓
SKU 찾기
↓
매장별 Inventory 조회
↓
배송 가능 여부 조회
↓
픽업 가능 여부 확인
↓
대체 상품 규칙 계산
까지 처리하도록 만든다.
Anthropic은 이런 방향을 경계한다.
기업에는 이미:
Search / Ranking
Catalog
Inventory
Pricing
Promotion
Cart
OMS
CRM
Analytics
시스템이 존재한다.
따라서 Agent Tool은 가능하면 그 시스템을 호출하는 얇은 Interface여야 한다.
예를 들어:
search_products(query)
를 호출하면 기존 Search Engine에서 이미 랭킹된 결과가 와야 한다.
Agent가 해야 하는 것은:
검색 알고리즘 구현 ❌
어떤 상품을 사용자에게 보여줄지 판단 ✅
왜 이 상품이 적합한지 설명 ✅
몇 개를 보여줄지 결정 ✅
다음 행동을 결정 ✅
하는 것이다.
이를 한 줄로 정리하면:
Agent = Judgment
Tool = Interface
Backend = Business Logic
이다.
이 분리가 중요한 이유는 모델이 교체돼도 Backend는 그대로 유지되기 때문이다.
6. Memory도 모델에게 맡기지 않는다
에이전트의 Memory를 이야기하면 흔히 이런 구조를 떠올린다.
memory.md
혹은 Conversation 전체를 Vector DB에 넣고 매번 검색하는 방법이다.
Anthropic의 Commerce Agent 설계는 더 보수적이다.
핵심 원칙은:
Memory는 모델 안에 있는 것이 아니라 우리 시스템 안에 있어야 한다.
예를 들어 사용자가 말한다.
나는 운동화 275를 신어.
그러면 이것은 단순한 텍스트가 아니라:
{
"key": "shoe_size",
"value": "275",
"category": "preference",
"source": "...",
"created_at": "...",
"expires_at": "..."
}
같은 Typed Data가 될 수 있다.
그러면 일반적인 Database가 가진 장점을 그대로 사용할 수 있다.
Query
Update
Delete
Permission
Retention
Audit
Validation
Join
그리고 Memory를 읽는 방법도 세 단계로 나눈다.
1. Always in Context
↓
항상 필요한 소수의 정보
2. Pre-fetch
↓
현재 요청에 관련된 Memory
3. Lookup Tool
↓
나머지 Long-tail Memory
예를 들어 사용자가:
운동화 좀 찾아줘.
라고 하면 Harness가 미리:
shoe_size = 275
preferred_brand = ...
default_store = ...
를 가져올 수 있다.
반대로 몇 달 전에 이야기한 여행 취향까지 매번 넣을 필요는 없다.
여기서 다시 Context Engineering이 등장한다.
7. Memory 쓰기조차 Main Agent의 일을 줄여준다
Commerce Agents에서 특히 재미있는 설계가 하나 더 있다.
사용자가 정보를 말할 때마다 Main Agent에게:
save_memory()
를 호출하게 하지 않는 것이다.
Anthropic은 별도의 비동기 Memory Extraction Process를 제안한다.
User ↔ Main Agent
│
│ 대화
↓
Conversation
│
└─────────────→ Memory Extractor
↓
Validate Facts
↓
DB
이렇게 하면 Main Agent의 사용자 응답 과정에 Memory 저장 Tool round가 들어가지 않는다.
Anthropic은 자체 Commerce Memory eval에서 별도 비동기 extraction 방식이 fact recall을 13% 높였다고 보고한다. 이 역시 Anthropic 내부 평가 수치다.
중요한 것은 13%라는 숫자보다 설계 철학이다.
Main Agent에게 모든 책임을 주지 않는다.
AI가 잘하는 것은 AI에게 맡기되,
Storage
Validation
Permission
Lifecycle
Extraction Pipeline
은 시스템으로 분리한다.
8. 가장 위험한 착각: Safety를 Prompt로 해결하려는 것
예를 들어 Merchant Agent가 있다고 해보자.
사용자가 말한다.
이 제품 가격 30% 내려줘.
Agent가 바로:
update_price()
를 호출하게 만들어서는 안 된다.
Commerce Agents의 Merchant 쪽은 기본적으로 다음 구조를 사용한다.
Model
↓
stage_price_change()
↓
Staged Change
↓
Preview
↓
Human / Policy Approval
↓
apply_change()
Shopping Agent 역시 모델이 신용카드를 직접 charge하는 Tool 자체를 갖지 않는다.
Agent
↓
Checkout UI
↓
User Action
↓
Host Application
↓
Payment
이다.
즉:
Model proposes. Harness enforces.
라는 구조다.
Anthropic의 실제 레퍼런스 코드에는 이 원칙을 위해 상당히 많은 deterministic gate가 들어 있다.
예를 들어:
Tool allowlist
Provenance validation
Result limits
Session serialization
Memory validation
Protected fields
Price movement cap
Promotion limit
Approval gate
Loop limit
SQL SELECT-only restriction
Timeout
Result row cap
등이다.
특히 흥미로운 것이 Provenance다.
Agent가 어떤 product_id를 마음대로 만들어냈다고 하자.
product_id = "XYZ123"
그 ID를 바로 Cart에 넣지 않는다.
Harness는:
이 ID를 우리 서버가
이 Session에서
실제로 Model에게 제공한 적이 있는가?
를 검사한다.
없다면 거절한다.
Model hallucination
↓
XYZ123
↓
Provenance Gate
↓
BLOCK
사용자가 Prompt Injection을 통해 ID를 집어넣어도 같은 원리가 적용된다.
즉 안전을:
"절대로 이상한 ID를 사용하지 마세요."
라는 Prompt에 의존하지 않는다.
코드에서 불가능하게 만든다.
9. 그래서 Harness가 Agent 제품의 핵심이 된다
여기까지 오면 재미있는 변화가 보인다.
처음 Agent를 만들 때 우리는 보통 모델을 중심으로 생각한다.
GPT인가?
Claude인가?
Gemini인가?
Opus인가?
Sonnet인가?
하지만 프로덕션으로 갈수록 중요한 부분은 모델 바깥으로 이동한다.
Harness가 담당하는 일이 많아진다.
Agent Harness
├─ Context Assembly
├─ Tool Execution
├─ Tool Permissions
├─ Authentication
├─ Session
├─ State
├─ Safety Gates
├─ Provenance
├─ Memory
├─ Prompt Caching
├─ Retry
├─ Token Limits
├─ Compaction
├─ Logging
├─ Streaming
└─ Observability
Anthropic이 2026년 Managed Agents를 설명하면서 사용한 표현도 흥미롭다.
모델과 Harness를 Brain, 실제 실행 환경과 Tools를 Hands, Session을 별도의 지속 가능한 Log로 분리하는 방향이다. 이렇게 하면 각 부분을 서로 독립적으로 교체하거나 확장할 수 있다.
┌──────────────┐
│ Brain │
│ Model │
│ + Harness │
└──────┬───────┘
│
execute(name,input)
│
┌─────────────────┼────────────────┐
↓ ↓ ↓
Backend MCP Sandbox
Hand Hand Hand
│
↓
Session
Durable Event Log
[Inference] 이 관점에서 보면 미래의 Agent Platform 경쟁력은 단순히 어떤 LLM API를 연결했느냐에서 나오기 어렵다.
오히려:
Context를 어떻게 구성하는가
Tools를 어떻게 설계했는가
State를 어떻게 관리하는가
Memory를 어떻게 관리하는가
Write 권한을 어떻게 제한하는가
Failure를 어떻게 검출하는가
가 시스템의 핵심 자산이 된다.
10. Prompt Cache 90~99%를 목표로 하는 이유
이 구조는 비용에서도 이점이 있다.
Anthropic은 Commerce Agent의 Context를 다음 세 영역으로 나눌 것을 권장한다.
┌─────────────────────────────┐
│ GLOBAL │
│ │
│ Tools │
│ System Prompt │
│ Stable Rules │
│ │
│ ===== Cache Breakpoint ==== │
├─────────────────────────────┤
│ SESSION │
│ │
│ User Profile │
│ Memory │
│ Conversation History │
├─────────────────────────────┤
│ VOLATILE │
│ │
│ Current Page │
│ Current Time │
│ Current State │
└─────────────────────────────┘
Prompt Caching은 prefix 기반이기 때문이다.
앞쪽 byte가 달라지면 뒤쪽 cache까지 영향을 받는다.
그래서:
Current Time: 19:31:24
같은 내용을 System Prompt 상단에 넣는 것은 좋지 않다.
Anthropic은 자사가 관찰한 좋은 Commerce deployment에서 90~99% 수준의 cache hit rate가 나타났으며 이를 처음부터 목표 범위로 설계하라고 제안한다. 또한 약 100K token context 기준 cached read가 fresh read보다 약 1.5~2배 빨랐던 경험치를 제시한다.
Skills 역시 System Prompt를 계속 변경하는 대신 Tool Result로 Conversation에 로딩하면 이후 Context Prefix의 일부가 되어 다시 caching할 수 있다.
결국 Agent 비용 최적화도:
작은 모델을 쓰자
하나로 끝나지 않는다.
Context 구조
+
Cache
+
Tool 호출 횟수
+
Agent Turn 수
+
Tool latency
+
Task success rate
전체를 봐야 한다.
그래서 Anthropic은 모델 호출 한 번의 가격보다 Cost per completed task를 측정하라고 이야기한다. 저렴한 모델이 더 많은 Turn을 쓰거나 실패율이 높으면 실제로는 더 비쌀 수 있기 때문이다.
11. 마지막 퍼즐은 Snapshot Evals다
Agent가 프로덕션에서 어려운 가장 큰 이유 중 하나는 비결정적이라는 점이다.
같은 요청이라도:
Tool 호출 순서가 달라질 수 있고
검색 전략이 달라질 수 있고
중간 판단이 달라질 수 있고
최종 답변도 조금씩 달라질 수 있다.
그렇다면 Agent를 어떻게 테스트해야 할까?
Anthropic은 Commerce Agents에서 전체 Conversation을 매번 재현하지 말고 Snapshot을 테스트하라고 제안한다.
예를 들어 이런 실패가 있었다고 해보자.
사용자가 이미 Cart에 상품 3개를 넣었다.
몇 Turn 전에는
"10만원 넘으면 사지 않겠다"
고 말했다.
그런데 검색 결과가 바뀌면서
Agent가 12만원 상품을 추가했다.
그럼 테스트도:
"10만원 넘는 상품 넣지 마"
라는 깨끗한 새 대화에서 시작하면 안 된다.
실패 직전의 상태를 그대로 구성한다.
conversation:
- ...
- user_budget: 100000
- ...
cart:
- product_A
- product_B
- product_C
search_results:
- product_D: 120000
current_page:
cart
user:
"그거 하나 더 넣어줘."
그리고 Agent를 실행한다.
중요한 것은 중간 reasoning path가 아니다.
Tool A → Tool B → Tool C
순서를 강제하는 대신:
최종 Cart가 어떻게 됐는가?
승인되지 않은 Write가 있었는가?
최종 UI에는 무엇이 표시됐는가?
가격은 Tool Result에서 Grounding됐는가?
를 평가한다.
Anthropic의 일반 Agent Eval 가이드에서도 같은 원칙을 강조한다.
Agent가 어떤 경로로 갔는지보다 실제 환경의 outcome을 평가하는 것이 더 낫다. 지나치게 구체적인 Tool 호출 순서를 검사하면 Agent가 더 좋은 방법을 찾아도 실패 처리하는 brittle test가 될 수 있기 때문이다.
12. 실패를 발견하면 Snapshot으로 얼려버린다
여기서 아주 좋은 개발 패턴이 나온다.
Production Failure
↓
Failure Analysis
↓
Precondition Reconstruction
↓
Snapshot Eval
↓
Regression Suite
즉 실제 사고 하나가 발생할 때마다 다시는 같은 사고가 발생하지 않도록 Agent의 시험문제 하나를 추가하는 것이다.
특히 Anthropic은 깨끗한 상황만 테스트하지 말라고 한다.
실패가:
긴 Conversation 이후
여러 Tool 호출 이후
상충되는 요구사항 이후
복잡한 Cart 상태에서
발생했다면 Eval 역시 그 상태를 만들어야 한다.
그리고 Positive Case만 만들면 안 된다.
Should answer
↔
Should refuse
Should ask
↔
Should just do it
Should write
↔
Should not write
처럼 Negative Counterpart도 함께 만들어야 한다.
이 순간 Evals는 단순 테스트 코드가 아니다.
사실상:
제품 요구사항을 실행 가능한 형태로 만든 것
이 된다.
13. 이 구조에서는 새로운 모델이 나와도 시스템을 다시 만들 필요가 없다
이제 모든 조각을 합쳐보자.
AGENT LOOP
┌────────────────┐
│ Strong Model │
│ │
│ Reason │
│ Act │
│ Observe │
└───────┬────────┘
│
┌──────────────┼───────────────┐
│ │ │
↓ ↓ ↓
Skills Tools Memory
│ │ │
Procedures Existing APIs DB
│ │ │
└──────────────┼───────────────┘
│
┌──────▼───────┐
│ Harness │
│ │
│ Context │
│ Security │
│ Provenance │
│ Approval │
│ Cache │
│ State │
└──────┬───────┘
│
↓
Snapshot Evals
여기서 생각해 볼 점이 있다.
새로운 Claude가 나온다고 해보자.
기존:
Model A
를:
Model B
로 바꾼다.
그렇다고:
상품 DB
Inventory
CRM
Memory DB
Pricing API
Skills
Approval Flow
Safety Gates
Evals
를 다시 만들 이유는 없다.
Evals를 돌린다.
Model A + effort X
Model A + effort Y
Model B + effort X
Model B + effort Y
그리고:
Task Completion
Grounded Accuracy
Latency p50
Latency p99
Cost / Completed Task
Safety Eval
을 비교한다.
문제가 없으면 교체한다.
Anthropic은 Commerce Agents 글의 결론에서도 대부분의 구조가 사실 모델 자체에 관한 것이 아니라고 설명한다. Tools는 기존 시스템을 호출하고, Skills는 기존 업무 절차를 담으며, Evals는 제품 요구사항을 테스트로 만들고, Harness는 기존 정책을 강제한다. 더 나은 모델이 등장하면 해당 구조 위에서 모델을 configuration처럼 바꾸고 Eval을 다시 돌리는 방향이다.
그렇다고 Multi-Agent가 필요 없다는 이야기는 아니다
여기서 오해하면 안 되는 부분이 있다.
Anthropic도 Subagent 자체를 부정하지 않는다.
좋은 예가 Deep Research다.
Main Agent
↓
"지난 6개월 매출 하락 원인을 분석해줘."
↓
Research / Analysis Subagent
│
├─ DB 탐색
├─ 문서 검색
├─ SQL 실행
├─ Code 실행
└─ 여러 가설 검증
│
↓
압축된 결과
↓
Main Agent
이런 작업은 별도의 Context Window를 사용하는 것이 오히려 유리하다.
실제 Commerce Agents의 Merchant 쪽에도 Analysis Delegate가 존재한다.
다만 범위가 철저하게 제한된다.
Reference 구현에서는 이 delegate가 read 중심으로 동작하고, SQL도 SELECT 중심으로 제한하며 결과 크기, timeout, 호출 횟수 등에 제한을 둔다. 무엇보다 delegate가 읽은 ID가 Main Agent의 write provenance로 자동 승격되지 않는다.
즉 기준은:
❌ 업무 카테고리가 다르니까 Subagent
✅ Context-heavy하고
독립적이며
경계가 명확한 작업이므로 Subagent
다.
[Inference] 좋은 Multi-Agent Architecture는 Agent 숫자가 많은 구조가 아니라 Context를 분리해야 할 이유가 명확한 구조라고 보는 편이 더 정확하다.
결국 AI Agent Engineering은 모델을 덜 믿는 기술이다
아이러니하게도 강력한 AI Agent를 만들수록 모델에게 모든 것을 맡기면 안 된다.
모델이 잘해야 하는 일은:
이해
추론
판단
계획
도구 선택
정보 종합
설명
이다.
반대로 시스템이 가져가야 할 것은:
Identity
Permissions
State
Business Rules
Transactions
Memory Storage
Validation
Approval
Limits
Audit
Security
Testing
이다.
이를 다시 나누면 아주 단순하다.
영역책임
| Model | 판단 |
| Skills | 업무 절차 |
| Tools | 시스템 접근 |
| Backend | 비즈니스 로직 |
| Memory DB | 장기 상태 |
| Harness | 통제와 실행 |
| Evals | 품질 계약 |
이 경계가 잘 만들어질수록 모델은 오히려 자유롭게 움직일 수 있다.
잘못된 가격 변경은 Harness가 차단한다.
존재하지 않는 상품 ID는 Provenance Gate가 차단한다.
결제는 모델에게 권한 자체가 없다.
Memory는 DB Validator를 거친다.
실패했던 행동은 Snapshot Eval이 잡는다.
그 안에서는 모델에게 상당한 자율성을 줄 수 있다.
앞으로 Agent 개발에서 중요한 질문
앞으로 Agent를 설계한다면 처음부터:
Agent를 몇 개 만들까?
부터 시작할 필요는 없어 보인다.
오히려 순서를 바꾸는 편이 낫다.
1. 하나의 Agent Loop로 해결 가능한가?
2. 어떤 지식이 항상 필요한가?
→ System Prompt
3. 어떤 업무 절차가 가끔 필요한가?
→ Skills
4. 모델이 무엇을 할 수 있어야 하는가?
→ Tools
5. 기존 Backend가 처리해야 할 것은 무엇인가?
→ Business Logic
6. Session 밖에서도 기억해야 하는 것은 무엇인가?
→ Memory DB
7. 모델이 절대 직접 결정하면 안 되는 것은 무엇인가?
→ Deterministic Harness
8. 어떤 실패를 다시 발생시키면 안 되는가?
→ Snapshot Evals
9. 그 후에도 Context 분리가 필요한 무거운 작업이 있는가?
→ Subagent
이 순서가 훨씬 합리적이다.
마치며
초기 Agent 시장에서는 모델을 여러 개 연결하는 구조 자체가 기술처럼 보였다.
Planner Agent.
Research Agent.
Critic Agent.
Executor Agent.
Manager Agent.
각각 이름을 붙이고 서로 대화하게 만들면 상당히 복잡하고 똑똑한 시스템처럼 보였다.
하지만 모델 자체가 점점 강해지면서 상황이 바뀌고 있다.
한 모델이 더 긴 Context를 처리하고,
더 많은 Tool을 이해하고,
필요한 Skill을 찾아 읽고,
실패한 Tool 호출에서 복구하고,
복잡한 여러 단계의 작업을 수행할 수 있게 된다.
그러면 우리가 직접 만들어야 하는 것은 점점 두뇌의 숫자가 아니라 두뇌가 일할 환경이 된다.
[Inference] Anthropic Commerce Agents에서 가장 주목할 부분도 Shopping 기능 그 자체가 아니다.
오히려 다음 문장으로 정리할 수 있는 아키텍처다.
똑똑한 모델 여러 개를 연결하는 것보다, 하나의 강한 Agent Loop 주변에 Skills · Tools · DB Memory · Deterministic Harness · Snapshot Evals를 제대로 설계하라.
모델은 계속 바뀐다.
오늘의 최고 모델이 6개월 후에도 최고라는 보장은 없다.
하지만 잘 설계된 Tools는 남는다.
업무를 담은 Skills도 남는다.
고객 Memory를 저장하는 Database도 남는다.
기업의 정책을 강제하는 Harness도 남는다.
실패 경험을 축적한 Evals도 남는다.
그래서 앞으로의 Agent Engineering에서 가장 가치 있는 자산은 어쩌면 모델 자체가 아니라 모델 바깥에 우리가 쌓아놓은 시스템일지도 모른다.
참고 자료
- Anthropic, A guide to the anatomy of effective commerce agents
- Anthropic, Building effective agents
- Anthropic, Effective context engineering for AI agents
- Anthropic, Equipping agents for the real world with Agent Skills
- Anthropic, Writing effective tools for AI agents — with AI agents
- Anthropic, Demystifying evals for AI agents
- Anthropic, Scaling Managed Agents: Decoupling the brain from the hands
- Anthropic, anthropics/commerce-agents reference implementation