주문 관련 질문을 받기 전에, 지금까지 고객에게 어떤 내용을 전달했는지 확인하고 싶습니다. 이미 고객이 보낸 것을 다시 물어보고 싶지는 않습니다. 제 앞에 있는 메시지가 답변을 얻기 위한 두 번째 또는 세 번째 시도일 수 있습니다. 어시스턴트가 내용을 읽어주는 것도 원합니다.
저는 DobroDesk에서 근무하는데, 이곳에서는 AI 클라이언트가 MCP(Model Context Protocol)를 사용하여 지원 도구를 호출할 수 있습니다. 이 클라이언트를 작업 공간에 연결하여 다음과 같이 요청할 수 있습니다: "주문 8142에 대한 열린 대화를 찾고, 메시지를 읽어주고, 인계받을 사람을 제안해줘." 이 예시를 위해 임의로 주문 번호를 만들었습니다.
최신 메시지가 "새 소식 있나요?"라고 할 수 있습니다. 이를 이해하려면 더 이전으로 거슬러 올라가야 합니다. 타임라인은 오래된 메시지들이 최근 반환되는 창 밖에 존재할 수 있다는 점을 표시할 수 있습니다. 또한 내용이 축약된 텍스트도 표시합니다. ID를 통해 개별 메시지의 내용을 더 많이 가져올 수 있습니다.
주문 번호는 올바른 대화를 찾는 데 도움이 될 것입니다. 저는 search_conversations를 사용하여 주문 받은 편지함(Orders Inbox)의 열린 대화들을 살펴볼 것입니다. 검색은 메타데이터만 제공하므로, 이것만으로는 아직 어시스턴트가 고객이 말한 내용을 읽어주는 것은 아닙니다. 원하는 메시지의 ID가 이미 있더라도, 메시지를 읽는 기능은 별도로 허용해야 합니다.
마음에 두고 있는 동료가 있을 수 있지만, 여전히 list_assignment_targets가 반환하는 선택지들을 확인할 것입니다. 여기에는 현재 받은 편지함에서 이 대화를 받을 수 있는 사람들이 포함됩니다. 마음에 둔 사람을 찾기 위해 다음 페이지가 필요할 수도 있으므로, 해당 결과의 커서(cursor)를 사용할 것입니다. 저는 그곳에서의 가용성과 처리 용량을 비교할 수 있습니다. 하지만 그들이 레나(Lena)가 이전에 주문을 처리했는지 여부는 알려주지 않습니다. 그것은 제가 직접 확인해야 할 부분입니다.
이 모든 것이 기록되기 전에, 저는 대화 내용과 누구에게 인계하는지를 확인할 것입니다. 이 예시에서는 레나가 담당자입니다. 이 제안된 클라이언트 흐름에서 어시스턴트는 assign_conversation을 호출하기 전에 저의 확인을 기다려야 합니다.
작업이 할당된 후 응답을 잃어버릴 수 있습니다. 원래 요청과 그 idempotencyKey를 유지할 것입니다. 그것이 제가 다시 보낼 요청입니다. 시간 초과(timeout)가 발생했다고 해서 새로운 키를 만들고 다른 작업을 시작할 이유는 되지 않습니다. 첫 번째 요청이 완료되어 저장된 결과가 남아 있다면, 저는 그 결과를 돌려받습니다. 그렇지 않다면, 아직 Lena에게 인계가 완료되었다고 말할 수 없습니다.
저는 비서(assistant)를 회사 전체가 아닌 한 팀원으로서 연결할 것입니다. 비서는 해당 팀원의 역할과 OAuth 권한 부여(grant)가 허용하는 것만 할 수 있습니다. DobroDesk는 또한 소유자(owner)가 멤버, 애플리케이션, 그리고 해당 멤버의 애플리케이션 사용을 제한할 수 있도록 합니다. 이 모든 것이 해당 작업을 허용해야 합니다. 팀원은 비서를 연결한다고 해서 새로운 브랜드나 받은 편지함(Inbox)을 얻게 되는 것은 아닙니다.
저는 고객 세부 정보(customer details)와 내부 메모(internal notes)는 이 작업에서 제외할 것입니다. 각각을 개별적으로 읽을 수 있는 권한을 부여해야 합니다. 비서가 이 대화의 메시지를 읽게 하기 위해서 두 가지 모두를 허용할 필요는 없습니다. 도브로데스크(DobroDesk)는 비서가 도구(tool)를 호출할 때마다 해당 팀원과 애플리케이션이 무엇을 할 수 있도록 허용되었는지 확인합니다.
만약 이 팀원의 애플리케이션 접근을 취소(revoke)하면, 현재의 권한 부여는 작동을 멈춥니다. 하지만 정책이 여전히 허용한다면, 나중에 다시 연결할 수도 있습니다. 또한 이를 방지하기 위해, 저는 동일한 팀원과 애플리케이션에 대한 재연결(reconnect)을 차단할 것입니다. 이것 하나를 처리하기 위해 다른 모든 사람의 연결을 차단할 필요는 없습니다.
저는 접근을 차단하기 위해 재연결 스위치(reconnect switch)만을 사용하지 않을 것입니다. 이미 존재하는 권한 부여는 여전히 작동할 수 있습니다. 따라서 이 팀원과 애플리케이션에 대한 해당 권한 부여도 취소할 것입니다. 나중에 다시 연결하도록 허용한다면, 그들은 다시 동의(consent)를 해야 합니다. 그때도 정책이 이를 허용해야 합니다.
여기에는 AI가 작성 및 수정에 도움을 주었습니다. 이 주문과 동료들은 가상의 것이며, 이것은 제안된 워크플로우입니다.