배경 및 맥락
Enterprise agent의 병목은 대화 품질이 아니라 운영 통제다. 고객 지원·보험 청구·사내 IT처럼 실제 데이터를 조회하고 조치를 취하는 흐름에서는 agent가 무엇을 할 수 있는지, 언제 사람에게 넘길지, 정책이 바뀌었을 때 어떻게 검증할지가 모델 선택만큼 중요하다. 단일 prompt나 tool wrapper만으로는 production의 감사·회귀 검증·권한 분리를 지속하기 어렵다.
핵심 내용
OpenAI Presence는 voice와 chat agent를 위한 배포형 Enterprise 제품이다. 고객사는 작업별로 필요한 지식과 시스템 접근만 부여하고, 수행 가능 조치·승인 조건·인간 전환 규칙을 정책으로 설정한다. 출시 전에는 일반 요청·edge case·고위험 시나리오를 simulation과 grader로 시험해 outcome, policy 준수, tool 사용, escalation을 확인한다. 운영 후에는 세션·escalation·품질 신호를 바탕으로 Codex가 변경안을 제안하고, 팀이 production 버전과 비교 평가한 뒤 통제된 rollout을 승인한다. OpenAI는 자사 영어 전화 지원에서 inbound issue의 75%를 human handoff 없이 해결했고, 개선 루프가 10일 동안 handoff를 15 percentage point 낮췄다고 설명한다. 제공 방식은 eligible Enterprise 고객 대상의 limited GA이며 FDE와 일부 시스템 통합 파트너가 배포를 주도한다.
경쟁 구도 / 비교
일반 agent SDK가 모델 호출·tool use·streaming을 쉽게 만드는 데 초점을 둔다면, Presence의 차별점은 업무별 policy, approval, evaluation, 운영 데이터 기반 개선을 하나의 control plane으로 묶는 데 있다. Vercel AI SDK 7·Connect·eve가 개발자가 agent runtime을 조합하도록 돕는 실행 스택이라면, Presence는 특정 Enterprise workflow를 공동 배포·운영하는 managed product에 가깝다. 그만큼 초기 구축 부담은 줄일 수 있으나, self-service가 아니고 OpenAI 및 SI 운영 방식과의 결합도는 반드시 평가해야 한다.
의미
Enterprise agent의 성숙도는 ‘답을 잘한다’가 아니라 ‘정책을 지키며 승인된 행동을 재현 가능하게 수행한다’로 측정해야 한다. 팀은 workflow별 allowed action, credential scope, human takeover SLA, evaluation dataset, prompt·policy 변경의 regression gate, 감사 로그 보존 기간을 architecture review의 필수 항목으로 삼아야 한다. 이후 모델이 바뀌어도 이 control loop가 유지돼야 agent가 데모를 넘어 운영 자산이 된다.