Planner, router, multi-agent

이 장에서 배울 것

이번 장에서는 복잡한 에이전트를 어떻게 나누고 조정할지 배운다. 지금까지는 도구 호출, MCP 연결, memory와 state 설계를 다뤘다. 이제 그 재료를 이용해 실행 흐름을 설계할 차례다.

이 장의 목표는 세 가지다.

• 복잡한 작업을 하위 작업으로 나누는 planner-executor 구조를 이해한다.

• 사용자 요청을 적절한 실행자에게 보내는 router를 설계한다.

• 여러 에이전트를 함께 쓸 때 필요한 역할 분담, 상태 공유, 종료 조건을 정한다.

중요한 전제는 단순하다. 에이전트가 복잡해질수록 필요한 것은 "더 긴 프롬프트"가 아니라 "더 명확한 오케스트레이션"이다. 오케스트레이션은 여러 작업자, 도구, 상태, 조건을 하나의 흐름으로 조정하는 설계다.

왜 이 주제가 중요한가

단일 에이전트는 처음에는 편하다. 하나의 프롬프트에 역할을 많이 넣고, 도구를 여러 개 붙이면 그럴듯하게 동작한다. 그러나 실제 서비스에서는 곧 문제가 생긴다.

• 도구가 많아질수록 잘못된 도구를 고른다.

• 작업이 길어질수록 중간 목표를 잊는다.

• 실패했을 때 어느 단계가 잘못됐는지 찾기 어렵다.

• 모든 요청을 고성능 모델로 처리해 비용이 커진다.

• 여러 문서, 여러 관점, 여러 검증이 필요한 작업에서 컨텍스트가 비대해진다.

그래서 복잡한 에이전트는 보통 역할을 나눈다. 계획을 세우는 역할, 실행하는 역할, 분류하는 역할, 검토하는 역할을 분리한다. LangChain의 plan-and-execute 설명에서도 계획 단계와 실행 단계를 분리하면 매번 큰 모델을 호출하지 않고, 하위 작업에는 더 작은 모델이나 도구를 쓸 수 있다는 장점을 강조한다¹.

다만 멀티 에이전트는 만능 해법이 아니다. 에이전트가 3개가 되면 지능이 3배가 되는 것이 아니라, 호출 횟수와 디버깅 지점이 먼저 늘어난다. 여러 에이전트를 쓰면 단일 에이전트보다 토큰 비용과 추적 난이도가 몇 배로 커질 수 있다. 따라서 "복잡하니까 멀티 에이전트"가 아니라 "명확한 이득이 있으니까 멀티 에이전트"여야 한다.

핵심 개념 설명

Planner-executor 구조

Planner-executor 구조는 말 그대로 계획자와 실행자를 분리하는 방식이다.

Planner는 다음을 만든다.

• 하위 작업 목록

• 각 작업의 입력과 출력

• 성공 기준

• 필요한 도구 또는 담당자

• 재시도와 중단 조건

Executor는 다음에 집중한다.

• 지정된 도구 실행

• 결과 수집

• 에러 보고

• 상태 업데이트

• 실행 로그 남기기

좋은 planner는 "검색한다 → 요약한다 → 답한다"처럼 모호한 계획을 만들지 않는다. 대신 실행 가능한 단위로 쪼갠다.

예를 들어 "최근 1년간 전기차 배터리 리콜 사례를 조사해 보고서로 정리해줘"라는 요청이 들어왔다고 하자.

나쁜 계획은 이렇다.

1. 전기차 배터리 리콜을 조사한다.

2. 보고서를 작성한다.

좋은 계획은 이렇다.

1. 조사 범위를 최근 1년, 전기차 배터리, 제조사 리콜로 제한한다.

2. 최소 3개 이상의 신뢰 가능한 출처에서 사례를 수집한다.

3. 사례별로 제조사, 날짜, 원인, 영향, 조치 내용을 추출한다.

4. 중복 사례를 병합한다.

5. 표와 요약 문단으로 보고서를 작성한다.

6. 출처 누락, 날짜 불일치, 과장 표현을 검토한다.

여기서 핵심은 "작업 목록"만이 아니다. 각 단계의 성공 기준이 있어야 한다. 성공 기준이 없으면 executor는 아무 결과나 반환하고, planner는 완료 여부를 판단하지 못한다.

