MCP 서버를 삭제하고 다시 만든 이유 — Reducto의 에이전트 아키텍처

URL: https://www.youtube.com/watch?v=jJQoVkd5yLg 날짜: 2026-10-09 채널: aiDotEngineer (AI Engineer)

---

메타데이터

• 원문 제목: Why We Deleted Our MCP Server and Rebuilt It — Abhi Arya, Reducto
• 발표자: Abhi Arya, Product, Reducto
• 영상 길이: 16분 39초
• 행사: AI Engineer World's Fair 2026, San Francisco
• 주제: Agent-first software, MCP(Model Context Protocol), Agent Experience, 문서 처리 파이프라인
• 관련 링크: Reducto · MCP 문서 · 채용

---

📌 핵심 질문 / 이 영상이 다루는 핵심 논점

==에이전트가 틀렸을 때 누가 대가를 치르는지를 기준으로 Agent-first software의 아키텍처를 설계해야 한다.==

• 자율성(autonomy)만 극대화하는 Auto mode는 에이전트가 자신 있게 틀려도 사람이 알아차릴 수 없게 만든다.
• 사람에게 모든 설정 조절기(knobs)를 돌려주는 User-first 방식은 에이전트를 단순 챗봇으로 제한한다.
• 사용자를 위해 에이전트에 구조화된 능력, 상태(state), 검증기(validators)를 제공하고 사람이 결과를 검토하게 하는 방식이 Agent experience in service of the user다.

Reducto는 API 엔드포인트마다 MCP 도구 하나씩을 붙인 첫 서버를 팀 전체에 공개했다가 당일 실패했다. 에이전트는 고객 통화의 미완성 설명이나 Notion 페이지를 바탕으로 전체 문서 워크플로를 자신 있게 만들었지만, 사용자도 에이전트도 그 워크플로가 실제로 무엇을 했는지 설명할 수 없었다. Abhi Arya는 서버 전체를 한 번의 커밋으로 삭제하고, 실제 업무의 구조를 담은 더 적은 수의 도구와 파이프라인의 실시간 상태를 돌려주는 snapshot 도구로 다시 만들었다. 이후 confidence score와 bounding box로 결과의 불확실성을 드러내고, 애매한 상황에서는 추측하지 않고 질문하도록 만들었으며, 모든 세션을 계측해 사용량이 장기 가이드로 되돌아오는 자기 개선 루프를 구성했다.

1. Reducto가 해결하는 문제와 Agent-first의 재정의

Reducto의 경험은 문서 처리 제품의 핵심 문제가 모델의 데모 성능이 아니라 운영 환경에서 검증 가능한 결과를 만드는 아키텍처임을 보여준다.

1.1. 비정형 문서를 실제 운영 데이터로 바꾸는 문서 계층

1. Reducto의 역할
   1. Agentic document platform: 지저분하고 비정형적인 문서를 도구와 AI agent가 이해할 수 있는 데이터로 바꾼다.
   2. 모델과 데이터 사이의 계층: 모델과 원본 데이터 사이에 놓여 복잡한 레이아웃과 후처리(post-processing)를 처리한다.
2. 대규모 운영에서 얻은 관찰
   1. 30억 개 초과 문서: Harvey, Scale AI, 세계 상위 5개 글로벌 기술 기업, 헤지펀드 등의 고객을 통해 3년 동안 30억 개가 넘는 문서를 처리했다.
   2. 운영 장애의 다양성: 이 규모에서 문서가 production에서 깨지는 거의 모든 방식을 보게 되며, Reducto는 제품과 모델을 반복 개선했다.
3. 깨끗한 문서와 production 문서의 차이
   1. 깨끗한 문서에 프런티어 모델(frontier model)을 적용하는 일은 더 이상 아주 어렵지 않다. 클라우드에 무언가를 올리면 약 60%까지는 해결할 수 있다.
   2. 스캔 문서, 회전된 페이지(rotated pages) 같은 실제 문서에서는 기업 데이터의 대다수가 비정형이어서 모델이 환각(hallucination)을 일으키기 쉽다.
   3. Reducto는 이 문서 계층을 다루는 과정에서 자체적으로 많은 에이전트를 만들고 파이프라인을 설계해 왔다.

