2026년 에이전틱 마케팅: 시스템이 반드시 노출해야 하는 네 가지

짧은 답변: 에이전틱 마케팅은 다음 단계를 스스로 선택한 뒤 실행하는 소프트웨어가 수행하는 마케팅 업무입니다. 대체로 합의는 여기서 끝납니다. 2026년 8월 18일 해당 용어와 변형어로 검색해 나온 11개 페이지를 가져왔는데, 그중 8개는 프로토콜, 도구 호출, 함수 호출을 전혀 언급하지 않았습니다. 바로 그 계층에서 에이전트는 채팅 창을 벗어나 커뮤니티, 캠페인, 고객 기록을 바꿀 수 있는 무언가가 됩니다. 그래서 이 글은 에이전트가 마케팅 업무를 수행하기 전에 시스템이 반드시 노출해야 하는 네 가지로 에이전틱 마케팅을 정의하고, 해당 시스템이 스스로에 대해 공개하는 라벨이 신뢰할 수 없는 이유를 Model Context Protocol에서 인용하며, Zealy 자체의 에이전트 표면을 이 정의에 비추어 평가합니다. 우리가 미흡한 부분도 포함해서요.

공개: Zealy가 이 페이지를 발행하며, Zealy는 이 글의 주제인 제품을 판매합니다. Zealy는 커뮤니티 및 퀘스트 플랫폼입니다. 이 글의 정의에 해당하는 에이전트 기능이 두 가지 있습니다. 외부 AI가 구동할 수 있는 MCP 서버와 제품 내 AI 리뷰어입니다. 세 가지 모두 아래에 나옵니다. Zealy 자체 에이전트 표면에 관한 모든 내용은 1차 자료입니다. Zealy 저장소에서 읽고, 우리가 Zealy 자체 서버에 대해 실행했으며, 다른 누구도 감사하지 않았습니다. 자사 제품을 설명하는 어떤 벤더에게든 적용할 회의적인 시각으로 읽으시기 바랍니다.

최종 확인: 2026년 8월 18일.

에이전틱 마케팅이란 무엇인가?

에이전틱 마케팅은 사람이 그린 워크플로를 따르는 대신 목표를 향해 스스로 다음 행동을 선택하는 소프트웨어가 수행하는 마케팅 업무입니다. 시스템은 네 가지를 노출할 때만 자격을 갖춥니다. 채팅 상자가 아닌 이름 있는 도구, 행동 전에 이를 발견할 방법, 의도적으로 정한 승인 경계, 그리고 반환되는 것에 대한 신뢰 경계입니다.

이 정의는 우리 것이며, 의도적으로 야망이 아니라 기계적 구조에서 출발해 만들어졌습니다. 우리가 읽은 모든 공개 정의는 소프트웨어가 무엇을 하려는지를 설명합니다. 그중 어느 것도 그것이 가능하려면 스택에 무엇이 참이어야 하는지를 설명하지 않습니다. 시스템이 충족해야 하는 순서대로 네 부분을 소개합니다.

1. 텍스트 상자가 아닌 이름 있는 도구. 에이전트에는 이름, 인수, 반환 형태를 가진 작업이 필요합니다. 예를 들어 create_campaign, list_members 및 send_message같은 것이요. 산문만 생성할 수 있는 모델은 산문만 생성할 수 있기 때문입니다. Model Context Protocol은 현재 이러한 목록을 공개하는 일반적인 방식이며, 그 도구들은 모델 제어라고 불립니다. 언어 모델이 컨텍스트와 사용자 프롬프트를 바탕으로 스스로 발견하고 호출합니다. 이 계층이 없으면 글쓰기 보조 도구일 뿐입니다. 유용한 제품이지만, 이 제품은 아닙니다.
2. 행동 전 발견. 에이전트는 무엇이 존재하고 각각 무엇을 하는지 물어본 뒤에야 무엇이든 시작할 수 있어야 합니다. 사람이 이미 세 가지 호출을 선택한 하드코딩된 통합은 카피에 모델을 붙인 자동화입니다.
3. 누군가 의도적으로 선택한 승인 경계. 모든 행동은 사람을 위해 멈추거나 멈추지 않으며, 어딘가에 어느 쪽인지 결정하는 규칙이 있습니다. 규칙은 엄격할 수도 느슨할 수도 있습니다. 검토되지 않은 것일 수는 없습니다.
4. 반환되는 것에 대한 신뢰 경계. 도구 결과는 다른 사람이 작성한 데이터입니다. 멤버, 고객, 양식, 스크랩한 페이지 등이요. 반환된 문자열이 에이전트를 설득해 다음 도구 호출을 하게 만들 수 있다면, 퀘스트 제출 필드를 채우는 누구에게서든 지시를 받는 시스템을 만든 것입니다.