Plan은 계약이어야 한다

운영 가능한 plan은 자연어 메모가 아니라 계약에 가깝다. 최소한 다음 필드를 포함하는 것이 좋다.

{
  "task_id": "research_1",
  "goal": "최근 1년간 전기차 배터리 리콜 사례 수집",
  "assignee": "research_agent",
  "input": {
    "period": "last_12_months",
    "topic": "EV battery recall"
  },
  "success_criteria": [
    "출처 3개 이상",
    "제조사, 날짜, 원인, 조치 포함"
  ],
  "max_attempts": 2,
  "on_failure": "ask_clarification"
}

이런 구조를 쓰면 사람이 읽기 쉽고, 시스템도 검증하기 쉽다. 특히 task_id, success_criteria, max_attempts는 추적과 평가에 중요하다.

Re-planning과 종료 조건

계획은 한 번 만들고 끝나는 것이 아니다. 실행 중 다음 상황이 생기면 재계획이 필요하다.

• 필요한 정보가 검색되지 않는다.

• 도구 호출이 실패한다.

• 사용자의 요청이 모호하다는 사실이 뒤늦게 드러난다.

• 중간 결과가 성공 기준을 만족하지 못한다.

• 위험 작업이 포함되어 승인이 필요하다.

하지만 재계획에도 한도가 필요하다. "될 때까지 다시 해봐"는 운영 정책이 아니다. 다음과 같은 종료 조건을 둬야 한다.

• 최대 반복 횟수 도달

• 동일 에러 2회 이상 반복

• 필수 입력 누락

• 비용 한도 초과

• 승인 필요 상태 도달

• 성공 기준 충족

종료 조건이 없는 planner는 무한 루프를 만든다. 무한 루프는 비용 문제이기도 하지만, 사용자 신뢰 문제이기도 하다.

Router의 역할

Router는 입력을 보고 다음 경로를 결정하는 구성 요소다. 라우터는 에이전트, 도구, 모델, 워크플로 중 어디로 보낼지 판단한다.

라우팅 대상은 다양하다.

• 고객 문의 → 결제 에이전트, 기술지원 에이전트, 일반 안내 에이전트

• 문서 요청 → 요약 워크플로, 계약 검토 워크플로, 번역 워크플로

• 모델 선택 → 작은 모델, 큰 모델, 특화 모델

• 위험도 분류 → 자동 실행, 사용자 확인, 관리자 승인

라우터를 만들 때는 세 가지 방식을 비교해야 한다.

실무에서는 하이브리드가 자주 쓰인다. 먼저 규칙으로 명확한 케이스를 처리한다. 예를 들어 "환불", "결제 실패", "청구서"가 있으면 결제 경로로 보낸다. 민감정보, 금지 요청, 권한 없는 작업도 규칙으로 먼저 차단한다. 그다음 애매한 요청만 LLM 라우터에 보낸다.

Microsoft의 멀티 에이전트 참조 아키텍처도 가벼운 분류기로 먼저 의도를 판단하고, 확신이 낮을 때 더 비싼 LLM으로 넘기는 semantic router 패턴을 제시한다². 이 방식은 비용을 줄이면서도 애매한 요청의 품질을 유지하는 데 도움이 된다.

Fallback과 clarification

라우터에서 가장 위험한 설계는 "무조건 하나를 고르게 하는 것"이다. 실제 사용자 요청은 자주 모호하다.

예를 들어 사용자가 "계약서 확인해줘"라고 했다면 다음 중 무엇인지 알 수 없다.

• 요약을 원하는가?

• 위험 조항 검토를 원하는가?

• 법무팀 제출용 표를 원하는가?

• 서명해도 되는지 판단을 원하는가?

이때 라우터가 억지로 계약 검토 에이전트에 보내면 잘못된 결과가 나올 수 있다. 모호한 요청에는 fallback 경로가 필요하다.

• clarification: 사용자에게 추가 질문

• safe default: 읽기 전용 요약 경로로 제한

• human handoff: 담당자 검토로 전달

• reject: 정책상 처리 불가 안내

• multi-route: 여러 에이전트에 병렬 요청 후 종합

운영 라우터는 "정답 경로"뿐 아니라 "모를 때의 경로"를 가져야 한다.

멀티 에이전트 패턴

Orchestrator-subagent

