에이전트가 많은 회사인간 10명과 요원 약 80명7분 읽기

필드노트와 81번째 노동자

Amara는 눈에 보이지 않는 81번째 직원으로, 매일 아침 실패를 반복하고 성공적인 실행 내에서 오래된 컨텍스트를 숨기는 에이전트를 조정하는 데 시간을 보냅니다.

복합적인 미래 시나리오 · 현재 고객의 주장이나 MVP 설명이 아님

Amara는 중복되는 상담사 워크플로, 중복 작업, 잘못된 형식의 API 응답으로 둘러싸여 있습니다.
80명의 에이전트가 81번째 작업을 생성합니다. 즉, 개인 운영 지침을 일관성 있게 유지하는 것입니다.

Fieldnote에는 10명의 직원과 약 80명의 전문 에이전트가 있었습니다. 일부는 매시간 실행되고 일부는 일주일에 한 번 실행되며 일부는 사람이 작업을 승인한 후에만 실행됩니다. 그들은 피드백을 수집하고, 시장을 조사하고, 통합을 유지하고, 릴리스를 테스트하고, 도움말 콘텐츠 초안을 작성하고, 운영 권장 사항을 준비했습니다.

여든일곱 번째 노동자는 다른 요원이 아니었다. Fieldnote의 운영 책임자인 Amara가 짊어진 보이지 않는 조정 부담이었습니다.

모든 요원은 어딘가에 지침이 있었습니다. 연구 요원은 프롬프트 파일을 가지고 있었습니다. 유지 관리 에이전트에는 코드에 재시도 논리가 있었습니다. 콘텐츠 에이전트는 작업 공간에서 브랜드 안내를 받았습니다. API가 변경되면 세 명의 에이전트가 동일한 오류를 개별적으로 발견할 수 있습니다. 제품이 정의를 변경하면 다운스트림 에이전트가 모두 이를 수신하지 못했습니다. Amara는 어떤 성공이 진부한 맥락을 숨기고 있는지 알 수 없었기 때문에 성공적인 실행 요약을 읽으면서 아침 시간을 보냈습니다.

Fieldnote의 onemind는 각 에이전트를 인간 소유자, 프로젝트 멤버십, 모델 및 어댑터 버전, 허용된 소스, 허용된 작업, 지출 한도, 일정 및 종료 제어 기능을 갖춘 인텔리전스로 취급했습니다. The Mind는 모든 에이전트에게 공유된 대화 메모리를 제공하지 않았습니다. 워크플로는 출처 및 승인 상태가 포함된 형식화된 아티팩트를 전달했습니다.

어느 월요일, 피드백 분석 에이전트는 고객이 통합 한도를 잘못 이해한 메시지 18개를 발견했습니다. 수집 에이전트는 동의, 민감도, 제품 영역 및 보존 메타데이터와 함께 각 메시지를 저장했습니다. 분석 에이전트는 식별되지 않은 텍스트와 허용된 피드백 분류를 받았습니다. 이는 교훈을 제시했습니다. 고객은 기록 기록이 동기화되기를 기대했지만 통합은 새 기록만 지원했습니다. 제안에는 증거, 신뢰도, 두 가지 반례가 포함되었습니다.

자동으로 변경된 사항은 없습니다. 제품 소유자는 증거를 검토하고 교훈을 하나의 통합으로 좁힌 후 이를 수락했습니다. onemind의 종속성 미리 보기에서는 도움말 문서, 온보딩 사본, 지원 문제 해결 분기 및 제품 백로그 항목이라는 네 가지 다운스트림 변경 사항을 제안했습니다. 각각의 주인이 달랐습니다.

문서화 에이전트는 승인된 작업 패키지를 받았고 초안을 자동으로 업데이트할 수 있었습니다. 콘텐츠 패키지에는 승인된 제품 사실, 청중, 브랜드 규칙, 소스 참조 및 기록 동기화가 계획된 주장 금지가 포함되어 있습니다. 지원 담당자가 문제 해결 설명을 받았습니다. 제품 기획 에이전트는 백로그 제안을 받았지만 제품 승인 없이 이를 약정 로드맵에 추가할 수 없었습니다.

그날 오후, 유지 관리 담당자는 파트너 API에서 알려진 429 오류를 발견했습니다. onemind 패키지에는 지수 백오프, 최대 3회 재시도, 5달러 실행 예산, 에스컬레이션 규칙 등 테스트된 복구 워크플로가 포함되어 있습니다. 런타임 후크는 각 재시도 전에 이러한 제한을 평가했습니다.

Amara와 통합 소유자는 일상적인 상담원 작업이 한도 내에서 계속되는 동안 의미 있는 예외 하나를 해결합니다.
인간은 모든 일반적인 성공이 아니라 예외와 이에 필요한 결정을 검토합니다.

처음 두 번의 재시도는 실패했습니다. 세 번째에서는 파트너가 잘못된 성공 응답을 반환했습니다. 에이전트가 계속하려고 시도했지만 후크가 필수 필드가 없음을 인식했습니다. 워크플로를 중지하고 현재 상태를 보존하며 패키지 버전, 입력 아티팩트, API 응답, 비용, 재시도 기록 및 관련 실패한 접근 항목이 포함된 예외를 열었습니다. 에이전트는 재시도 횟수를 늘리거나 자체적으로 더 광범위한 API 액세스를 요청할 수 없습니다.

Amara는 3번의 실행 실패와 40번의 성공 메시지가 아닌 심각도가 높은 예외를 1번 확인했습니다. 그녀는 이를 통합 소유자에게 할당했습니다. 두 명의 에이전트가 동일한 기형 응답을 발견했을 때 onemind는 이를 기존 사고로 중복 제거하고 영향을 받는 수를 늘렸습니다. 통합 소유자가 복구 파서를 업데이트하고 테스트를 추가했습니다. onemind는 유지 관리 패키지를 다시 빌드하고 멱등성이 실패한 단계만 재생했습니다.

일주일 후, 구성 오류 이후 다른 운영 에이전트가 중복 CRM 작업을 생성하기 시작했습니다. Amara는 프로젝트 수준 킬 스위치를 사용했습니다. 실행 가능한 작업 작업이 중지되었지만 읽기 전용 마인드 액세스 및 감사 데이터는 계속 사용할 수 있습니다. 팀에서는 구성을 수정하고, 기록된 입력에 대해 워크플로를 시뮬레이션하고, 작업을 점진적으로 복원했습니다.

두 달이 지나면 Fieldnote는 더 이상 사람이 거의 모든 일상적인 실행을 읽도록 요구하지 않습니다. 인간은 모든 결과적 예외와 위험 기반 성공 샘플을 검토했습니다. 심각도가 높은 누락된 예외는 측정 기간 동안 0으로 유지되었습니다. 또한 회사는 이전보다 원격 측정 및 아티팩트 저장에 더 많은 비용을 지출했으며 Amara는 매주 시끄러운 규칙을 조정해야 했습니다.

에이전트는 자체 관리 회사가 되지 않았습니다. 제품 결정, 돈, 고객 약속 및 정책은 여전히 ​​명명된 인간의 소유였습니다. onemind는 위임을 읽기 쉽게 만들었습니다. 모든 상담원은 회사 업무 방식의 관련 부분을 알고 있었고, 모든 결과적인 조치는 제한되었으며, 모든 예외는 사람이 다음에 무슨 일이 일어날지 결정할 수 있을 만큼 충분한 기록과 함께 도착했습니다.