Microsoft Multi-Agent Reference Architecture

Source: microsoft/multi-agent-reference-architecture

 

Microsoft Multi-Agent Reference Architecture는 robust한 멀티 에이전트 시스템을 설계하기 위한 개념적 가이드다.

Microsoft 고객과 함께 구축한 production-scale solution에서 얻은 내용을 바탕으로 한다.

특정 기술에 종속되지 않지만, 개별 에이전트 개발보다는 orchestration과 governance에 초점을 둔다.

Design Principles

1. Separation of Concerns
   각 에이전트는 명확하게 정의된 고유 책임을 가진다. 이를 통해 집중적인 개발과 깊은 도메인 전문성을 확보할 수 있다.
2. Secure by Design
   인증, 권한 부여, 정책 적용, 민감 데이터 흐름 관리를 설계 단계부터 고려한다.
3. Observability & Traceability
   에이전트의 행동, 데이터 교환, 의사결정은 공통 식별자를 통해 end-to-end로 계측되고 추적 가능해야 한다.
4. Agent Registration & Lifecycle Governance
   에이전트는 production 배포 전에 명시적으로 등록되고, 버전 관리되며, 검증되어야 한다.
5. Failure Isolation & Graceful Degradation
   하나의 에이전트 실패가 전체 시스템으로 전파되지 않아야 한다. fallback mechanism을 통해 서비스가 계속 동작할 수 있어야 한다.
6. Context Management
   어떤 상태를 에이전트 간에 공유할지, 얼마나 오래 유지할지에 대한 명확한 정책이 필요하다.

Building Blocks

Core Components

ComponentRole

Orchestrator Agent	요청을 받고, high-level plan을 만들고, specialized agent에 작업을 위임한 뒤 결과를 종합
Specialized Agents	특정 기능 영역을 담당하는 domain expert. 예: flight search, hotel booking. 자체 sub-agent를 관리할 수도 있음
Agent Registry	에이전트 identity, capability, operational status, version, metadata를 관리하는 중앙 catalog
Supervisor Agent	복잡한 작업을 분해하고, subtask를 specialized agent에 위임하며, 결과를 취합
Classifier (NLU/SLM/LLM)	intent routing 수행. NLU → SLM → LLM 순으로 certainty에 따라 접근하며, intent가 없으면 “IDK” 반환
Knowledge Layer	document database, knowledge graph, domain resource. 구조화되고 tag와 version이 관리됨
Storage Layer	conversation history, agent state, registry metadata를 위한 persistent infrastructure
Integration Layer / MCP Server	Model Context Protocol을 통해 외부 tool 접근을 표준화

Key Architectural Principle

에이전트는 granular task가 아니라 의미 있는 capability를 대표해야 한다.

예를 들어, 단일 API 호출 하나를 에이전트로 만들기보다는 실제 비즈니스 기능이나 도메인 역량 단위로 구성하는 것이 좋다.

에이전트 간 통신은 기본적으로 orchestrator를 통해 라우팅된다. 다만 에이전트들이 매우 tightly coupled 되어 있다면, 하나의 composite unit으로 묶는 것이 적절하다.

Design Options

Modular Monolith

orchestrator와 agents가 잘 정의된 module로 구성된 standalone application이다.

 

특징

• 구조가 단순함
• shared memory 사용 가능
• component 간 통신이 빠름

적합한 경우

• 초기 단계 시스템
• 작은 팀
• 운영 복잡도가 낮은 환경

Microservices

각 에이전트가 독립적인 service로 캡슐화된 distributed system이다.

 

특징

• 독립 배포 가능
• 필요한 agent만 targeted scaling 가능
• 기술 스택 선택의 유연성

적합한 경우

• 대규모 시스템
• 여러 팀이 함께 운영하는 조직
• heterogeneous tech stack이 필요한 환경

선택 기준은 technical objective, organizational structure, team dynamics다. 어느 한쪽이 항상 더 좋은 것은 아니다.

 

Agents Communication

Request-Based Communication

에이전트 간 synchronous 또는 asynchronous direct request를 주고받는 방식이다.

 

장점

• 단순함
• 예측 가능함
• tightly coupled interaction에 적합

latency sensitivity가 중요한 경우에 적합하다.

 

Message-Driven Communication

broker나 event bus를 통해 asynchronous message를 교환하는 방식이다.

 

장점

• loose coupling
• scalability
• resilience

distributed environment에서 dynamic coordination이 필요한 경우에 적합하다.

 

Hybrid Approach

request-based pattern과 message-driven pattern을 함께 사용하는 방식이다.

이를 통해 control, flexibility, fault tolerance 사이의 균형을 맞출 수 있다. 에이전트는 외부 소비를 위해 event를 발행하면서도, direct interaction capability를 유지할 수 있다.

Memory

TypeScopePurpose

Short-Term Memory (STM)	Active session	Conversation history, in-session task coordination
Long-Term Memory (LTM)	Cross-session	Persistent knowledge, past interactions, personalization

Design Challenges

멀티 에이전트 환경에서 memory를 설계할 때는 다음 문제가 중요하다.

• Synchronization
  distributed agents 간 consistency 유지
• Ownership & Privacy
  공유 정보의 소유권과 통제 권한 정의
• Data Consistency
  multi-agent environment에서 state를 안정적으로 관리

Agent Registry

Registration Mechanisms

Agent Registry는 에이전트를 등록하고 관리하는 핵심 구성 요소다. 등록 방식은 크게 두 가지다.

• Registry-Initiated Discovery
  registry가 agent endpoint를 능동적으로 조회