1.2. Mean Girls 스티커에서 시작한 질문

1. Abhi는 주말에 여자친구에게 영화 Mean Girls의 문구를 에이전트식으로 바꾼 스티커를 받았다. “Get in loser. We’re building agent-first software.”라는 문구였고, 소프트웨어 엔지니어답게 노트북에 붙였다.
2. AI 분야에서 일하지 않는 여자친구가 “Agent-first software가 뭐냐”고 물었고, 이 질문이 발표의 출발점이 됐다.
3. 좋은 harness, 좋은 API, 프롬프트 작성·반복 개선은 모델 최적화에 가깝다. 에이전트를 정말로 우선하는 것은 본질적으로 아키텍처 문제다.
4. 아키텍처는 “에이전트가 틀렸을 때 누가 대가를 치르는가(Who pays for the agent being wrong)?”라는 질문으로 귀결된다.

1.3. 세 가지 Agent-first 설계 버킷

1. Auto mode: 자율성을 최적화하는 방식
   1. 사용자는 프롬프트를 쓰고 에이전트가 원하는 대로 하도록 맡긴다.
   2. 에이전트는 틀릴 수밖에 없지만 자신이 하는 일을 매우 확신하는 것처럼 보인다. 사용자는 오류를 알 수 없고 고객·사용자에게 발생한 비용을 부담한다.
2. User-first: 인간 인터페이스를 최적화하는 방식
   1. 사용자에게 모든 조절기(knobs)를 제공한 뒤 실제로 많은 일을 하지 못하는 에이전트를 붙인다. 결과는 사실상 챗봇 경험이다.
   2. 사용자는 프롬프트로 제품을 활용하지 못하고, 에이전트도 제품 안에서 충분한 일을 하지 못한다. 사용자 이해도와 에이전트 능력을 동시에 제한한다.
3. Agent experience in service of the user
   1. 에이전트의 능력을 사용자가 진짜 원하는 일을 돕는 방향으로 구조화한다.
   2. 에이전트가 풍부하지만 범위가 정해진 능력(rich and scoped capabilities)을 사용하게 하고, 사람이 작업을 검증하게 한다.
   3. 이 관점은 Agent experience를 모델 자체가 아니라 context, capability, self-improvement의 문제로 바꾼다.

2. 설정이 아니라 결과를 향한 문서 파이프라인

Reducto의 사용자는 최종 결과보다 파이프라인 설정에 시간을 더 많이 쓰고 있었고, MCP는 이 간극을 줄이기 위한 첫 시도였다.

2.1. 기존 문서 파이프라인이 만든 병목

1. 자동화되는 업무의 흐름
   1. 문서를 파싱(parse)하고 분류(classify)하거나 섹션으로 나눈(split) 다음 필요한 정보를 추출(extract)한다.
   2. 송장 처리(invoicing), 계약 관리(contract management)처럼 사람의 입력이 필요한 업무가 대표적인 사용 사례다.
2. 설정에 갇힌 사용자
   1. 특히 영업팀이 결과가 아니라 설정(configuration)에 모든 시간을 쓰고 있었다.
   2. 레거시 인터페이스는 파이프라인을 직접 조립하도록 설계됐지만, agentic work 시대에는 최종 산출물에 최대한 빨리 도달하는 것이 더 중요하다.
3. MCP가 제시한 방향
   1. MCP 서버가 무거운 작업을 에이전트에게 맡기면 사용자는 사용 사례를 생각하고 프롬프트를 쓰는 정도만 부담하면 된다.
   2. Abhi는 Claude Code로 MVP를 만들고, 앱을 구동하는 모든 API 엔드포인트에 MCP 도구를 하나씩 붙여 거대한 파일 하나에 넣었다.