Orchestrator-subagent 패턴은 중앙 조정자가 하위 에이전트를 도구처럼 호출하는 구조다. 사용자는 orchestrator와만 대화한다. 하위 에이전트는 검색, 요약, 코드 분석, 문서 검토처럼 특정 작업을 맡는다.

이 패턴의 장점은 통제가 쉽다는 것이다. 모든 호출이 orchestrator를 거치므로 로그와 권한을 관리하기 좋다. 단점은 orchestrator가 병목이 될 수 있다는 점이다.

문서 조사·보고서 작성 사례에서는 다음처럼 나눌 수 있다.

• orchestrator: 전체 목표, 계획, 최종 응답 관리

• research_agent: 자료 검색과 출처 수집

• extraction_agent: 표에 넣을 항목 추출

• writer_agent: 보고서 초안 작성

• critic_agent: 누락, 과장, 출처 오류 검토

LangChain 문서도 멀티 에이전트를 반드시 써야 하는 것은 아니며, 단일 에이전트가 너무 많은 도구를 가져 잘못 선택하거나, 전문 컨텍스트를 분리해야 하거나, 병렬 처리가 필요할 때 유용하다고 설명한다³. 이 기준은 실무 판단에 중요하다.

Supervisor-worker

Supervisor-worker는 관리자와 작업자 구조다. supervisor는 작업을 분해하고, worker에게 할당하고, 결과를 합친다. orchestrator-subagent와 비슷하지만, supervisor가 더 적극적으로 계획과 품질 관리를 수행한다.

보고서 작성에서는 supervisor가 "시장 동향", "기술 동향", "규제 동향"을 각각 worker에게 맡기고, 마지막에 하나의 문서로 합친다.

이 구조는 결과물이 하나로 통합되어야 할 때 좋다. 단점은 supervisor의 판단이 틀리면 전체 작업이 흔들린다는 점이다. 따라서 supervisor의 출력도 평가 대상이어야 한다.

Sequential pipeline

Sequential pipeline은 정해진 순서대로 에이전트를 연결하는 방식이다.

예시는 다음과 같다.

1. parser_agent: 문서에서 텍스트 추출

2. extractor_agent: 핵심 항목 추출

3. writer_agent: 초안 작성

4. compliance_agent: 정책 위반 검토

5. formatter_agent: 최종 형식 정리

이 패턴은 예측 가능하고 디버깅이 쉽다. 각 단계의 입력과 출력이 명확하기 때문이다. 그러나 앞 단계가 틀리면 뒤 단계가 그 오류를 이어받는다. 그래서 단계 사이에 품질 게이트를 넣는 것이 좋다.

Parallel research

Parallel research는 독립적인 조사 작업을 동시에 실행하는 방식이다. 예를 들어 하나의 보고서를 만들 때 다음 세 작업은 병렬로 진행할 수 있다.

• 시장 규모 조사

• 경쟁사 사례 조사

• 규제 변화 조사

병렬 처리는 지연 시간을 줄이고 관점을 넓힌다. 하지만 결과 충돌을 해결해야 한다. 어떤 출처를 더 신뢰할지, 날짜가 다른 자료를 어떻게 병합할지, 중복 내용을 어떻게 제거할지 정해야 한다.

Microsoft Azure의 에이전트 오케스트레이션 가이드도 병렬 패턴을 fan-out/fan-in 구조로 설명하며, 여러 에이전트의 결과를 집계할 때 투표, 가중 병합, 요약 합성 같은 전략이 필요하다고 정리한다⁴.

Critic loop

Critic loop는 생성자와 검토자를 분리하는 방식이다.

• generator: 초안 작성

• critic: 기준에 따라 검토

• generator: 피드백 반영

• critic: 재검토

이 패턴은 보고서, 코드, 정책 문서처럼 품질 기준이 있는 결과물에 유용하다. 단, critic이 막연히 "더 개선하세요"라고 말하면 루프가 길어진다. critic은 구체적인 실패 사유를 반환해야 한다.

좋은 critic 출력은 다음과 같다.

{
  "status": "fail",
  "issues": [
    {
      "type": "missing_source",
      "location": "시장 규모 문단",
      "message": "수치의 출처가 없음"
    },
    {
      "type": "unsupported_claim",
      "location": "결론",
      "message": "가장 빠르게 성장한다는 표현의 근거 부족"
    }
  ],
  "next_action": "revise"
}

