Every Company Is Building Agents That Can't Work Together - Justin Schroeder, Standard Agents

한 줄 핵심

기업들이 에이전트를 직접 만드는 이유는 단순히 모델이 좋아서가 아니라, 비즈니스 핵심 프로세스를 통제 가능하고 신뢰 가능하며 성과가 검증되는 형태로 묶어야 하기 때문이며, 이를 위해서는 툴·프롬프트가 아니라 하네스까지 표준화된 agent runtime이 필요하다는 주장이다.

시간별 요약

1. 0:00
   왜 기업은 아직도 에이전트를 만드는가 MCP와 markdown 스킬만으로 충분하다는 통념과 달리, 실제 시장은 여전히 업무용 에이전트를 만들고 있다. 그 이유는 기업의 핵심 프로세스가 AI 도입의 중심이기 때문이다.
2. 1:02
   통합·신뢰·효과가 에이전트 선택을 좌우한다 워런티 처리, 일정 조율, 허가 신청처럼 비즈니스에 깊이 박힌 프로세스는 통합이 필요하고, 에이전트가 예기치 않은 행동을 하지 않도록 강하게 제한되어야 하며, 실제로 업무 성과를 올려야 한다. 그래서 범용 대형 모델보다 좁은 업무에 특화된 에이전트가 더 적합하다.
3. 9:00
   문제는 에이전트가 아니라 하네스다 에이전트는 겉보기보다 구현이 어렵고, 루프 제어·병렬 실행·복구·상태 관리까지 포함한 하네스가 필요하다. 그런데 하네스가 표준이 없으면 서로 호환되지 않고, 결국 대규모 공유와 조합이 불가능해진다.
4. 12:00
   표준 에이전트 사양과 런타임의 설계 해결책은 표준이다. 표준 에이전트 사양은 vendor agnostic, domain-specific, model-coupled, composable, portable을 핵심 원칙으로 삼고, runtime 안에 model, prompt, tools, sub agents, hooks, effects, thread를 명시적으로 정의한다. TypeScript로 코드를 패키징해 배포하고, 어떤 언어의 runtime이든 사양만 맞으면 실행할 수 있게 설계한다.
5. 29:00
   표준 에이전트 빌더와 실제 배포 표준 에이전트 빌더는 문서 한 장을 바탕으로 특화된 에이전트를 빠르게 생성하고, 로컬과 클라우드 어디서나 실행되며, MCP 서버나 웹챗봇 같은 형태로 외부에 노출될 수 있다. 데모는 배터리 워런티 클레임 같은 좁은 업무일수록 표준화된 런타임 위에서 더 빨리 만들고 더 정확하게 운영할 수 있음을 보여준다.

실무 인사이트

• 기업용 에이전트는 모델 성능보다도 업무 범위의 고정, 권한 제한, 실행 재현성이 더 중요하므로, '무엇을 할 수 있는가'보다 '무엇만 하게 할 것인가'를 먼저 설계해야 한다.
• 에이전트를 개별 프로젝트가 아니라 표준 런타임 위의 패키지로 보면, 재사용성과 조합성이 크게 올라가고 서로 다른 팀·공급자가 만든 에이전트를 붙이기 쉬워진다.
• 실무에서는 범용 슈퍼 에이전트보다 한 가지 업무를 잘하는 소형 에이전트를 여러 개 만들고, 필요할 때 상위 에이전트나 MCP로 묶는 방식이 더 현실적이다.