2.2. Version 1: API 엔드포인트마다 도구 하나

1. Abhi는 매우 구체적인 프롬프트를 작성하고 MCP를 Slack에 넣었다. 데모는 꽤 잘 작동했지만, 자신이 무엇을 만들고 있는지 정확히 알고 있는 매우 큐레이션된 환경이었다.
2. 따라서 standalone demo는 실제 품질에 대해 아무것도 알려주지 못했다. 팀 전체 공개가 진짜 테스트가 됐다.
3. 팀원들은 고객 통화의 어설픈 설명이나 Notion 페이지를 입력했다. 정제된 프롬프트가 없는 실제 입력에서 에이전트는 전체 워크플로를 처음부터 끝까지 만들었다.
4. 에이전트는 자신이 한 일이 모두 맞다고 확신했지만 사용자도 에이전트도 워크플로가 실제로 무엇을 했는지 설명하지 못했다.
5. 이것이 production에서 Auto mode가 주는 “rude awakening”이다. 에이전트는 “확실하지 않다”고 하지 않고 가진 모든 도구를 사용해 계속 진행했으며, 사람이 검증하거나 생각할 지점이 없었다.
6. Reducto는 시스템과 통신하는 무언가는 만들었지만 시스템과 실제로 함께 일할 수 있는 것은 만들지 못했다.

2.3. 삭제와 재설계: 프롬프트가 아닌 아키텍처

1. 시스템 프롬프트를 더 상세하게 만들거나 모델 가이드를 추가하는 것은 근본 해결책이 아니었다. 문제는 MCP와 통신하는 전체 파일의 아키텍처였다.
2. Abhi는 MCP에 사용했던 전체 파일을 한 번의 커밋으로 삭제했다.
3. 대체물은 더 많은 도구가 아니었다. 실제 업무의 구조를 담은 더 적은 수의 도구였다.

3. 실제 업무의 구조를 운반하는 MCP 도구

새 MCP는 모델이 프롬프트를 보고 업무 절차를 추측하도록 하지 않고, Reducto가 이미 알고 있는 올바른 구조를 도구 자체에 담았다.

3.1. 적은 도구, 더 강한 구조

1. 기존 방식은 에이전트가 workflow의 create step을 반복 호출하고 파이프라인을 올바르게 조립했기를 기도하는 방식이었다.
2. 재설계된 도구는 Reducto의 내부 대시보드와 제품이 작동하는 방식을 이해한다. 사용 가능한 동작 자체가 실제 업무의 구조를 반영한다.
3. 흔한 흐름은 문서를 분류하는 classify endpoint에서 extract node로 보내 후속 정보를 추출하는 것이다.
4. 모델이 이 연결을 프롬프트로 추측하지 않도록 'classify to extract'라는 하나의 도구로 만들었다.
5. 각 단계가 끝나면 다음에 실제로 무엇을 해야 하는지에 대한 문맥적 가이드를 받는다. 일부 도구는 이런 연결을 자동으로 chaining한다.
6. 에이전트가 무엇이 옳은지 스스로 추측하는 대신 옳은 경로를 안내받으며, 엔지니어가 이미 참이라고 알고 있는 부분은 자유롭게 즉흥적으로 바꾸지 못한다.

3.2. Stateless agent를 위한 snapshot 도구

1. 에이전트가 stateless이므로 현재 파이프라인의 실제 상태를 매번 추론하게 두면 변수 이름을 지어내거나 상태를 환각할 수 있다.
2. Reducto는 snapshot 도구를 추가했다. 이 도구는 파이프라인 전체 flow의 현재 live state와 표면화된 오류, 매우 구체적인 error code를 한 번에 돌려준다.
3. 에이전트는 변수 이름을 추측하는 대신 실제 상태를 참조하기 시작했다.
4. 프롬프트에서 문맥을 꺼내 구조(structure) 안으로 옮기자 guessing이 referencing으로 바뀌었다.
5. 도구가 파이프라인을 엔지니어와 제품 담당자가 원한 형태로만 만들게 하므로 사람은 어떤 일이 벌어졌는지 따라가고 MCP의 출력을 최종 사용자에게 설명할 수 있다.

