ProdOps.AI

세 가지 부품으로 대부분 해결된다. Skill은 모델, 도구, 데이터 소스를 붙인 프롬프트이고, Skills끼리는 정해진 순서로 또는 모델이 필요하다고 판단할 때 서로를 부른다. Agent는 페르소나, 기억, Skills, 도구를 설정한 채팅이다. Workflow는 단계 사이의 입력과 출력을 명시한 여러 단계 파이프라인으로, 매번 똑같이 돌아야 하는 업무에 맞는다. 단계마다 다른 모델을 쓸 수 있어 긴 분석과 짧은 분류가 같은 청구서에 섞이지 않는다. 이 구조가 운영팀용 AI 에이전트를 일반 채팅 구독과 갈라 놓는다.

문서를 올리고 Google Drive와 SharePoint를 동기화하며 웹 페이지도 끌어온다. 계정의 모든 Agent가 그 문서고를 검색한다. 운영 현장에서 중요한 것은 인용이다. 답변마다 숫자가 나온 파일이나 기록을 가리킨다. 보고서 금액이 의심스러울 때 확인은 몇 초면 끝난다.

연결된 서비스에서 기록을 만들거나 고치거나 지우기 전에 Agent는 멈춰서 묻는다. 한 번만 승인하거나, 이후 그 동작을 허용하거나, 거절하면 된다. 읽기만 하는 동작은 끊김 없이 돌고, 모든 동작은 기록에 남는다. 그래서 복제본이 아니라 실제 ERP에 Agent를 겨눌 수 있다.

Claude, Cursor, 사내 앱이 MCP로 Agent와 Skill을 호출한다. 기능을 한 번 만들면 어느 클라이언트에서든 닿는다. 반대 방향도 된다. Agent가 외부 MCP 서버를 부르며, GitHub가 가장 분명한 예로 issue를 읽고 코드를 검색하고 검토용 pull request를 연다.

Workspaces는 Agent에게 파일을 읽고 쓰고 코드를 실행하고 스프레드시트를 다루는 공간을 준다. 각 샌드박스는 운영 시스템과 떨어져 있어 계산이 끝나지 않은 숫자가 실제 장부에 닿지 않는다. 목록에서 가장 눈에 안 띄는 기능이고, 아마 보안 담당자가 가장 먼저 묻는 항목이다.

Skill과 Agent가 각자 모델을 고르므로 비싼 추론이 값싼 작업에 섞이지 않는다. 플랫폼 자체는 Elixir로 작성해 오래 걸리는 작업을 동시에 많이 감당한다. 개발 쪽에서는 Bearer 키를 붙여 chats 엔드포인트로 POST하면 지정한 Agent와 대화가 시작되고, 요청 한도는 요금제마다 단계가 나뉜다.