critic loop에도 최대 반복 횟수가 필요하다. 보통 1~2회면 충분하다. 그 이상 반복되면 사람 검토로 넘기는 편이 낫다.

쉬운 비유 또는 사례

멀티 에이전트는 신문사 편집국과 비슷하다.

기자가 모든 일을 혼자 하면 빠를 수는 있다. 하지만 큰 기획 기사를 만들 때는 역할을 나눈다. 취재 기자는 자료를 모은다. 데이터 기자는 수치를 검증한다. 편집자는 글의 구조를 잡는다. 데스크는 제목과 법적 위험을 검토한다.

여기서 중요한 것은 "사람이 많다"가 아니다. 역할과 마감 기준이 명확하다는 점이다.

에이전트도 같다. research_agent, writer_agent, critic_agent를 만든다고 자동으로 품질이 좋아지지 않는다. 각 에이전트가 무엇을 입력받고, 무엇을 출력하며, 언제 멈추는지 정해야 한다.

나쁜 멀티 에이전트는 회의만 많은 조직과 같다. 서로 비슷한 말을 반복하고, 결론은 늦게 나오며, 책임 소재도 흐리다. 좋은 멀티 에이전트는 작은 팀처럼 움직인다. 각자 맡은 일이 있고, 결과물 형식이 정해져 있으며, 최종 책임자가 있다.

직접 해보는 실습

이번 실습에서는 같은 리서치 과제를 세 가지 방식으로 실행해 비교한다.

과제는 다음과 같다.

"최근 1년간 국내외 AI 에이전트 도입 사례 5개를 조사하고, 산업, 사용 목적, 기대 효과, 위험 요소를 표로 정리한 뒤 5문장 요약을 작성하라."

실습 A: 단일 에이전트

먼저 하나의 에이전트에 모든 일을 시킨다.

요청 예시는 다음과 같다.

너는 리서치 에이전트다.
최근 1년간 국내외 AI 에이전트 도입 사례 5개를 조사하고,
산업, 사용 목적, 기대 효과, 위험 요소를 표로 정리한 뒤
5문장 요약을 작성하라.
출처를 함께 남겨라.

실행 후 다음을 기록한다.

• 총 모델 호출 수

• 총 토큰 수

• 실행 시간

• 출처 개수

• 표의 누락 항목

• 확인되지 않은 주장 수

• 사용자가 읽기에 충분한지 1~5점 평가

단일 에이전트는 구현이 쉽다. 그러나 작업이 길어질수록 검색, 추출, 작성, 검증이 뒤섞인다.

실습 B: Planner-executor

이번에는 planner와 executor를 분리한다.

Planner에게는 다음만 시킨다.

사용자 요청을 실행 가능한 단계로 분해하라.
각 단계에는 task_id, goal, required_input, output_format,
success_criteria, max_attempts를 포함하라.
직접 조사하거나 답변하지 말고 계획만 작성하라.

예상 plan은 다음과 비슷하다.

[
  {
    "task_id": "collect_cases",
    "goal": "AI 에이전트 도입 사례 5개 수집",
    "output_format": "case_list",
    "success_criteria": ["최근 1년", "출처 포함", "사례 5개"]
  },
  {
    "task_id": "extract_fields",
    "goal": "산업, 사용 목적, 기대 효과, 위험 요소 추출",
    "output_format": "table_rows",
    "success_criteria": ["각 사례마다 4개 필드 존재"]
  },
  {
    "task_id": "write_summary",
    "goal": "5문장 요약 작성",
    "output_format": "paragraph",
    "success_criteria": ["5문장", "과장 표현 없음"]
  },
  {
    "task_id": "verify",
    "goal": "출처와 주장 검증",
    "output_format": "issue_list_or_pass",
    "success_criteria": ["출처 누락 없음", "날짜 오류 없음"]
  }
]

Executor는 plan의 첫 단계부터 실행한다. 각 단계가 끝날 때 state에 결과를 저장한다.

state 예시는 다음과 같다.

{
  "user_request": "AI 에이전트 도입 사례 조사",
  "plan": [],
  "current_task_id": "collect_cases",
  "case_list": [],
  "table_rows": [],
  "summary": "",
  "issues": [],
  "attempt_count": 0,
  "status": "running"
}