3.3. API가 아니라 전문성을 건네라

1. 에이전트에게 API 자체를 그대로 건네지 말고, 올바른 패턴(patterns), 상태(state), 검증기(validators) 같은 전체 전문성(expertise)을 담은 도구를 건네야 한다.
2. 올바른 경로가 MCP가 선택할 수 있는 가장 쉬운 경로가 되도록 해야 한다.
3. 구조화된 도구는 구축(building) 단계의 결과를 읽기 쉽게 만들었지만, 실제 실행(runtime) 단계에서 결과 자체가 틀리면 누가 알아차릴지는 여전히 남아 있었다.

4. 조용히 실패하는 에이전트와 불확실성의 가시화

에이전트 시스템의 위험은 명시적인 예외가 아니라 정상적으로 완료된 것처럼 보이는 조용한 실패에 있다.

4.1. Runtime에서 발생하는 조용한 오류

1. 잘못된 schema를 사용했거나 사용자가 실제 사용 사례를 충분히 지정하지 않았을 때 에이전트가 무엇을 잘못했는지 바로 알아차리기 어렵다.
2. 전통적인 프로그램이라면 segmentation fault 같은 명시적 오류가 나올 수 있지만, 에이전트 파이프라인은 오류 없이 끝까지 실행될 수 있다.
3. 파이프라인이 문서 100개를 처리했는데 30페이지의 스캔을 놓칠 수 있고, 문서 유형을 지정하지 않아 잘못된 추출이 일어날 수도 있다.
4. 두 사례의 공통점은 에이전트가 매우 자신 있게 틀리고 자신의 불확실성이 완전히 보이지 않는다는 점이다.

4.2. 결과의 불확실성을 데이터로 반환하기

1. Reducto의 extract는 confidence score와 bounding box를 출력하며, 무엇이 잘못됐는지에 관한 정보까지 failure에 실어 보낸다.
2. Reducto는 이 정보를 모델에 다시 공급하는 도구를 만들었다.
3. 모델은 추출 schema를 반복해서 최적화하고 시간이 지나면서 더 정확한 문서 출력을 만든다.
4. 실패와 낮은 확신을 단순 성공/실패 표지가 아니라 다음 판단을 위한 문맥으로 바꾸는 방식이다.

4.3. 에이전트 자신의 불확실성도 표면화하기

1. 한 필드나 문서 유형을 두 가지로 읽을 수 있거나 한 번도 보지 못한 문서 유형을 만났다면, 임의의 해석을 선택해서는 안 된다.
2. 그렇다고 조용히 멈춰서도 안 된다. “이 문서를 두 가지 방식으로 읽을 수 있는데 어느 의미인가?”라고 사용자에게 물어야 한다.
3. Reducto의 eval은 흔들리는 가정을 세우는 에이전트를 실패로 처리하기 시작했다.
4. harness와 프롬프트에는 추측 대신 'ask user question' 도구를 사용하라는 가이드를 넣었다. Claude Code 같은 frontier harness의 질문 기능도 활용했다.
5. 평가와 보상은 guessing이 아니라 asking을 우대하도록 바뀌었다.
6. 판단은 에이전트 혼자에게 존재하지 않는다. 전체 파이프라인은 사용자가 감독하고, 에이전트의 confidence와 reasoning은 MCP의 프롬프트 가이드로 출력된다.
7. 새로운 것을 만들 때마다 에이전트는 무엇을 했고 왜 그렇게 했는지를 설명한다. 사용자는 이를 검토하며, 에이전트는 사용자가 쓴 문장만이 아니라 사용자가 원한 결과에 가까워지도록 동작한다.
8. 불확실성을 읽기 쉽게 만들고 최종 판단을 책임질 사람의 손에 남겨두면, 한 번의 명확화 질문이 문맥 제공, 능력 확장, human-in-the-loop 검증을 동시에 수행한다.