두 가지 결과가 따르며, 이것이 우리가 굳이 정의를 쓴 이유입니다. 첫 번째 부분이 빠진 것은 더 나은 마케팅을 한 챗봇일 뿐입니다. 그리고 세 번째 부분이 빠진 것은 자율성에 대해 결정한 적이 없다는 뜻입니다. 그저 자율성이 일어난 것입니다. 선택하지 않은 승인 경계는 설계상의 입장이 아니라 아직 비용이 발생하지 않은 사고입니다.

존재하는 정의들, 그리고 각각이 자율성의 선을 긋는 지점

공개된 정의들은 에이전트가 스스로 계획하고 행동한다는 데 동의하며, 인간 개입이 얼마나 남아야 하는지에는 의견이 다릅니다. Vlerick Business School은 최소한의 개입을 허용합니다. Braze는 인지하고, 결정하고, 행동하는 시스템을 설명합니다. Young Urban Project와 Netcore는 둘 다 단계별 인간 승인에 선을 긋습니다. Forrester는 에이전트와 에이전틱 AI를 완전히 분리합니다.

오른쪽 열보다 가운데 열을 먼저 읽으세요. 누가 이 범주를 정의하는지가 그들이 선을 어디에 긋는지에 대해 많은 것을 알려줍니다.

오른쪽 열의 모든 문자열은 검색 결과에서 읽은 것이 아니라 2026년 8월 18일에 가져온 링크된 페이지의 원문 텍스트와 대조했습니다. 이 용어로 상위에 노출되는 페이지 중 여섯 개는 전혀 읽을 수 없었습니다. Salesforce, IBM, Gartner, BCG는 모든 시도에 403을 반환했고 McKinsey와 Adobe는 시간 초과되었습니다. 이 중 어느 것도 여기에서 인용되지 않았습니다.

세 페이지는 인접한 용어와의 유용한 경계도 제시하며, 이 세 개만이 보존할 가치가 있다고 판단한 것입니다.

마케팅 자동화와의 구분. Treasure Data는 "에이전틱 마케팅은 AI 마케팅보다 좁은 개념이며 마케팅 자동화와 구별된다"고 씁니다. 왜냐하면 "마케팅 자동화는 사람이 정의한 고정된 워크플로를 실행"하기 때문입니다. 기준은 소프트웨어가 사용자 없이 작동하는지가 아닙니다. 이메일 도구는 이미 그렇게 합니다. 기준은 단계의 순서가 사람에 의해 미리 선택되었는지입니다.

생성형 AI와의 구분. Optimove는 이를 두 가지 트리거의 대조로 설명합니다. "생성형 AI는 사람의 프롬프트에 따라 콘텐츠를 생성"하는 반면, "에이전틱 AI는 프롬프트를 기다리지 않고 자율적으로 행동합니다." 프롬프트형 대 목표형이라는 구분은 실제로 존재하지만 좀처럼 지켜지지 않는 구분입니다.

