에이전틱 보조자: 안전한 캘린더 및 Gmail 통합

내 주장은 캘린더, Gmail 및 연결된 앱에서 작동하는 안전하고 사용 가능한 에이전틱 보조자를 구축하려면 허가 우선 런타임을 설계하고, 계획을 행동에서 분리하며, 실행 레이어에 감사 및 복원 플로우를 첫날부터 통합해야 한다는 것이다. 이 기사에서는 이를 위한 명확한 엔지니어링 체크리스트와 실행 가능한 프롬프트를 제공한다.

에이전틱 보조자를 위한 허가 설계

사용자별 OAuth와 최소 권한 스코프에서 시작하라. 관리자가 명시적으로 도메인 위임을 요구하지 않는 한, 공유 서비스 계정보다 사용자 바인드 OAuth를 사용하라. Google의 세분화된 스코프에 대한 문서는 기본이다. 모든 에이전트 기능을 단일 OAuth 스코프에 매핑하고 해당 스코프에 대한 인간이 읽을 수 있는 의도를 문서화하라. 프롬프트에서 토큰을 제외하라. Vault에 저장하고 정책을 시행하는 실행 서비스 내에서 호출 시점에만 자격 증명을 삽입하라.

우리는 권한을 제품 UX로 취급하고 명확한 동의 화면 및 스코프 미리 보기를 제공하는 팀이 지원 요청을 훨씬 적게 받는다는 것을 관찰했다. 우리가 마주친 한 가지 문제는 순진한 새로 고침 로직에서 발생한 토큰 증식이다. 새로 고침을 중앙 집중화하고 새로 고침 토큰을 정기적으로 교체하라.

계획 대 행동

보조자를 계획자와 실행기로 분리하라. 계획자는 구별된 행동 계획을 생산한다: 최근 스레드를 읽고 두 개의 회의 시간을 제안하며 초안 이메일을 작성한다. 실행기는 정책 검사를 수행한 후 그리고 민감한 작업의 경우 사람의 확인 단계를 거쳐서만 실행된다. 이 패턴은 모델이 특권 작업을 즉흥적으로 수행하지 못하게 하고, 권한 부여를 감사 가능하게 만든다.

실용적인 거래: 사람의 승인을 위한 긴 대기 시간 대 낮은 위험. 많은 캘린더 및 이메일 작업에 대해 30~60초의 사람 개입 대기 시간이 허용된다. 높은 빈도의 작업에 대해서는 작업당 클릭보다 일괄 승인이 더 효과적이다.

테스트, 로그 및 복구

모든 작업은 요청된 의도, 계획자 출력, 정책 결정, 실행자 호출 및 반환된 API 응답을 포함하는 불변 감사 항목을 생성해야 한다. 재생 가능한 명령 형식을 유지하여 재생하고 롤백할 수 있도록 하라. 마지막 N 작업에 대해 원클릭 철회 기능과 행사 취소 및 수정 후속 조치를 생성하는 복구 플로우를 제공하라.

우리는 프롬프트 수준의 가드레일이 외부 정책 엔진 없이는 실패한다는 것을 관찰했다. 실제로 모델은 그럴듯하게 보이지만 정책을 위반하는 변경 사항을 제안할 것이다. 신뢰도가 보정된 임계값 이하일 때 모든 쓰기를 거부하는 실행 게이트는 이러한 사건을 줄인다.

제품 및 엔지니어링 체크리스트

1. 최소 스코프와 명시적인 동의 텍스트가 포함된 사용자별 OAuth. 2. 런타임에서 자격 증명을 삽입하는 토큰 Vault 및 실행 서비스. 3. 정책 검사가 포함된 계획자/실행기 분리. 4. 민감한 작업에 대한 인간 개입 에스컬레이션. 5. 불변 감사 로그 및 재생 가능한 작업 형식. 6. 명확한 UI 제공 요소가 있는 복구 및 보상 플로우.

제품 UX를 인간-AI 워크플로 설계에서 설명한 워크플로 패턴에 연결하고 에이전트 차이에 대한 기초 정보를 AI 에이전트 대 챗봇에서 사용하여 계획자/실행자 분리를 정당화하라.

직접 시도해 보라. 아래 프롬프트는 계획자 출력과 안전한 실행 지침을 비교한다. 계획자에게는 간결한 JSON 형식의 계획이 예상되며, 실행자는 짧은 확인이 예상된다.

이 프롬프트는 모델이 후보 회의 시간의 제한된 계획과 논리를 생산하도록 요청한다. 계획자로 사용하라. 후보 슬롯은 2~3개와 각 슬롯에 대한 한 줄의 논리가 예상된다.

당신은 회의 계획자입니다. 사용자가 오늘 3개의 여유 시간을 가지고 있습니다: 오전 10시, 오후 2시 30분, 오후 4시. ISO 형식으로 정확히 세 개의 후보 회의 시간을 반환하고, 각 시간에 대한 한 줄의 논리와 초대가 외부 이메일에 연결되는지 여부에 대한 한 줄의 개인정보 보호 주석을 추가하시오.

이 프롬프트는 실행자를 위한 것이다. 이벤트를 생성하기 전에 인간 확인 토큰과 명시적인 정책 검사 통과를 기대한다.

실행기: 사용자 확인 토큰 X와 계획자 계획 Y가 주어지면, policy_check(policy_id:calendar_write)가 통과할 경우에만 {start,end,attendees,summary} 필드로 Calendar.CreateEvent를 호출한다. policy_check가 실패하면 실패 코드를 반환하고 인간의 조치가 필요하다고 알린다.

반박할 수 있는 주장은 엄격한 통제가 채택 속도를 늦춘다는 것이다. 내 추정은 이 팀들이 이러한 패턴을 시행할 때 신뢰가 성장함에 따라 초기 사용자 유지가 향상된다는 것이다. 초기 활성화가 느리더라도 말이다. 거래는 명확하다: 이러한 통제가 없는 더 빠른 출시가 측정 가능한 위험과 높은 수정 비용을 초래한다.