5. 세 가지 실패 모드의 공통 원인

겉으로는 Auto mode, 조용한 오답, 보상 해킹으로 보이지만 모두 사람이 검증할 수 있는 범위를 넘어선 자율성과 접근 권한에서 비롯된다.

5.1. 검증을 넘어선 자율성

1. 초기 MCP에는 아무도 검사할 수 없는 Auto mode가 있었다.
2. 틀린 답이 아무런 신호 없이 도착했고, 에이전트는 자신이 한 일을 숨기거나 보이지 않게 만들어 reward hacking으로 테스트를 통과할 수 있었다.
3. 공통된 모양은 에이전트가 사람보다 더 많은 자율성과 접근 권한을 가지고 사람이 그 결과를 검증할 수 없었다는 점이다.

5.2. 가장 강력하면서 가장 싸게 고칠 수 있는 지점

1. 파이프라인을 만들고 schema를 생성하고 올바른 문맥을 가져오는 구성 단계에서 에이전트의 지능이 가장 강력하게 작동한다.
2. 사람이 바로 옆에서 검토할 수 있으므로 이 단계의 실수가 가장 싸게 고칠 수 있다.
3. 이 인터페이스를 중심으로 구축하자 사람들이 무슨 일이 일어나는지 볼 수 있어 MCP의 사용자 만족도가 올라갔다.
4. 에이전트를 믿을 수 없는 문서 계층에는 Reducto를 사용해 정확한 파싱과 추출을 보장했다. 에이전트가 맡은 부분에서는 결과가 검증 가능하고 올바르며 사용자를 위한 것임을 보여 줘야 한다.
5. “Agents are just intelligence in a box.” 에이전트를 둘러싼 harness가 downstream 사용자에게 결과를 전달할 능력을 제공한다.

6. 계측으로 만든 자기 개선 루프

6.1. MCP 세션을 관찰 가능한 데이터로 만들기

1. 모든 MCP 세션에서 모델이 보낸 프롬프트를 기록했다.
2. 영업팀을 비롯한 팀원들에게 Claude Code 세션을 export해 달라고 요청했다.
3. 사람이 언제 에이전트를 override했는지, 모델의 confidence가 언제 낮아졌는지, 에이전트가 언제 질문했는지를 확인했다.
4. instrumentation의 정보는 MCP의 장기 가이드로 흘러 들어갔다. 시스템은 사람이 매번 손으로 다시 쓰지 않아도 파이프라인을 더 잘 만들게 됐다.

6.2. 조직·사용자별 자기 개선

1. 파이프라인을 더 많이 만들수록 그 경험이 다시 시스템의 가이드가 됐다.
2. 이 self-improving loop는 조직별 또는 파이프라인을 만드는 사용자별로 작동했다.
3. 모델 자체는 매우 guided하고 inspectable한 상태로 유지했고, 모델 주변의 정보가 실제로 다음 행동을 이끄는 모든 것이 됐다.

7. 영업팀이 자발적으로 채택한 결과

7.1. 지시가 아니라 업무 흐름 속 노출

1. Abhi는 영업팀에게 에이전트로 파이프라인을 만들라고 명시적으로 지시하지 않았다. Reducto의 Cloud Enterprise 안에 에이전트를 노출했을 뿐이다.
2. 영업팀과 다른 팀원들은 고객 통화 전에 CircleBack이나 Slack으로 고객을 학습했다.
3. 그다음 MCP에 고객에 관해 질문하고 해당 고객을 위한 파이프라인을 downstream에서 만들었다.

7.2. 신뢰가 실제 영업 결과로 이어짐

