레코드 — 에이전트가 수집한 것이 도달하는 곳

문의를 검증한 뒤 그것을 대화 기록에 남겨두는 에이전트는 일을 절반만 한 것입니다. 레코드가 나머지 절반입니다: 사람이 필요한 것마다 하나의 항목으로, 그것을 만들어낸 대화가 한 번의 클릭 거리에 있는, 대시보드의 큐입니다.

여기에는 설정할 것이 없습니다. 설정 마법사가 에이전트를 만들 때 이 도구들도 연결하므로, "당신의 팀에게 구조화된 파일을 넘긴다"고 말하는 템플릿이 이제 그것을 넘길 곳을 갖게 됩니다.

에이전트가 정리하는 것

lead 또는 checklist는 두 번째 레코드를 만드는 대신 그 대화의 레코드를 업데이트하므로, 한 채팅에서 두 번 정리하는 에이전트는 큐를 어지럽히는 대신 스스로 교정합니다. booking과 escalation은 매번 하나씩 만드는데, 그런 것 두 개는 실제로 두 가지 일이기 때문입니다.

참조 번호

모든 레코드는 짧은 참조 번호를 받습니다 — 7K4M-2QP — O/0와 I/1이 없는 알파벳으로 만들어집니다. 전화로 불러주고 다시 타이핑하다 틀리기 때문입니다. 에이전트가 이를 고객에게 주어 나중에 문의할 수 있게 합니다.

참조 번호는 접근 키가 아닙니다. 읽기는 대화에서 실려온 묻는 사람의 신원으로 인가되므로, 엿들은 참조 번호를 인용해도 아무것도 반환되지 않습니다.

자체 스택에서 도구 사용하기

두 개의 인터페이스, 같은 동작. 토큰은 대시보드의 Tenant & API에 있습니다.

MCP

마법사가 만든 에이전트에는 이미 연결되어 있습니다. 다른 곳에 연결하려면, streamable_http MCP 서버를 https://agent4.io/api/mcp에 Authorization: Bearer 헤더와 함께 가리키세요. 도구: submit_lead, open_checklist, request_booking, escalate, lookup_case, close_case.

HTTP

curl -X POST https://agent4.io/api/tools/records \
  -H "Authorization: Bearer $AGENT4_TOOL_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
        "type": "lead",
        "title": "Sarah — quote for a home policy",
        "summary": "Wants contents cover on a flat she has just bought.",
        "contact": { "name": "Sarah", "phone": "07700 900000" },
        "fields": { "sumInsured": "40000", "startDate": "2026-08-01" }
      }'

{ "reference": "7K4M-2QP", "created": true, "message": "Recorded. The reference is 7K4M-2QP …" }

PATCH /api/tools/records/{reference}와 {"outcome":"quoted"}로 하나를 종료합니다. GET /api/tools/records/{reference}로 하나를 읽으며, 이는 레코드가 속한 사람의 X-Agent4-End-User를 요구합니다.

필드

title, summary, contact, urgency는 모든 업종에서 동일합니다 — 큐가 정렬하고 표시하는 것입니다. 그 외 모든 것은 fields에 들어가며, 각 템플릿이 자기 업종이 수집하는 키를 선언하므로, telephone은 들어오는 길에 phone으로 접힙니다. 어떤 템플릿도 선언하지 않은 키는 버려지지 않고 보존되어, 레코드의 "also mentioned" 아래에 나타납니다.

통보받기

아무도 통보받지 못하는 큐는 아무도 읽지 않는 큐이므로, Notifications가 큐 자체에 놓여 있습니다. 두 개의 채널이 있고, 유형마다 어느 것이 발동할지 당신이 선택합니다.

이메일은 다른 곳을 지정하지 않는 한 로그인 주소로 갑니다 — 비용을 내는 사람이 큐를 처리하는 사람인 경우는 드뭅니다. 기본적으로 escalation과 booking 요청은 이메일을 보내고 문의는 보내지 않습니다: 문의마다 알림이 울리는 받은편지함은 음소거되고, 그러면 escalation까지 함께 침묵합니다.

