질문 폼(채팅 안의 폼)이란?
에이전트가 대화 중간에 구성하는 작은 폼 — 선택지, 숫자, 날짜 — 으로, 타이핑으로 답할 질문 한 문단이 아니라 탭할 수 있는 무언가로 렌더링됩니다.
대부분의 상업적 대화에는 에이전트가 유용해지기 전에 네 가지 구체적인 것이 필요한 순간이 있습니다: 통화, 금액, 기간, 날짜.
산문으로 물으면 그것은 네 개의 질문을 담은 한 문단이 됩니다. 돌아오는 것은 그중 두 개에 대한 답인데, 당신이 묻지 않은 순서로, 금액은 "대략 160만"이라고 적혀 있습니다. 그다음 후속 질문, 그다음 그게 달러였는지에 대한 확인.
질문 폼은 그것을 몇 번의 탭으로 대체합니다.
에이전트가 구성할 수 있는 것
에이전트는 그 순간 필요한 것으로부터, 대화 한가운데서 폼을 스스로 작성합니다. 당신이 미리 설계해 트리거에 연결해 둔 폼이 아닙니다.
한 폼에 섞을 수 있는 다섯 가지 필드 종류:
- single과 multi — 열거 가능한 선택지 중에서 고르기
- number — 단위와 범위와 함께. 천 단위 구분 기호는 고객에게 표시되지만 에이전트가 값을 보기 전에 제거되어, 아무도 "160만"을 파싱하지 않습니다
- date — 허용된 범위와 함께
- text — 진정으로 열려 있는 그 한 가지를 위해
고객이 그것을 채우고 제출하면, 답은 에이전트가 이어 가는 메시지로 돌아옵니다.
흥미로운 부분은 자제력이다
이런 기능의 유혹은 그것을 끊임없이 쓰는 것이고, 모든 질문에 폼으로 답하는 에이전트는 결코 그러지 않는 에이전트보다 나쁩니다.
그래서 에이전트는 선택지가 진정으로 열거 가능하고, 실제 선택지가 최소 두 개이며, 앞으로 나아가는 데 필요할 때만 폼을 쓰도록 지시받습니다. 열린 질문 — "당신의 상황에 대해 말씀해 주세요" — 은 질문으로 남습니다. 마무리 인사도 마찬가지입니다: "더 필요한 것 있으세요?"에 대한 라디오 버튼을 원하는 사람은 없고, "대화 끝내기"라는 단일 선택지를 제시하는 폼은 그것이 대체한 문장보다 나쁩니다.
왜 비즈니스 에이전트에게 중요한가
데이터가 구조화되어 돌아옵니다. 숫자는 해석해야 할 구절이 아니라 숫자이며, 이는 다음 단계가 정수를 기대하는 견적 도구를 호출하는 것일 때 중요합니다.
같은 지점에 이르기까지 더 적은 턴. 여섯 번의 확인 메시지 대신 한 번의 주고받음으로 네 개의 사실 — 그리고 추가되는 모든 주고받음은 고객이 이탈할 수 있는 지점입니다.
고객의 언어로 작동합니다. 에이전트는 다른 모든 것을 쓰듯 라벨을 쓰므로, 스페인어 문의는 아무도 다섯 가지 번역을 유지하지 않아도 스페인어 폼을 받습니다.
답은 어디로 가나
제출된 폼은 데이터베이스 쓰기가 아닙니다 — 에이전트가 추론하는 메시지로 돌아옵니다. 이것이 중요한 이유는 다음 단계가 대개 다른 부품 중 하나이기 때문입니다: MCP 도구에 곧장 입력되는 숫자, Skill의 어느 분기가 실행될지 결정하는 선택지 집합, 혹은 다음 달에 아무도 다시 묻지 않도록 그 고객의 스페이스에 기억되는 사실들.
폼은 에이전트별로 활성화되므로, 오직 질문에만 답해야 하는 에이전트는 질문을 시작하는 능력을 결코 얻지 않습니다.
이것은 에이전트가 모델에 더하는 것의 좋은 예입니다. 모델은 무엇을 물을지를 결정하고, 그것을 탭할 수 있는 무언가로 렌더링하며, 돌아온 것을 검증하고, 깔끔한 숫자를 다음 도구에 건네는 것은 모두 하네스입니다.
에이전트를 위한 페이지별 브리핑 — 이미 알고 있어야 할 배경, 첫 인사말, 그리고 몇 가지 추천 질문 — 으로, 방문자가 채팅을 연 URL로부터 자동으로 선택됩니다.
에이전트가 특정한 미래 시점에 하기로 약속하는 작업 — 스스로 보내기로 결정한 후속 조치나, 반복되는 알림 — 으로, 누군가 먼저 말하기를 기다리는 대신 스케줄러가 제때 실행합니다.
한 고객의 대화, 문서, 기억을 담는 격리된 컨테이너 — 데이터베이스 수준에서 강제되어, 한 고객의 자료가 다른 고객의 대화에 나타날 수 없습니다.
사용자가 제공한 텍스트 — 또는 에이전트가 읽는 문서, 웹 페이지, 이메일에 숨겨진 텍스트 — 가 모델에 의해 새로운 지시사항으로 해석되어 에이전트가 규칙을 포기하거나, 정체성을 변경하거나, 시스템 프롬프트를 노출하게 만드는 공격입니다. 공격은 정당한 입력과 동일한 채널을 통해 도착하므로, 더 엄격한 프롬프트를 작성하는 것으로는 해결할 수 없습니다. 효과적인 방어는 모델 앞뒤에 위치해야 합니다.