중앙 제어 없이 여러 사업부에 에이전트를 배포합니다.

대규모 조직 전체에 에이전트를 배포하는 데는 두 가지 표준 접근 방식이 있으며 둘 다 처음부터 눈에 띄는 방식으로 실패합니다.

중앙팀

한 그룹이 모든 에이전트 개발을 소유합니다. 거버넌스는 훌륭하고 표준은 일관적이며 4개월 이내에 대기열이 됩니다.

업무를 가장 잘 이해하는 팀이 사업부인데, 지금은 요청을 접수하고 기다리고 있습니다. 요청의 우선순위가 지정되고, 번역에서 컨텍스트가 손실되며, 가장 관심이 있는 비즈니스 단위는 어쨌든 중앙 팀이 제공하기 위해 존재하는 거버넌스 외부에서 자체 구축을 시작합니다.

실패는 무능력이 아니다. 중앙 팀이 12개의 서로 다른 도메인에 대한 도메인 지식을 보유할 수 없다는 것입니다.

모두를 위한 자유

모든 유닛은 원하는 것을 구축합니다. 채택이 빠르고 열정이 높으며 실행 중인 내용에 대해 누구도 대답할 수 없습니다.

6개월이 되면 소유자가 없는 상담원이 생기고, 동일한 문제를 세 번이나 해결하는 부서 간 중복된 작업, 구성 파일의 자격 증명, 아무도 귀속할 수 없는 비용 라인이 생깁니다. 첫 번째 심각한 사건은 모든 것을 중단시키는 반응을 낳습니다.

실제로 작동하는 것

레일을 소유한 플랫폼 팀과 에이전트를 소유한 사업부입니다.

플랫폼 팀은 ID 및 자격 증명 처리, 작업 시점의 정책 시행, 감사 추적, 비용 귀속, 평가 하네스 및 공유 카탈로그 등 일관되어야 하는 사항을 담당합니다.

사업부는 도메인 지식이 필요한 사항, 즉 자동화 대상, 좋은 결과, 각 에이전트의 소유자, 여전히 실행할 가치가 있는지 여부를 담당합니다.

경계는 유용한 부분입니다. 단위는 선택 사항이 아닌 플랫폼의 속성이기 때문에 속성 또는 감사를 선택 해제할 수 없습니다. 건물은 제한된 자원이 아니기 때문에 유닛은 무언가를 만들기 위해 허가를 요청할 필요가 없습니다.

카탈로그는 복제를 막는 것입니다

같은 문제를 3개의 유닛이 따로 해결하는 것은 대규모 롤아웃에서 가장 흔한 낭비이며, 공유된 공간이 없으면 전혀 눈에 띄지 않습니다.

에이전트를 찾아보고, 분기하고, 게시하고, 롤백할 수 있는 내부 카탈로그는 중복된 노력을 재사용으로 전환합니다. 두 번째 단위는 첫 번째 단위의 작업에서 시작해 이를 개선하고, 그 개선은 다시 흘러간다.

이것이 에이전트 허브의 목적이며 롤아웃에서 가장 자주 연기되고 가장 자주 후회되는 부분입니다.

예산은 단위에 속합니다.

중앙 예산 관리는 재정 형태의 대기열을 다시 생성합니다. 경고보다는 차단하는 단위당 예산은 제한된 노출 내에서 각 단위에 실제 자율성을 부여하고 거래를 판단할 수 있는 가장 좋은 위치에 있는 사람들에게 거래를 표시합니다.

가장 먼저 설치해야 할 것은

롤아웃 중이 아닌 롤아웃 전의 에이전트당 소유권입니다. 그 밖의 모든 것은 노력을 통해 개선할 수 있습니다. 아무도 기억하지 못하는 200명의 에이전트에 걸쳐 소유권을 개조한 것은 이 목록에서 최악의 프로젝트입니다.

다음

에이전트 허브 페이지에서는 공유 카탈로그, 포크 및 버전 관리를 다룹니다. 에이전트 오케스트레이션 시스템 페이지에서는 플랫폼 팀이 소유한 레일인 속성, 정책 및 예산을 다룹니다.