어시스턴트와의 구분. 세트에서 누군가 쓴 가장 날카로운 문장은 다음 사람의 것입니다: Docket의 Arjun Pillai: "어시스턴트는 사용자를 기다리고, 작업을 돕고, 인간의 워크플로 안에서 산다." 그 에이전트 절반은 "에이전트는 목표를 향해 행동하고, 제한된 결정을 내리고, 워크플로를 트리거하고, 감독 아래 실행의 일부를 소유한다." 같은 페이지의 별도 구절이 그 문구에 빠진 메커니즘을 제공한다: 인간은 "목표, 에스컬레이션 규칙, 주제 제약, 승인 임계값을 정의한다. 에이전트는 그 경계 안에서 작동한다. 무언가가 그 경계를 벗어나면 에스컬레이션한다." 에스컬레이션은 우리 정의의 승인 경계를 에이전트의 관점에서 설명한 것이다.

하나의 이견은 매끄럽게 넘기기보다 그대로 인쇄할 가치가 있다. Forrester는 AI 에이전트 사용 사례에 관한 페이지에서 Craig Le Clair가 이름을 올린 페이지에서, 위의 모든 벤더 페이지가 서로 바꿔 쓸 수 있는 것으로 취급하는 두 용어를 구분한다: AI 에이전트는 "사전 정의된 규칙"으로 작동하는 반면, "에이전틱 AI는 더 넓은 자율성과 적응성을 도입한다". 그 인용에 대한 정직한 경고 — 그것은 팟캐스트 랜딩 페이지이지 발행된 연구 노트가 아니며, 우리는 그것을 연구 결과가 아니라 한 분석 기업의 프레이밍으로 인용하고 있다.

열한 개 정의 중 여덟 개가 빠뜨린 계층

2026년 8월 18일에 이 용어를 위해 가져온 열한 개 페이지 중 여덟 개는 Model Context Protocol, 도구 호출 또는 함수 호출을 전혀 언급하지 않는다. 그 계층이 캠페인 브리프를 작성해 주는 모델과 퀘스트를 생성하고, 멤버를 차단하고, 이벤트 스트림을 새로운 곳으로 돌릴 수 있는 모델 사이의 차이다.

해당 문자열이 전혀 언급되지 않은 여덟 곳은 braze.com, cdp.com, docket.io, forrester.com, netcore.ai, tofuhq.com, vlerick.com, youngurbanproject.com입니다. 나머지 세 곳 중 hubspot.com은 Model Context Protocol을 언급하지만 정의를 다루는 페이지는 아닙니다. Optimove 이 우리 기억에 남았습니다: 문자열 MCP 은 해당 페이지의 탐색 메뉴에 "The Optimove MCP"로만 등장하며, 카테고리를 설명하는 본문에는 전혀 나오지 않습니다. MCP 서버를 출시한 벤더인데, 자사의 에이전틱 마케팅 해설은 자사가 출시한 그 제품에까지 이르지 못합니다. 이는 어느 하루의 열한 개 페이지에 대한 진술일 뿐 카테고리 전체에 대한 것은 아니지만, 우리가 확인한 모든 페이지에서 그러했습니다.

이 집합에서 두 페이지는 빠진 계층을 실제로 언급하며, 둘 다 잘 설명합니다.

HubSpot의 Duncan Lennox 는 이렇게 씁니다: "하지만 에이전트는 대시보드를 클릭하거나 인터페이스를 탐색하지 않습니다. API를 호출하고, 구조화된 출력을 읽고, 행동합니다." 같은 페이지는 범위를 "에이전트가 읽고, 쓰고, 행동할 수 있는 것"으로 규정하는데, 이것이 올바른 단위입니다. "마케팅을 할 수 있는가"가 아니라, 어떤 명사와 어떤 동사를 다루는가입니다.

마테크 리서치 기업인 Real Story Group은 벤더 평가를 판매하며, 이 논쟁을 끝내는 문장을 제시합니다. MCP에 관한 글 (2025년 6월 11일)에서 수석 애널리스트 Scott Simmons는 이를 "AI 에이전트를 위해 구축된 범용 API 추상화 계층"이라고 부르며, 에이전트는 "벤더가 공개하기로 선택한 것만큼만 강력하다"는 결론을 내립니다.