1. 에이전트 경험이 실제 사용자를 위해 설계되자 사람들을 직접 몰지 않아도 사용자들이 스스로 에이전트를 찾았다.
2. 사용자들은 에이전트를 회사 전체의 자원으로 사용하기 시작했고, 높은 가치의 고객 앞에서도 출력을 보여 줄 만큼 신뢰했다.
3. 단순히 데모가 작동한 것이 아니라 사람이 “제가 만들었습니다. 한번 확인해 보세요”라고 말할 수 있게 됐고 실제 영업 통화에서 성과로 이어졌다.
4. 발표자는 현장의 Slack 반응도 이런 변화를 보여 주는 신호라고 덧붙였다.

8. 결론: Agent-first는 에이전트를 먼저 두는 일이 아니다

8.1. 모델 우선이라는 초기 정의의 폐기

1. 몇 달 전에는 최고의 모델, inference speed, 모델 지능을 갖추는 것이 Agent-first라고 말했을 것이다.
2. 모델이 closed source에서 open source로, 비싼 모델에서 싼 모델로 좋아지고 있는 지금 Agent-first는 처음 들리는 의미와 거의 반대가 된다.
3. 에이전트는 혼자 먼저 나가는 존재가 아니라 downstream 작업에 책임질 사람들과 loop 안에 있어야 한다.

8.2. 연결 개수보다 중요한 질문

1. 오늘날 모든 에이전트가 모든 것에 연결되고 Claude는 즉시 새 connector를 만들어 줄 수 있으므로, “무엇에 연결되는가?”만 묻는 것은 부족하다.
2. 에이전트가 정말 자신 있게 틀렸을 때 누가 알아차리는가?
3. 그 사람이 얼마나 빨리 알아차리는가?
4. 이 두 질문에 답하도록 설계해야 사람이 실제 업무를 맡길 수 있는 시스템이 된다.

8.3. 발표 마무리

1. Abhi는 Reducto가 행사장 P8 부스에 있고 여러 직무에서 채용 중이라고 알렸다.
2. 관심 있는 사람은 reductoai.careers에서 확인해 달라고 안내했다.
3. 마지막 인사 뒤 16분 36초부터 음악이 흐르며 영상이 끝난다.

주요 발언 모음

“Agent first software is inherently an architecture problem.”

“Who pays for the agent being wrong?”

“By moving context out of the prompt and into structure, the agent stopped guessing and started referencing.”

“To avoid auto mode, you don't hand your agent an API, you hand it tools that carry the overall expertise: the right patterns, the state, and the validators.”

“We rewarded asking instead of guessing.”

“Agents are just intelligence in a box. The harness that you surround them with is what provides them with the ability to deliver these outcomes downstream.”

“The agent doesn't go first.”

“When your agent is really confidently wrong, who finds out and how fast did they find out? If you build for that, then you can build for something that people will actually trust with real work.”

핵심 데이터 & 수치

• 3년: Reducto가 제품과 모델을 반복 개선해 온 기간이다.
• 30억 개 초과: 주요 고객을 통해 처리한 문서 수다.
• 약 60%: 깨끗한 문서와 프런티어 모델을 클라우드에 올리는 것만으로 도달할 수 있는 대략적인 지점이다.
• 100개 문서: 에이전트 파이프라인이 처리하고도 오류를 놓칠 수 있는 예시의 규모다.
• 30페이지: 100개 문서 처리 중 스캔을 놓칠 수 있는 구체적인 사례다.
• 16분 39초: 영상 전체 길이다.
• P8: Reducto의 행사장 부스 번호다.

결론 및 시사점

