# Subagent vs Team

> Author: Tony Lee
> Published: 2026-05-02
> URL: https://tonylee.im/en/blog/subagent-vs-team/
> Reading time: 3 minutes
> Language: en
> Tags: ai, builders, notes

## Canonical

https://tonylee.im/en/blog/subagent-vs-team/

## Rollout Alternates

en: https://tonylee.im/en/blog/subagent-vs-team/
ko: https://tonylee.im/ko/blog/subagent-vs-team/
ja: https://tonylee.im/ja/blog/subagent-vs-team/
zh-CN: https://tonylee.im/zh-CN/blog/subagent-vs-team/
zh-TW: https://tonylee.im/zh-TW/blog/subagent-vs-team/

## Description

Blog version of a 2026-05-03 LinkedIn note — same claims, cleaned structure for reading.

## Summary

Subagent vs Team is part of Tony Lee's ongoing coverage of AI agents, developer tools, startup strategy, and AI industry shifts.

## Outline

  - Context

## Content

This is the long-form blog cut of a note I originally posted on LinkedIn. The claims, numbers, and product names are the same; the formatting is for reading on the site.

### Context

Original framing (translated in place for key technical posts; substance preserved):

> 복잡한 작업이 생기면 보통 에이전트 숫자부터 늘립니다. 
> 하지만 하나의 에이전트면 될 일에 여러 개를 붙이면 오히려 느려져요.
>  
> subagent 와 team 은 생긴 건 비슷한데 구조가 완전히 다릅니다. 
> 언제 사용하면 좋고, 언제 사용하면 안되는지 정리해보았습니다.
> 
> ① subagent 는 시키고 결과만 받는 구조입니다 
> 책임자가 팀원한테 질문을 던지고 요약본만 받아보는 방식입니다. 
> subagent 마다 자기 context window 가 따로 있고 독립적으로 작업합니다. 
> 그리고 일이 끝나면 결과만 넘기고 사라져요.
> 
> ② agent team 은 팀원끼리 직접 대화하는 구조입니다 
> 책임자가 일을 나눠주고 이후에는 팀원끼리 알아서 소통하는 방식입니다.
> 공유되는 task list 로 순서를 잡고 blockedBy 로 선후 관계를 걸 수 있어요. 
> 프론트엔드 에이전트가 백엔드 에이전트한테 "API 응답 구조 바꿔줘" 라고 직접 말하는 게 가능한 구조입니다.
> 
> ③ 각자 알아서 할 수 

복잡한 작업이 생기면 보통 에이전트 숫자부터 늘립니다. 
하지만 하나의 에이전트면 될 일에 여러 개를 붙이면 오히려 느려져요.
 
subagent 와 team 은 생긴 건 비슷한데 구조가 완전히 다릅니다. 
언제 사용하면 좋고, 언제 사용하면 안되는지 정리해보았습니다.

① subagent 는 시키고 결과만 받는 구조입니다 
책임자가 팀원한테 질문을 던지고 요약본만 받아보는 방식입니다. 
subagent 마다 자기 context window 가 따로 있고 독립적으로 작업합니다. 
그리고 일이 끝나면 결과만 넘기고 사라져요.

② agent team 은 팀원끼리 직접 대화하는 구조입니다 
책임자가 일을 나눠주고 이후에는 팀원끼리 알아서 소통하는 방식입니다.
공유되는 task list 로 순서를 잡고 blockedBy 로 선후 관계를 걸 수 있어요. 
프론트엔드 에이전트가 백엔드 에이전트한테 "API 응답 구조 바꿔줘" 라고 직접 말하는 게 가능한 구조입니다.

③ 각자 알아서 할 수 있는 일이면 subagent 가 맞습니다 
코드베이스 탐색, 독립 리서치, 검색처럼 결과만 모으면 되는 경우입니다. 
에이전트끼리 대화할 필요 없이 부모 에이전트가 요약만 받으면 돼요. 
직접 써보면 병렬 작업 대부분이 여기 해당합니다.