비교할 점은 명확하다. 단일 에이전트보다 호출 수는 늘 수 있다. 하지만 중간 결과가 구조화되어 품질 검토와 재실행이 쉬워진다.

실습 C: Subagent 실험

이번에는 역할을 나눈다.

• planner_agent: 작업 분해

• search_agent: 사례 수집

• extraction_agent: 표 항목 추출

• writer_agent: 요약 작성

• critic_agent: 검증

라우팅 규칙은 단순하게 시작한다.

collect_cases → search_agent
extract_fields → extraction_agent
write_summary → writer_agent
verify → critic_agent

그다음 병렬 조사도 실험한다.

• search_agent_1: 국내 사례

• search_agent_2: 해외 사례

• search_agent_3: 위험 요소 중심 조사

마지막에 writer_agent가 결과를 합친다.

실습 결과는 다음 표로 비교한다.

결과를 보면 멀티 에이전트가 항상 이기지 않는다는 것을 알게 된다. 간단한 과제에서는 단일 에이전트가 더 싸고 빠를 수 있다. 반대로 출처 검증, 병렬 조사, 역할별 전문성이 필요한 과제에서는 subagent 구조가 더 안정적일 수 있다.

흔한 실수와 오류 분석

실수 1: Planner가 너무 많은 일을 한다

Planner가 계획뿐 아니라 조사와 판단까지 하려고 하면 구조가 흐려진다. Planner는 실행하지 않는다. Planner는 "무엇을 할지"와 "성공 기준이 무엇인지"를 정한다.

실수 2: Executor가 계획을 무시한다

Executor가 매번 자기 판단으로 다른 도구를 고르면 planner-executor 구조의 의미가 사라진다. Executor에게도 제한이 필요하다. 허용된 도구, 입력 스키마, 최대 재시도 횟수를 정해야 한다.

실수 3: Router가 항상 하나의 경로만 고른다

모호한 요청은 억지로 분류하지 말아야 한다. confidence가 낮으면 clarification으로 보내야 한다. "계약서 확인"처럼 의도가 넓은 요청은 추가 질문이 더 안전하다.

실수 4: 모든 subagent가 비슷한 프롬프트를 가진다

이름만 다른 에이전트는 멀티 에이전트가 아니다. search_agent와 critic_agent가 같은 지시문, 같은 도구, 같은 출력 형식을 갖고 있다면 비용만 늘어난다. 각 역할의 입력, 출력, 금지 행동이 달라야 한다.

실수 5: 공유 state를 아무나 수정한다

여러 에이전트가 같은 state를 동시에 수정하면 충돌이 생긴다. 병렬 작업에서는 각 에이전트가 고유한 key에 결과를 써야 한다.

예를 들어 다음은 위험하다.

{
  "result": "..."
}

다음처럼 분리하는 편이 낫다.

{
  "domestic_research_result": "...",
  "global_research_result": "...",
  "risk_research_result": "..."
}

실수 6: 종료 조건이 없다

critic이 계속 fail을 반환하고 generator가 계속 수정하면 비용이 폭증한다. max_revision_count를 두고, 초과하면 human review로 넘겨야 한다.

실수 7: 멀티 에이전트를 너무 일찍 도입한다

멀티 에이전트는 마지막 카드에 가깝다. 먼저 단일 에이전트와 명확한 tool use로 해결해본다. 그래도 도구 선택 오류, 컨텍스트 과부하, 병렬 처리 필요, 보안 경계 분리가 해결되지 않을 때 멀티 에이전트를 도입한다.

RouteLLM 같은 모델 라우팅 연구와 도구들은 요청 난이도에 따라 강한 모델과 약한 모델을 나눠 쓰면 품질을 유지하면서 비용을 줄일 수 있음을 보여준다⁵. 멀티 에이전트에서도 같은 원칙이 적용된다. 모든 하위 에이전트를 가장 비싼 모델로 만들 필요는 없다.

최근의 MAS 라우팅 연구도 단순히 어떤 LLM을 고를지만이 아니라 협업 모드, 역할 배정, 모델 선택을 함께 결정해야 멀티 에이전트 비용을 줄일 수 있다고 본다⁶. 즉 멀티 에이전트의 핵심은 "많이 호출하기"가 아니라 "필요한 역할을 필요한 만큼만 호출하기"다.