1. Agent-first 제품의 첫 질문은 모델 성능이 아니라 에이전트의 오류 비용을 누가 부담하는지여야 한다.
2. API 엔드포인트를 그대로 MCP 도구로 노출하면 모델이 업무 구조를 추측해야 하므로 도메인 규칙과 올바른 연결을 도구에 넣어야 한다.
3. 도구 수를 늘리기보다 'classify to extract'처럼 검증된 업무 전이를 하나의 구조화된 도구로 만드는 편이 안전하다.
4. stateless agent에는 snapshot처럼 파이프라인, flow, 오류 코드가 포함된 살아 있는 상태를 명시적으로 제공해야 한다.
5. 프롬프트 안에 모든 문맥을 집어넣기보다 문맥, 상태, 검증기를 구조로 옮겨 추측 공간을 줄여야 한다.
6. confidence score, bounding box, 실패 원인을 반환해 낮은 확신을 다음 판단을 위한 문맥으로 바꿔야 한다.
7. 애매한 입력에서 추측하는 에이전트보다 애매한 부분을 설명하고 질문하는 에이전트가 실제 업무에 적합하다.
8. 사람이 검증할 수 없는 자율성과 접근 권한은 모델이 더 똑똑해져도 신뢰 문제를 해결하지 못한다.
9. 모든 MCP 세션의 프롬프트, 사람의 override, 낮은 confidence, 질문을 계측하면 자기 개선 루프를 만들 수 있다.
10. 사용자를 에이전트로 억지로 이동시키지 않고 올바른 업무 경로를 쉽게 만들면 비개발 사용자도 자발적으로 채택한다.
11. 정확성이 필요한 문서 파싱·추출은 Reducto 같은 계층에 맡기고 에이전트는 검증 가능한 구성과 판단 보조를 맡겨야 한다.
12. Agent-first는 에이전트를 인간보다 앞세우는 일이 아니라 에이전트를 책임질 사람과 함께 검증 가능한 루프에 두는 일이다.

핵심 요약 (20줄)

1. Reducto는 지난 3년 동안 주요 고객의 문서 30억 개 이상을 처리했다.
2. 깨끗한 문서보다 스캔 문서와 회전 페이지가 섞인 production 데이터 처리가 어렵다.
3. Agent-first software의 본질은 최고 모델이 아니라 에이전트 오류의 비용을 누가 치르는지 설계하는 일이다.
4. Auto mode는 자율성을 높이지만 자신 있게 틀리는 작업을 발견하기 어렵게 만든다.
5. User-first 방식은 사용자의 조절기를 늘리지만 에이전트를 제한된 챗봇으로 만들 수 있다.
6. 사용자를 위해 구조화된 능력을 제공하는 Agent experience가 자율성과 인간 검증을 함께 달성한다.
7. Reducto의 첫 MCP는 모든 API 엔드포인트를 도구로 노출한 거대한 단일 파일이었다.
8. 큐레이션된 독립 데모는 성공했지만 실제 팀 입력이 들어오자 당일 실패했다.
9. 에이전트는 전체 워크플로를 만들었지만 사용자와 에이전트 모두 결과를 설명하지 못했다.
10. Abhi는 시스템 프롬프트를 늘리는 대신 MCP 파일 전체를 한 번의 커밋으로 삭제했다.
11. 새 MCP는 도구 수를 줄이고 Reducto의 실제 업무 구조를 도구 안에 담았다.
12. 'classify to extract' 도구는 모델이 분류와 추출의 연결을 추측하지 못하게 한다.
13. snapshot 도구는 파이프라인의 live state와 구체적인 오류 코드를 반환한다.
14. 구조화된 문맥은 에이전트를 guessing에서 실제 상태 referencing으로 바꾼다.
15. Reducto는 confidence score와 bounding box를 모델에 되돌려 추출 schema를 개선했다.
16. 에이전트가 애매한 필드나 문서 유형을 만나면 추측하지 말고 사용자에게 물어야 한다.
17. 세션과 사람의 override를 계측하면 조직·사용자별 자기 개선 루프가 만들어진다.
18. 영업팀은 지시를 받지 않았지만 고객 통화 전에 MCP를 사용해 자발적으로 채택했다.
19. 에이전트가 자신 있게 틀렸을 때 누가 얼마나 빨리 알아차리는지가 업무 신뢰도의 핵심이다.
20. Agent-first는 에이전트를 책임질 사람과 함께 검증 가능한 루프에 두는 일이다.