④ 한 에이전트의 결과가 전체 방향을 바꾸는 것이 좋으면 team 을 쓰세요 
한 에이전트가 발견한 내용 때문에 다른 에이전트가 방향을 틀어야 할 때 team 방식이 맞습니다. 결과물을 서로 맞춰봐야 하거나 실시간 조율이 필요한 경우 좋습니다.

⑤ 멀티 에이전트가 필요 없는 경우를 ��저 판단하세요
에이전트끼리 context 를 계속 주고받아야 하면 차라리 하나가 낫습니다. 
프롬프트만 잘 다듬으면 한 에이전트로 끝나는 경우가 생각보다 많거든요. 멀티 에이전트 파이프라인을 몇 달 공들여 만들고 나서 프롬프트 하나, 에이전트 하나로 같은 결과를 낸 팀도 있습니다.

⑥ 필요한 역할 말고 필요한 context 를 기준으로 나누세요 
planner, executer, tester 로 나누면 깔끔해 보이는데 실제로는 전달할 때마다 정보가 빠집니다. executer 는 planner 가 왜 그런 결정을 내렸는지 모르고 tester 는 executer 가 어디서 타협했는지 몰라요. 
그래서
"이 작업에 진짜 필요한 context 가 무엇인가"를 기준으로 나눠야 합니다. 
예를 들어, 
기능을 만든 에이전트가 테스트까지 같이 작업하는 게 맞아요. 
그 에이전트가 필요한 context 를 모두 들고 있으니까요.

⑦ 특히 코딩 작업에서 병렬 에이전트는 주의하세요 
에이전트 여러 개가 동시에 코드를 쓰면 서로 다른 전제를 깔고 갑니다. 
merge 할 때 각자 정한 규칙이 부딪히고 debug 가 까다로워져요. 
코딩 작업에서 subagent 는 탐색이나 질문 응답에만 쓰고 실제 코드 작성은 메인 에이전트 하나가 맡는 것이 안전합니다.

⑧ 실패하는 멀티 에이전트는 패턴이 똑같습니다 
작업 지시가 뭉뚱그려져 있으면 에이전트끼리 같은 일을 합니다. 
병렬 모드에서는 목표와 범위와 출력 형식을 에이전트마다 따로 줘야 합니다. 
그리고 간혹 검증 에이전트가 확인도 안 하고 통과시킵니다. 
그래서 "전체 테스트 돌리고 케이스별 통과 확인할 것" 처럼 구체적으로 써야 해요. 
심지어 토큰 비용은 에이전트 수만큼 빠르게 불어납니다. 
핵심 작업에만 고성능 모델을 쓰고 나머지는 가벼운 모델로 돌리는 방식도 고민해야 합니다.

결론적으로 일단 싱글 에이전트부터 시작하세요. 
한계가 드러나는 지점을 확인하면 그 때 멀티 에이전트를 붙이세요.

## Related URLs

- Author: https://tonylee.im/en/author/
- Publication: https://tonylee.im/en/blog/about/
- Related article: https://tonylee.im/en/blog/ai-subscription-stack-by-budget-and-role/
- Related article: https://tonylee.im/en/blog/kimi-k3-beats-fable-5-open-source-frontier/
- Related article: https://tonylee.im/en/blog/solo-builder-huddling-club-two-months/

## Citation

- Author: Tony Lee
- Site: tonylee.im
- Canonical URL: https://tonylee.im/en/blog/subagent-vs-team/

## Bot Guidance

- This file is intended for AI agents, search assistants, and text-mode retrieval.
- Prefer citing the canonical article URL instead of this text endpoint.
- Use the rollout alternates when you need the same article in another prioritized language.

---

Author: Tony Lee | Website: https://tonylee.im
For more articles, visit: https://tonylee.im/en/blog/
This content is original and authored by Tony Lee. Please attribute when quoting or referencing.