# Philosophy — 핵심 철학

이 문서는 AgentOutO의 핵심 철학을 정의한다. 여기에 명시된 원칙은 **절대적**이며, 어떤 기능 요구보다 우선한다.

---

## 1. 오케스트레이터 거부

기존 멀티 에이전트 프레임워크(CrewAI, AutoGen 등)는 "오케스트레이터 패턴"을 사용한다 — 하나의 base 에이전트가 다른 에이전트를 관리하는 계층 구조.

**AgentOutO는 이를 거부한다.**

오케스트레이터 패턴의 문제:
- 단일 에이전트가 병목이 된다.
- 하위 에이전트는 상위 에이전트를 호출할 수 없다.
- 동적인 협업이 불가능하다.
- 시스템 구조가 에이전트 행동을 제약한다.

AgentOutO에서는 **어떤 에이전트든 다른 어떤 에이전트를 호출할 수 있다.** 계층이 없다.

---

## 2. 다섯 가지 핵심 원칙

### 원칙 1: 모든 에이전트는 완전히 대등하다

- Base 에이전트가 존재하지 않는다.
- 매니저 에이전트, 컨트롤러 에이전트가 존재하지 않는다.
- 모든 에이전트는 동일한 인터페이스를 가진다.
- 에이전트 간 권한 차이가 없다.

### 원칙 2: 모든 에이전트는 모든 에이전트를 호출할 수 있다

- 호출 허용 목록(`calls=[]`)이 존재하지 않는다.
- 자기 자신을 호출할 수 있다 (A→A→A→...).
- 순환 호출이 허용된다 (A→B→A→B→...).
- 호출 깊이 제한이 없다.
- 이런 제한이 필요하면 `instructions`(역할 설명)으로 자연어로 걸어야 한다. 런타임이 강제하는 것이 아니라 LLM이 판단하는 것이다.

### 원칙 3: 모든 에이전트는 모든 도구를 사용할 수 있다

- 에이전트별 도구 할당(`tools=[]`)이 존재하지 않는다.
- 모든 도구는 전역으로 등록된다.
- 모든 에이전트의 LLM 호출에 모든 도구가 제공된다.

### 원칙 4: 메시지는 전달과 반환 2종류뿐이다

- **전달 메시지 (Forward)**: 호출자 → 피호출자에게 보내는 메시지
- **반환 메시지 (Return)**: 피호출자 → 호출자에게 돌려보내는 응답
- 다른 메시지 타입은 존재하지 않는다.
- 반환은 항상 호출한 에이전트에게만 돌아간다.

### 원칙 5: 사용자는 LLM이 없는 에이전트일 뿐이다

- `run()` 함수가 에이전트를 호출하는 것은 에이전트가 `call_agent`로 에이전트를 호출하는 것과 **내부적으로 완전히 동일하다.**
- 사용자를 위한 별도의 도구, 프로토콜, 인터페이스가 존재하지 않는다.
- 사용자는 전달 메시지를 보내고, 반환 메시지를 받는다. 그게 전부다.

---

## 3. 제한 없음 — 완전 자유

시스템 레벨의 제한은 **일체 존재하지 않는다:**

| 항목 | 정책 |
|------|------|
| 호출 깊이 제한 | 없음. 무한대로 호출 가능. |
| 순환 호출 방지 | 없음. A→B→A→B→... 허용. |
| 자기 호출 차단 | 없음. A→A→A→... 허용. |
| 동시 호출 제한 | 없음. |
| 에이전트별 도구 제한 | 없음. |
| 에이전트별 호출 제한 | 없음. |

**어떠한 제한이든, `instructions`(역할 설명)으로 자연어로 걸어야 한다.** 런타임이 강제하는 것이 아니라 LLM이 판단하는 것이다.

예: 순환 호출을 막고 싶으면 `instructions="... 절대로 이미 대화 컨텍스트에 등장한 에이전트를 다시 호출하지 마라."`와 같이 지시한다.

---

## 4. 설계 결정의 근거

### 왜 에이전트별 도구 제한이 없는가?

도구 제한은 오케스트레이터 패턴의 산물이다. "이 에이전트는 이 도구만 쓸 수 있다"는 것은 계층 구조를 전제한다. 피어 간 자유 호출 시스템에서는 모든 에이전트가 동등하므로 도구 접근도 동등해야 한다.

### 왜 호출 제한이 없는가?

호출 제한은 정적 그래프를 만든다. 정적 그래프는 에이전트의 자율성을 제거한다. LLM이 상황에 따라 동적으로 누구를 호출할지 판단해야 한다.

### 왜 사용자를 특별 취급하지 않는가?

사용자를 특별 취급하면 "사용자→에이전트" 경로와 "에이전트→에이전트" 경로가 갈라진다. 이는 두 가지 코드 경로를 유지해야 함을 의미하고, 버그의 원인이 된다. 하나의 메커니즘으로 통일하는 것이 더 단순하고 견고하다.

### 왜 메시지 타입이 2종류뿐인가?

복잡한 프로토콜은 복잡한 버그를 만든다. 전달과 반환만으로 모든 멀티 에이전트 패턴을 표현할 수 있다. 추가 메시지 타입이 필요한 것처럼 보이는 경우, 전달/반환의 조합으로 해결할 수 있다.

---

## 5. 철학 변경 시

이 철학은 프로젝트의 근간이다. 변경하려면:

1. 사용자(프로젝트 소유자)에게 명시적으로 확인을 받아야 한다.
2. 변경 이유를 이 문서에 기록해야 한다.
3. 변경에 의해 영향을 받는 모든 문서와 코드를 함께 업데이트해야 한다.

**AI가 독단적으로 철학을 변경하거나 위배하는 것은 허용되지 않는다.**