마지막 문장이 핵심입니다. 에이전트 마케팅은 선택한 모델의 속성이 아닙니다. 벤더가 공개하는 표면의 속성입니다. 도구가 읽기 전용이라면 에이전트는 보고만 합니다. 도구가 없다면 에이전트는 카피를 작성합니다. 역량 질문과 조달 질문은 같은 질문이며, 이 계층을 건너뛰는 정의가 읽기는 즐겁지만 실행하기는 어려운 이유입니다. 에이전트가 활동할 채널의 더 넓은 그림을 원하신다면, 저희 web3 마케팅 필러 가 해당 채널과 그 비용을 다룹니다.

도구 목록이 증거이고 도구 레이블은 단지 힌트인 이유

Model Context Protocol은 에이전트가 당신에게 무엇을 할 수 있는지에 대한 질문에 서버의 도구 목록을 읽으라고 답한 뒤, 클라이언트에게 그 목록이 스스로에 대해 말하는 내용을 신뢰하지 말라고 합니다. 그렇게 말하는 주석은 산문이 아니라 스키마에 있어서, 읽은 사람이 적은 이유 중 하나입니다.

다음은 발췌문입니다. 출처: ToolAnnotations 인터페이스, 위치: 명세의 스키마 (개정 2026-07-28):

참고: 다음의 모든 속성 ToolAnnotations 은(는) 힌트도구 동작(예: "와 같은 설명 속성 포함)에 대한 충실한 설명을 보장하지 않습니다. title).

그리고 같은 주제로, 도구 페이지:

신뢰 및 안전과 보안을 위해, 고객은 MUST 신뢰할 수 있는 서버에서 온 것이 아니라면 도구 주석을 신뢰하지 마세요.

잠시 그 형태를 곱씹어 보세요. "이것이 나에게 무엇을 할 수 있는지 어떻게 알 수 있나"에 대한 프로토콜의 답은 목록을 읽으라는 것입니다. 바로 다음 지침은 이렇습니다. 그 목록은 당신이 평가하는 주체가 한 주장입니다. 도구 이름 and schemas 는 핵심 요소입니다. 모델이 이를 호출하고 서버가 이를 준수해야 하기 때문입니다. 여기에 붙은 위험 레이블은 서버가 자신의 동작을 스스로 설명한 것입니다.

이러한 레이블은 네 가지입니다 — readOnlyHint, destructiveHint, idempotentHint 및 openWorldHint — 및 그중 두 개, destructiveHint and openWorldHint기본값: true. 레이블이 없는 도구는 따라서 파괴적인 것으로 간주되며 외부 세계에 영향을 미치는 것으로 간주됩니다. 이는 올바른 판단이며 대부분의 사람들이 기대하는 것과 정반대입니다.

에이전틱 마케팅의 정의에서 중요한 것은 destructiveHint, 왜냐하면 그것이 묻지 않는 것 때문입니다. 그것은 덮어쓰기와 추가를 구분합니다. 피해는 다른 축이며 스키마에는 그에 대한 열이 없으므로, 순수하게 추가적인 호출이 에이전트가 당신의 스택에 하는 가장 중대한 일이 될 수 있으면서도 완전히 선의로 행동하는 서버에 의해 안전한 방식으로 표시될 수 있습니다. 각 플래그가 실제로 의미하는 것과 기본값을 적용했을 때 실제 목록이 어떻게 보이는지는 옆집의 워크스루.

이것은 마케터들이 흔히 '에이전트 워싱'이라고 부르는 것의 정직한 버전이기도 합니다. Young Urban Project는 이를 정확히 지적합니다: "가장 흔한 실패는 에이전트 워싱으로, 기존 자동화나 챗봇 제품을 밑에 계획이나 의사결정 계층을 추가하지 않은 채 에이전트 기반으로 리브랜딩하는 것입니다", 그리고 덧붙입니다: "데모는 정작 중요한 격차를 감추도록 대본이 짜여 있습니다". 도구 목록은 데모보다 대본으로 꾸미기가 훨씬 어렵습니다. 또한 이 범주 전체에서 구매자가 공급업체의 협조 없이 확인할 수 있는 유일한 산출물이며, 그래서 우리는 별도의 워크스루를 작성했습니다: 연결하기 전에 모든 MCP 서버의 도구를 열거하는 방법.

승인 경계가 어디에 놓이며, 누가 그것을 놓아야 하는가

Model Context Protocol은 인간이 항상 루프 안에 있어 도구 호출을 거부할 수 있어야 한다고 말하며, 이를 MUST가 아닌 SHOULD로 클라이언트 애플리케이션에 전달합니다. 프로토콜 어디에도 연결하는 서버에 의무를 부과하지는 않습니다. 승인 경계가 어디에 위치하는지는 누군가가 내린 선택이며, 흔히 당신이 아닙니다.

정확한 문장은 다음과 같습니다:

신뢰·안전 및 보안을 위해, SHOULD 항상 인간이 루프 안에 있어 도구 호출을 거부할 수 있어야 합니다.

같은 보안 섹션은 클라이언트에게 "악의적이거나 우발적인 데이터 유출을 피하기 위해 서버를 호출하기 전에 사용자에게 도구 입력을 보여줄 것"과 "LLM에 전달하기 전에 도구 결과를 검증할 것"을 요청합니다. 둘 다 클라이언트, 즉 당신 쪽에서 실행되며 모델을 보유한 Claude나 ChatGPT 또는 사내 하네스를 대상으로 합니다. 따라서 프로토콜을 있는 그대로 읽으면, 에이전트 기반 마케팅의 안전은 클라이언트의 몫이며, 연결한 서버는 정직한 도구 목록 외에는 당신에게 아무것도 빚지지 않습니다.

이 분야는 이를 알고 있지만 어떻게 해야 할지 확신하지 못합니다. 벤더 가이드는 흔히 사람이 없음을 기준으로 에이전트를 정의한 뒤, 같은 페이지 아래쪽에서 사람을 어디에 다시 넣어야 하는지 알려줍니다. 우리는 그런 페이지 중 하나를 다음에서 해부합니다: AI 에이전트가 실제로 커뮤니티를 운영할 수 있을까두 부분 모두 진심입니다. 정의는 시장을 위해 쓰이고 지침은 배포를 위해 쓰이며, 그 사이의 간극에서 자율성에 관한 모든 실제 결정이 이루어집니다.

주장할 가치가 있는 버전은 "완전 자율성"도 "모든 것을 승인"도 아닙니다. 경계는 양쪽 모두에 비용이 따르는 결정별 설정이며, 이를 강제하는 메커니즘 자체가 실패할 수 있는 소프트웨어라는 점입니다. 올해 초 Discord 모더레이션 실패 사례가 이를 보여줬는데, 공개된 설계에는 인간 검토 단계가 있었지만 버그로 인해 그 경로에서 빠졌습니다. 우리는 이에 대해 에이전트가 커뮤니티를 운영하도록 하는 것이 무엇을 의미하는지 별도로 다루어야 합니다. 단순한 문구 이상의 의미가 있기 때문입니다.

이제 측정된 답도 존재합니다: 어떤 호출이 게이트를 받을 자격이 있는지에 대한 답이며, 그것은 직관이 알려주는 답이 아닙니다. SABER: 작은 행동, 큰 오류 — LLM 에이전트의 변경 단계 보호Alejandro Cuadron, Pengfei Yu, Yang Liu, Arpit Gupta가 작성하여 2025년 11월 26일에 제출한 이 연구는 도구를 사용하는 에이전트의 궤적이 잘못될 때 실제로 비용이 발생하는 경우를 다룹니다. 이 연구는 "반대로, 변경을 일으키지 않는 행동의 편차는 거의 또는 전혀 영향을 미치지 않는다"고 보고합니다. 바로 앞 문장은 그 반대 측면을 제시합니다: "의 추가 편차마다 변경 중 action은 최신 모델 기준으로 두 도메인 중 하나에서 성공 확률을 최대 92%, 다른 하나에서는 최대 96%까지 낮춥니다. 실패는 상태를 변경하는 호출에 집중됩니다.

설계 결론은 화려하지 않고 값싸다. 쓰기를 제한하고, 읽기는 그대로 두며, "인간 개입"을 단일 설정의 단일 다이얼로 취급하는 것을 멈추는 것이다. Zealy의 서버는 우연히 그렇게 동작하며, 우리가 이를 이 논문에서 도출하지 않았다는 점을 분명히 해야 한다. 논문은 설계 이후에 나왔고 설계에 동의한다. 이는 증거 주도 엔지니어링보다 약하고 아무것도 없는 것보다는 강하다. 인용에는 한 가지 주의가 따른다. SABER는 기반 벤치마크의 주석 오류를 문서화하고 수정본을 공개하므로, 오래된 도구 에이전트 벤치마크 점수를 현재 모델을 여전히 설명하는 것처럼 인용하지 말아야 할 좋은 이유가 된다. 여기서 단일 숫자를 조심해야 하는 또 다른 이유는 에이전트 실패가 대부분 분산 문제라는 점이다. 멀티턴 연구는 성능 저하를 역량의 경미한 손실과 신뢰성의 큰 상승으로 나눈다, 이는 모델이 단순히 충분히 좋지 않은 것과는 다른 관리 문제다.

같은 "구현자에게 맡김" 패턴이 우리 정의의 네 번째 부분인 한 계층 아래에서도 나타난다. 우리는 2026년 8월 18일에 명세 및 보안 페이지 일곱 개를 내려받아 검색했다. 명세의 위협 모델은 권한 부여 및 전송 위협 모델로, 혼동된 대리인, 토큰 패스스루, 서버 측 요청 위조, 침해된 로컬 서버 등을 포함하지만 모델 계층 공격은 구현자에게 맡긴다. 우리가 내려받은 페이지에서 "프롬프트 인젝션"이라는 문구는 나타나지 않는다. 보안 모범 사례 문서에서 "인젝션"의 네 가지 일치는 교차 사이트 스크립팅, 셸 명령 인젝션, 원격 코드 실행이다. 이는 범위를 스스로 정할 권리가 있는 전송 명세에 대한 불만이 아니다. 이는 무언가를 연결하는 순간 문제의 절반 중 어느 쪽을 물려받는지, 그리고 반환 데이터의 신뢰 경계가 프로토콜의 가정된 속성이 아니라 누군가의 명시적 업무여야 하는 이유에 대한 진술이다.

Zealy는 자체 정의에 실패하며, 바로 이 지점에서

이 글의 가장 엄격한 정의, 즉 Young Urban Project의 "각 개별 단계를 인간이 승인하지 않고"와 Netcore의 "매 단계마다 인간 승인을 요구하지 않고"에 따르면 Zealy는 에이전트 마케팅을 하지 않는다. Zealy의 에이전트 표면을 통한 모든 쓰기는 사람 앞에서 멈추며, 운영자가 켜기 전까지 쓰기는 꺼져 있다.

나중에 논쟁에서 지는 것보다는 그렇게 말하는 편이 낫다. 다음은 우리 자신의 네 부분에 대한 전체 점수표이며, 1차 자료이고 감사되지 않았다.

네 가지 모두 존재하며, 이는 쉬운 부분이다. 세 번째는 라벨에 맞게 반대 방향으로 설정되어 있다. Zealy의 서버는 승인 게이트를 서버 측에 두는데, 이는 프로토콜이 서버에 요구하는 것보다 많고 에이전트 마케팅의 엄격한 정의가 허용하는 것보다도 많다. 도구 표면 자체는 감사할 가치가 있을 만큼 크다 — 우리가 집계한 시점에 명명된 도구 72개 — 하지만 숫자가 핵심은 아니다. 설정이 핵심이다.

우리는 제품 전체에 걸쳐 일관성을 주장할 수도 없다. Zealy는 또한 퀘스트 클레임을 스스로 마감하는 AI 리뷰어를 제공하며, 그 경로에는 사람이 없다. 같은 회사, 반대 설정, 멤버가 지급받는지 여부에 영향을 미치는 결정에서 그렇다. 두 선택 모두 변호할 수 있다. 우리가 정직하게 말할 수 없는 것은 얼마나 많은 자율성이 적절한지에 대한 회사 전체의 단일 답이 있다는 것이다.

그러니 라벨을 떼자. Zealy가 실제로 제공하는 것은 인간 커밋 단계가 있는 에이전트가 읽을 수 있는 표면이며, 이는 대부분의 팀이 먼저 원해야 할 것에 대한 지루한 이름이다. 연결 메커니즘을 원한다면 MCP 통합 문서 가 정본이며 이 글은 이를 의도적으로 다시 서술하지 않는다. 그 아래의 더 오래되고 넓은 표면을 원한다면 API 문서 가 다룬다. 그리고 제품을 한 번도 사용해 본 적이 없다면 Zealy란 무엇인가 가 더 짧은 진입 경로다.

에이전트 마케팅이라는 이름의 무언가를 사기 전에 물어야 할 것

도구 목록을 요구하라. 에이전트 마케팅을 판매하는 벤더는 에이전트가 받는 명명된 작업과 그에 붙은 권한을 보여줄 수 있거나, 보여줄 수 없다. 나머지 전부, 즉 계획 언어와 목표 추구 언어와 데모는 양식에 연결된 챗봇과 호환되며, Young Urban Project는 그것에 이름을 붙였다.

가장 적은 회의 시간으로 가장 많은 정보를 얻는 순서의 다섯 가지 질문:

1. "에이전트가 받는 작업은 이름별로 무엇인가?" 답이 목록이 아니라 역량 문장이라면 답을 얻은 것이다. 목록이라면 동사를 읽어라. 읽기, 쓰기, 삭제, 전송, 게시, 지불.
2. "그중 어느 것이 나 없이 행동할 수 있는가?" "인간 개입이 있는가"가 아니다. 그 질문은 모두에게 예라는 답을 받는다. 어떤 특정 호출이 사람을 건너뛰는지, 그리고 누가 그 분할을 선택했는지 물어라.
3. "에이전트가 고객이 쓴 텍스트를 읽을 때 그 텍스트는 어떻게 되는가?" 도구 결과가 데이터로 취급되는지 잠재적 지시로 취급되는지 묻고 계신 겁니다. 이 점을 고민해 본 벤더라면 즉시 답할 것입니다. 엔지니어들의 잠을 못 이루게 하는 실패 유형이기 때문입니다.
4. "귀사의 위험 라벨은 무슨 의미인가요?" 그런 다음 영업 자료가 아니라 명세서와 대조해 답변을 확인하고, 기본값이 무엇인지 물어보세요. 대부분의 사람은 기본값을 거꾸로 짐작합니다.
5. "이것이 할 수 없는 것은 무엇인가요?" 경계 목록은 가장 저렴한 신뢰 신호이며, 이를 공개하는 곳은 거의 없습니다. 없다고 해서 무언가를 증명하는 것은 아닙니다. 있다면 그 가치는 매우 큽니다.

마지막으로 말씀드릴 것은 순서에 관한 것입니다. 여기서 구매 결정은 보통 시기를 놓치기 때문입니다. 에이전트형 마케팅을 평가하는 대부분의 팀은 반복 업무 중 무엇을 넘겨도 안전하고 무엇은 안전하지 않은지 아직 문서화하지 않았습니다. 그리고 그 결정은 그 일을 맡는 주체가 계약자든, 모더레이터든, 모델이든 동일합니다. 커뮤니티 업무를 위임하는 방법 은 사람들과 함께 이 문제를 짚어 나가며, 그 분석은 거의 그대로 적용됩니다. 먼저 그것을 하세요. 에이전트는 여전히 있을 것이고, 여러분은 어떤 도구를 실제로 원하는지 알게 될 것입니다.