요약

Planner, router, multi-agent는 복잡한 에이전트의 실행 흐름을 다루는 핵심 구조다.

Planner는 작업을 나누고 성공 기준을 만든다. Executor는 도구 실행과 결과 보고에 집중한다. Router는 요청을 적절한 경로로 보낸다. Multi-agent는 전문 역할을 나눠 병렬 처리, 검증, 컨텍스트 분리를 가능하게 한다.

하지만 복잡한 구조는 공짜가 아니다. 호출 수, 토큰 비용, 지연 시간, 로그 분석 난이도가 증가한다. 따라서 다음 순서로 판단하는 것이 좋다.

1. 직접 모델 호출로 해결 가능한가?

2. 단일 에이전트와 도구 몇 개로 충분한가?

3. planner-executor 분리만으로 충분한가?

4. router로 경로를 나누면 충분한가?

5. 정말 subagent가 필요한가?

좋은 에이전트 설계는 큰 구조를 자랑하지 않는다. 필요한 만큼만 나누고, 각 단계의 책임과 종료 조건을 명확히 한다.

퀴즈

1. Planner와 executor를 분리하는 가장 큰 이유는 무엇인가?

2. 좋은 plan에 포함되어야 할 필드는 무엇인가? 세 가지 이상 적어보라.

3. Router를 규칙 기반으로 만들 때의 장점과 한계는 무엇인가?

4. LLM 기반 router가 적합한 상황은 언제인가?

5. 모호한 요청을 라우터가 처리할 때 필요한 fallback 경로 두 가지를 적어보라.

6. Sequential pipeline과 parallel research의 차이는 무엇인가?

7. Critic loop에서 반드시 필요한 제한 조건은 무엇인가?

8. 멀티 에이전트를 도입하면 비용이 증가하는 이유를 설명해보라.

9. Subagent를 만들 때 "이름만 다른 에이전트"가 되지 않으려면 무엇을 정의해야 하는가?

10. 다음 요청을 어떤 구조로 처리할지 설계해보라. "우리 회사 보안 정책 문서를 읽고, 개인정보 처리 관련 위험 조항을 찾아 수정안을 제안해줘."

체크리스트

• Planner가 실행이 아니라 계획에 집중하는가?

• 각 task에 입력, 출력, 성공 기준이 있는가?

• Executor가 허용된 도구와 범위 안에서만 실행하는가?

• 재계획 조건과 최대 반복 횟수가 있는가?

• Router가 confidence를 반환하는가?

• 모호한 요청에 clarification 경로가 있는가?

• 금지 요청과 위험 작업을 먼저 차단하는 규칙이 있는가?

• Subagent별 역할, 도구, 출력 형식이 구분되어 있는가?

• 병렬 작업에서 state key 충돌이 없는가?

• 최종 결과를 합성하는 책임자가 명확한가?

• 비용, 토큰, 지연 시간, 실패율을 기록하는가?

• 멀티 에이전트 도입 이유가 단일 에이전트 대비 명확한가?

다음 장 연결

이번 장에서는 복잡한 작업을 계획하고, 라우팅하고, 여러 에이전트로 나누는 방법을 배웠다. 그러나 실제 서비스에서는 한 가지 질문이 더 남는다.

"에이전트가 실행해도 되는 작업과 반드시 사람의 승인이 필요한 작업을 어떻게 구분할 것인가?"

Planner가 좋은 계획을 세워도, router가 올바른 경로를 골라도, executor가 위험한 작업을 바로 실행하면 사고가 난다. 예를 들어 계약서 발송, 결제 취소, 고객 정보 수정, 외부 이메일 전송은 자동 실행 전에 확인이 필요할 수 있다.

다음 장에서는 human approval과 guardrails를 다룬다. 승인 정책, 사용자 확인 UX, 실행 전 차단, 실행 후 감사 로그를 설계하는 방법을 배운다.

참고

¹LangChain Plan-and-Execute Agents

²Microsoft Multi-Agent Reference Architecture Patterns

³LangChain Multi-agent documentation

⁴AI Agent Orchestration Patterns - Azure Architecture Center

⁵RouteLLM: An Open-Source Framework for Cost-Effective LLM Routing

⁶MasRouter: Learning to Route LLMs for Multi-Agent Systems