• Agent Self-Registration
  agent가 스스로 registry에 등록

Metadata Standards

Metadata는 human operator와 agent consumption을 모두 고려해야 한다.

Human operator를 위한 metadata는 다음과 같다.

• tags
• owners
• categorization metadata

Agent consumption을 위한 metadata는 다음과 같다.

• name
• description
• communication URL
• authentication credentials

Lifecycle Management

Agent Registry는 단순한 목록이 아니다. lifecycle management가 필요하다.

주요 관리 항목은 다음과 같다.

• regular health check
• information refresh cycle
• registration 단계의 validation
• system degradation 방지

관련 표준으로는 A2A Agent Card, ACP Agent Detail specification이 있다.

Context Engineering

Context는 LLM이 output을 생성할 때 사용하는 정보다.

여기에는 instruction, memory, external data가 포함된다. Context engineering은 이 정보를 설계하고 관리하는 과정이다.

Key Objectives

1. Reducing Noise
   오래되었거나 중복되었거나 misleading한 정보를 제거한다. 이를 통해 token usage와 cost를 줄인다.
2. Enhancing Relevance
   적시에 활용 가능한 actionable하고 high-confidence인 데이터를 제공하도록 정보를 구조화한다.

Multi-Agent Impact

멀티 에이전트 환경에서는 작은 context 개선도 전체 시스템에 큰 영향을 줄 수 있다.

각 에이전트에서 약간씩 context 효율이 좋아지면, 에이전트 수가 늘어날수록 그 효과가 누적된다.

또한 advanced AI가 필요하지 않은 작업은 더 단순한 component에 위임하는 것도 고려해야 한다.

Observability

Four Monitoring Focus Areas

1. Agent Communication
   에이전트 간 message flow, coordination pattern, communication bottleneck을 모니터링
2. Performance Monitoring
   response time, resource utilization, throughput을 distributed agents 전반에서 추적
3. Error Handling
   failure, cascading error, recovery mechanism을 관찰
4. Security & Compliance
   unauthorized access, data leak, regulatory compliance를 모니터링

Observability vs. Evaluation

Observability와 Evaluation은 다르다.

• Observability
  log, metric, trace 같은 raw signal을 생성
• Evaluation
  이 signal을 분석해 agent performance를 평가하고 개선 방향을 찾음

Security

Identity & Access Control

에이전트와 orchestrator는 Azure AD 또는 동등한 identity provider를 통해 인증한다.

실행 권한은 role-based access control로 관리한다.

에이전트 간 mutual authentication은 X.509 certificate 또는 internal CA에서 발급한 JWT를 사용할 수 있다.

Communication Protection

모든 inter-agent communication과 external tool communication은 HTTPS 또는 mutual TLS를 사용한다.

MCP protocol은 signed payload와 call tracing을 지원한다.

Data Protection

저장 데이터는 encryption-at-rest와 configurable retention policy를 적용한다.

Short-term memory는 conversation scope에 한정된다.

Long-term memory는 PII redaction과 consent-based retention을 고려해야 한다.

RAG system은 user role에 따라 document retrieval을 제한해야 한다. 이 제한은 세 단계에서 적용된다.

• indexing
• retrieval
• response generation

Risk Mitigations

• Adversarial Testing
  prompt injection, message corruption, impersonation을 시뮬레이션한다. chaos security engineering도 포함된다.
• Versioning & Rollback
  agent logic, prompt, communication contract는 semantic versioning을 적용한다. anomaly detection 시 즉시 rollback할 수 있어야 한다.
• Audit Logging
  모든 orchestration call은 timestamp, caller identity, input/output hash를 기록한다. 이 로그는 centralized observability platform으로 전송한다.

Governance

Responsible AI Framework

Responsible AI framework는 다음 principle을 포함한다.

• fairness
• reliability
• privacy
• inclusiveness
• transparency
• accountability

또한 legal, compliance, IT, security, AI team이 참여하는 cross-functional governance committee가 필요하다.

참고 문서로 Microsoft Responsible AI Standard v2가 있다.

Data Governance

Data governance에서는 데이터를 sensitivity에 따라 분류하고, agent access를 제한해야 한다.

핵심 수단은 다음과 같다.

• role-based access control
• data loss prevention
• encryption

Lifecycle Phases

PhaseKey Practices

Development	Azure AI Content Safety를 통한 guardrail 적용, unsafe output filtering
Operational	telemetry와 eval pipeline을 통한 model drift 및 prompt injection 모니터링
Oversight	structured logging, versioning, traceable decision tree
Continuous	human-in-the-loop feedback, adversarial testing, hallucination rate tracking

Reference Architecture Patterns

Microsoft Multi-Agent Reference Architecture에서 다루는 주요 reference pattern은 다음과 같다.

1. Semantic Router + LLM Fallback
2. Dynamic Agent Registry
3. Semantic Kernel Orchestration
4. Local & Remote Agent Execution
5. Onion Architecture
6. MCP Integration
7. RAG Pipeline
8. Conversation-Aware Orchestration
9. Agent-to-Agent Communication

Reference

[1] microsoft/multi-agent-reference-architecture (GitHub)

[2] Microsoft Responsible AI Standard v2

[3] Semantic Kernel: Multi-agent Orchestration (Microsoft DevBlogs)

[4] Model Context Protocol (MCP)

[5] Agent-to-Agent Protocol (A2A) — Google

[6] OpenTelemetry Documentation

[7] The Onion Architecture — Jeffrey Palermo

[8] Microservices Guide — Martin Fowler