Webhook. 레코드가 정리되는 순간 그것을 당신의 URL로 POST합니다:

{
  "event": "record.created",
  "record": {
    "reference": "7K4M-2QP",
    "type": "lead",
    "title": "Sarah — quote for a home policy",
    "summary": "Wants contents cover on a flat she has just bought.",
    "contact": { "name": "Sarah", "phone": "07700 900000" },
    "fields": { "sumInsured": "40000", "startDate": "2026-08-01" },
    "agent": "Front desk"
  },
  "url": "https://agent4.io/dashboard/records/7K4M-2QP"
}

두 개의 헤더가 함께 옵니다: X-Agent4-Timestamp와 X-Agent4-Signature — 타임스탬프, 점, 그리고 원본 본문의 HMAC-SHA256으로, 설정 페이지의 서명 secret으로 키를 씁니다. 이를 검증하면 그 POST가 URL을 알아낸 누군가가 아니라 우리 것임을 알 수 있습니다. 타임스탬프가 서명 안에 있으므로, 캡처된 요청은 나중에 재전송될 수 없습니다.

expected = hmac.new(secret.encode(), f"{ts}.{raw_body}".encode(), hashlib.sha256).hexdigest()
hmac.compare_digest(expected, request.headers["X-Agent4-Signature"])

URL은 https여야 하고 공용 인터넷에서 도달 가능해야 합니다 — 당신의 네트워크 안에서만 해석되는 주소는 레코드가 도착할 때마다 조용히 실패하는 대신, 저장할 때 거부됩니다. 이에 의존하기 전에 설정 페이지에서 테스트를 보내세요. 수신자가 실제로 무엇을 말했는지 보고합니다.

페이로드는 연락처 정보를 포함한 레코드 내용을 담습니다 — 그것을 생략한 webhook은 티켓을 열기에 충분하지 않을 텐데, 그것이 바로 그 webhook이 존재하는 이유입니다. 그러니 당신이 이것을 가리키는 엔드포인트는 고객의 개인 정보를 받으며, 당신이 그 정보를 보관하는 다른 어느 곳과 같은 주의를 받을 자격이 있습니다.

동료에게 넘기기

두 번째 계정이 필요 없습니다. 링크를 켜서 보내세요 — WhatsApp으로, 또는 누군가 화면에서 스캔하는 QR로. 케이스를 종료하면 링크가 꺼지므로, 취소가 기억해야 할 일이 아니라 작업을 마치는 일의 일부로 일어납니다. 링크를 껐다가 다시 켜면 다른 링크가 생성되므로, 옛 링크를 아직 가진 사람에게 "꺼짐"은 진짜로 꺼짐을 뜻합니다.

레코드를 인쇄할 수도 있습니다. 출력물은 만료가 없고 회수할 수 없으니, 건물을 떠나기 전에 잠시 생각해볼 만합니다.

떠나기

큐에서 언제든 모든 레코드를 CSV로 내보내세요. 이것을 넘어서 CRM으로 옮겨도 에이전트는 계속 동작합니다 — 레코드는 당신 것이고 함께 이동합니다.

우리가 저장하는 것과 방식

레코드의 전체 내용 — 제목, 요약, 연락처 정보, 메모 — 은 저장 시 암호화됩니다. 큐가 정렬하고 필터링하는 데 필요한 것만 평문 컬럼에 있습니다: 유형, 상태, 타임스탬프, 그리고 대화를 다시 가리키는 식별자들. 그 어느 것도 사람을 식별하지 않습니다.

의도적으로 받아들인 결과: 데이터베이스 쿼리로 레코드 내부를 검색할 수 없습니다. 필터링은 유형, 상태, 에이전트, 날짜로 이뤄집니다.

레코드는 당신을 대신해 보관하는 고객의 개인 정보입니다. 대시보드에서 하나 또는 전부를 삭제하세요. 계정을 닫으면 그와 함께 제거됩니다.