Як Claude бере на себе до 90% support tickets: кейс Kodif

Коли у SaaS, e-commerce або fintech росте кількість клієнтів, support майже завжди отримує той самий подарунок: більше однакових питань, більше перемикань між системами і більше людей, яких треба наймати лише для підтримки темпу. Класичне рішення — FAQ, макроси та ще одна зміна операторів. Воно працює, поки процес не впирається у звернення, де треба не просто відповісти, а щось реально зробити.

Kodif будує customer-support automation platform і використовує Claude через Amazon Bedrock як основу AI-агентів. За описом Anthropic, мета системи — не скоротити support до генератора тексту, а автоматизувати значну частину повного циклу обслуговування: зрозуміти запит, знайти контекст, обрати дію, використати зовнішній інструмент і повернути клієнту результат.

Claude використовується у Kodif у трьох шарах. Перший — автономні customer-service agents для складніших workflow на кшталт refunds і cancellations. Другий — допомога з вхідними tickets: визначення наміру клієнта, використання knowledge base, попередніх звернень і релевантної документації для формування відповіді. Третій — аналіз масиву support-даних, щоб знаходити тренди, групувати схожі проблеми та піднімати нові сигнали для бізнесу.

Ключова різниця з типовим чат-ботом у тому, що automation може взаємодіяти з іншими інструментами. Anthropic прямо наводить Shopify як приклад системи, з якою workflow може працювати. Окремо документація Amazon Bedrock підтверджує сам механізм Claude tool use: застосунок передає моделі опис дозволених інструментів, модель обирає потрібний tool, а виконання залишається за контрольованим application layer.

• розпізнавання intent і типу звернення;
• підтягування knowledge base та контексту попередніх tickets;
• генерація персоналізованої відповіді у brand voice;
• refund і cancellation workflows;
• використання зовнішніх інструментів, зокрема Shopify;
• кластеризація звернень і пошук нових бізнес-проблем.

Уявімо клієнта, який пише: «Хочу скасувати замовлення і повернути гроші». Слабкий AI-бот красиво перепише FAQ і передасть звернення оператору. Agentic workflow працює інакше: спочатку класифікує intent, потім отримує дозволений customer context, перевіряє policy, визначає допустиму дію і лише після цього викликає потрібний бізнес-інструмент. Результат tool call повертається в контекст, після чого клієнт отримує відповідь уже з фактичним статусом операції.

Нижче — відтворюваний AI-Magister патерн, а не твердження про точну внутрішню архітектуру Kodif. Це важливе розділення: з джерела ми знаємо про refunds, cancellations, knowledge base, ticket context і external tools; конкретні production-контроли на кшталт idempotency, approval threshold та retry policy є інженерною рекомендацією для безпечного повторення такого класу систем.

• Trigger → новий support ticket;
• Intent → що саме хоче клієнт;
• Context → профіль, історія, замовлення, knowledge base;
• Policy → чи дозволена дія для цього сценарію;
• Decision → відповідь, tool call або escalation;
• Tool call → Shopify / CRM / billing / інша система;
• Validation → перевірка фактичного результату операції;
• Response + Audit → відповідь клієнту та журнал дії.

Kodif підкреслює explainability: команда може бачити reasoning, пов’язаний із діями AI, використовувати його для debugging і покращувати knowledge base. Це змінює роль оператора. Замість ручного виконання кожного типового ticket людина все більше контролює винятки, політики, якість і ті дії, для яких ціна помилки вже не схожа на вартість неправильної коми у листі.

У production-моделі authority краще проектувати окремо від reasoning. Claude може визначити, що refund логічний, але право реально списати або повернути гроші повинно залежати від суми, policy, tenant, permissions і approval rules. Низька confidence, конфлікт даних або ризикова операція мають вести до human review із уже зібраним контекстом, а не до ще одного творчого prompt.

Найсильніша частина кейсу — Claude використовується не лише для відповіді клієнту. Kodif аналізує потік звернень, групує схожі проблеми та допомагає побачити нові патерни. П’ятсот окремих скарг на checkout перестають бути п’ятьмастами приватними діалогами різних операторів і можуть стати одним бізнес-сигналом: після релізу різко зросли проблеми на конкретному етапі оплати.

Тому ROI такого workflow не варто рахувати лише через cost per ticket. Той самий data exhaust може працювати на product, operations, retention і quality management. Support із центру витрат поступово стає сенсором, який показує, що реально відбувається з клієнтом після того, як красивий funnel у презентації вже закінчився.

У customer story Anthropic описано Fellow: AI-powered cancellation flow не просто прискорював скасування. Частина клієнтів у процесі розуміла, що хоче змінити замовлення або додати до нього товари. Простий шлях до модифікації замість тупого «скасувати й закрити» у певних сценаріях збільшував order value.

Це хороший продуктовый урок: automation support можна проектувати не тільки як «менше операторських хвилин». Якщо agent розуміє причину звернення і має безпечний набір наступних дій, support стає точкою retention, recovery і навіть upsell. Тобто автоматизуємо не листування — автоматизуємо шматок customer journey.

Anthropic повідомляє до 90% automation support tickets для Trust Wallet і приблизно 75% для Halo Collar. Це сильні reported metrics, але вони належать конкретному vendor/customer case study. Вони не означають, що підключення Claude автоматично перетворює будь-який helpdesk на 90-відсотковий autopilot.

На тій самій сторінці є суперечливі значення щодо Dollar Shave Club у різних фрагментах. AI-Magister свідомо не використовує цю цифру як headline-метрику. Саме так і має працювати рубрика: навіть офіційний customer story — це джерело, яке треба перевіряти на внутрішню узгодженість, а не маркетингове Євангеліє.

• Trust Wallet — до 90% automation за даними кейсу;
• Halo Collar — близько 75% automation за даними кейсу;
• складні workflows включають refunds і cancellations;
• окремий шар використовується для аналізу trends і emerging issues.

Це не кейс рівня «відкрий Claude і встав промпт». Для повторення потрібні LLM API або Bedrock, helpdesk, knowledge base, customer context, tool layer для CRM або commerce systems, rules/permissions, журналювання, evaluations і escalation. Найбільша інженерна робота часто не в LLM, а в тому, щоб реальні бізнес-дії були доступні через вузькі, безпечні та передбачувані контракти.

A4 означає, що значна частина workflow може пройти без оператора, включно з використанням інструментів і exception handling. Але A5 тут було б передчасним: refunds, cancellations, персональні дані та нестандартні випадки вимагають контрольних меж. Повна автономність без authority model — це не інновація, а дуже сучасний спосіб створити старомодний фінансовий інцидент.

• Claude API або Amazon Bedrock;
• helpdesk / ticketing platform;
• knowledge base і customer context;
• CRM, Shopify, billing або власні APIs;
• policy engine та approval thresholds;
• observability, audit logs, retries та idempotency;
• evaluation dataset для типових і ризикових сценаріїв.

Найкращі кандидати — компанії з великим потоком повторюваних звернень, структурованими APIs і відчутною часткою tickets, де оператор фактично виконує стандартну операцію в іншій системі. Саме там LLM може прибрати не лише написання відповіді, а й кілька ручних переходів між helpdesk, CRM, billing та commerce tools.

Починати логічно не з KPI «автоматизуємо 90% support», а з одного bounded workflow: order status, subscription cancellation або low-risk refund. Далі — evals, approval rules, escalation rate, wrong-action rate і лише після стабільних цифр розширення authority. Менше пафосу на старті, більше шансів реально дійти до A4.

У кейсі Kodif Claude стоїть не в кінці процесу як генератор відповіді, а в середині керованого support workflow. Trigger — новий ticket або наступний turn у вже відкритому зверненні. До AI потрапляють intent-сигнали, релевантний customer context, попередні tickets, knowledge-base матеріали та дозволений набір дій. Далі модель має не лише сформулювати текст, а визначити, чи достатньо інформації для відповіді, чи потрібен зовнішній tool, і чи не виходить сценарій за межі автоматичної authority.

Результат циклу — не просто message. Це або grounded response, або structured request на дію, або escalation. Для refund чи cancellation критично розділяти decision і execution: AI може запропонувати наступний крок, але реальний side effect повинен виконувати application layer через вузько визначений API-контракт. Такий дизайн збігається з актуальною моделлю tool use в Amazon Bedrock, де модель повертає tool request, а застосунок виконує інструмент і передає результат назад.

• Trigger → новий ticket / новий turn у thread;
• Inputs → intent, customer/order context, history, knowledge base, policy;
• AI stage → classify → retrieve → decide → respond або request tool;
• Tool execution → application layer виконує дозволену дію;
• Validation → фактичний результат side effect повертається в loop;
• Output → response + audit event або escalation із повним контекстом.

AWS прямо описує tool-use contract: модель бачить definitions інструментів, вирішує, коли вони потрібні, але в client-side режимі саме application code виконує tool і повертає tool_result. Це принципово важливо для support automation. Refund, cancellation, account change або subscription action мають бути захищені policy layer незалежно від того, наскільки переконливо модель сформулювала рішення.

Практичний authority matrix варто будувати за risk tier. Read-only дії — status lookup, knowledge retrieval, order inspection — можуть працювати автономно. Reversible low-value operations можна дозволяти в межах суми, tenant policy та rate limits. High-value refunds, identity conflicts, нестандартні contractual cases або дані з низькою confidence мають переходити людині. Human-in-the-loop тут не декоративний approval screen, а окремий control plane.

• Tier 0 → read-only lookup, автономно;
• Tier 1 → reversible low-risk action у policy bounds;
• Tier 2 → фінансовий side effect до встановленого threshold;
• Tier 3 → high-value / identity / policy exception → mandatory human review;
• Кожен tool має least-privilege scope, schema validation і tenant binding;
• Approval прив’язується до exact payload, а не до абстрактного «дозволити агенту».

Головний production KPI для такого агента — не максимальна частка автоматизованих tickets, а мінімальна частка неправильних дій. Якщо knowledge base застаріла, order state змінився між retrieval і execution, API повернув partial failure або customer identity не збігається, система повинна зупинити side effect. Модель не повинна компенсувати технічну невизначеність творчістю.

Для цього потрібні idempotency keys, precondition checks, post-action verification, bounded retries і explicit escalation reasons. Tool result має бути джерелом фактичного стану після дії. Якщо refund API не підтвердив операцію, клієнту не можна відповідати «повернення виконано» лише тому, що AI очікував успіх. Кожен клас production failure після інциденту має потрапляти в regression/eval set.

• Stale context → повторний read перед side effect;
• Conflicting policy → block + human review;
• API timeout → bounded retry з тим самим idempotency key;
• Partial success → verify downstream state перед customer response;
• Identity mismatch → нуль фінансових дій до re-verification;
• Repeated failure pattern → incident + eval regression case.

Support-agent workflow є event-driven: модель викликається на кожен relevant ticket turn, а складні сценарії можуть створювати кілька model/tool cycles в одному зверненні. Тому cost scale залежить не від кількості клієнтів як такої, а від ticket volume × turns × retrieval × tool calls × retry rate. AWS окремо зазначає, що tool use додає token overhead через tool definitions, tool_use і tool_result blocks; отже «ціна одного запиту» майже ніколи не дорівнює ціні завершеного support case.

Оптимізація починається з маршрутизації, а не з урізання якості. Простий intent classification, status lookup або deterministic policy check не потребують найдорожчого inference path. Сильніша модель потрібна там, де є складна мова, багатокрокова логіка або ризикове рішення. Водночас економити на evaluation чи observability — класичний спосіб зробити automation дешевшою в billing і дорожчою в інцидентах.

• Cost unit → cost per successfully resolved case, не cost per model call;
• Scale drivers → ticket volume, turns, context size, tool calls, retries;
• Hidden cost → human exception review, knowledge maintenance, incident handling;
• Optimization → routing, caching stable facts, bounded context, deterministic policy checks;
• Business KPI → containment, resolution time, CSAT/retention, revenue recovery;
• Safety KPI → wrong-action rate, reversal rate, escalation precision, policy violations.

Kodif customer story описує сильні reported results, але це vendor/customer evidence, а не універсальна формула. Anthropic на одній сторінці навіть подає різні значення automation rate для Dollar Shave Club у різних фрагментах, тому AI-Magister не використовує цю цифру як канонічну метрику. Trust Wallet 90% і Halo Collar 75% залишаються reported figures конкретних deployments, а не очікуванням для нового проєкту.

Для відтворення важливіший патерн: bounded workflow, authoritative data, safe tools, human oversight і evals. У customer story згадується Claude 3.5 Sonnet як модель, яку Kodif обрав на той момент; сьогодні production design не повинен механічно прив’язуватися до цієї версії. Вибір моделі треба робити через актуальну support matrix і власний evaluation dataset, бо provider lineup та Bedrock capabilities змінюються швидше, ніж бізнес-процес.

• 1. Вибрати один bounded use case: order status, cancellation або low-risk refund;
• 2. Визначити canonical customer/order/policy sources і freshness SLA;
• 3. Побудувати tool contracts із least privilege та schema validation;
• 4. Ввести authority tiers і monetary/action thresholds;
• 5. Запустити shadow/draft mode на реальних historical tickets;
• 6. Виміряти factuality, correct-action rate, escalation quality і latency;
• 7. Дозволити autonomy лише для low-risk класів після threshold pass;
• 8. Розширювати coverage по одному workflow, додаючи failures у regression set.

Після того як support agent уже вміє читати контекст, викликати tools і закривати частину звернень без оператора, головне питання змінюється. Не «скільки tickets ми автоматизували?», а «яка частка автоматизації завершилася правильним outcome без прихованого боргу». Kodif публічно акцентує на explainability та можливості людей розуміти й debug-ити AI actions; це логічно переводить систему з demo-метрики automation rate до операційної моделі quality control.

Anthropic у матеріалі про evals для agents окремо виділяє conversational agents: для них треба оцінювати і перевіряємий кінцевий стан, і якість самої взаємодії. Для support це означає одночасно перевіряти, чи ticket справді вирішено, чи правильна дія відбулася в зовнішній системі, скільки turns знадобилося, чи не було policy violation і чи залишалася комунікація коректною для клієнта.

• Outcome correctness → фактичний стан order/refund/cancellation після workflow;
• Tool correctness → правильний tool, параметри, tenant і sequence;
• Policy compliance → жодної дії поза authority boundary;
• Conversation quality → tone, clarity, completeness і відсутність зайвих turns;
• Escalation quality → складні кейси переходять людині вчасно й з повним контекстом;
• Business outcome → resolution time, containment, retention/revenue recovery, а не лише volume.

Anthropic описує agent eval через чотири базові сутності: task, trial, grader і transcript/trace. Цю модель легко перенести на customer support. Task — наприклад «скасувати subscription відповідно до policy». Trial — один реальний прогін агента з тестовим customer state. Graders перевіряють окремі властивості: чи cancellation реально сталася, чи не був виданий зайвий refund, чи відповідь відповідала policy, чи escalation була коректною. Trace зберігає весь шлях: model turns, retrieval, tool calls і результати.

Через недетермінованість одного успішного прогону замало. Для ризикових класів потрібні кілька trials на той самий сценарій і варіації input: нечітке формулювання, конфліктні дані, відсутній order, повторний запит після вже виконаної дії, timeout downstream API. Саме так перевіряється не красивий happy path, а поведінка системи під навантаженням неоднозначності.

• Task → конкретна support-задача з початковим state і success criteria;
• Trial → один прогін агента; для критичних кейсів потрібно кілька повторів;
• Code grader → перевіряє фактичний downstream state, schema, limits і side effects;
• Model grader → оцінює tone, completeness, policy reasoning або interaction quality;
• Human grader → потрібен для неоднозначних policy/brand cases і калібрування;
• Trace → повний transcript + retrieval + tool calls + tool results + escalation.

Найгірший eval dataset — випадкова сотня простих tickets, на яких система завжди виглядає добре. Для Kodif-класу workflow цінні саме ті сценарії, де модель повинна знати межу автономності. Golden set варто будувати не лише з частих звернень, а з комбінації frequency × business impact × failure severity.

Практичний набір повинен включати звичайні запити, boundary cases, adversarial wording і відомі production incidents. Кожен новий wrong action або слабка escalation після розбору стає regression case. Так evaluation накопичує організаційну пам’ять: одна й та сама помилка не повинна повертатися після наступної зміни prompt, model, knowledge base або tool description.

• High-volume → order status, FAQ, стандартна cancellation;
• High-impact → refund, subscription/account changes, фінансові side effects;
• Boundary → сума рівно біля approval threshold або policy exception;
• State conflict → knowledge каже одне, backend state — інше;
• Retry/idempotency → повторний user message після вже виконаної операції;
• Adversarial → користувач просить обійти policy або маніпулює контекстом;
• Incident-derived → кожен підтверджений production failure додається у regression suite.

Для нового support workflow безпечніша траєкторія — не увімкнути autonomy для всіх і дивитися на CSAT, а поступово підвищувати authority. Спочатку historical replay та offline evals, потім shadow mode на живому трафіку без side effects, далі limited canary для одного low-risk intent і лише після стабільного результату розширення coverage. Це AI-Magister production pattern, а не твердження про внутрішній rollout Kodif.

Gate має бути багатовимірним. Високий containment не компенсує неправильні financial actions, а чудовий tone не компенсує слабку factuality. Для кожного intent визначається мінімальна якість outcome, максимальний wrong-action rate, допустима escalation rate і latency/cost budget. Якщо regression suite падає після заміни моделі чи prompt — rollout зупиняється незалежно від того, наскільки нова модель сильніша в загальному benchmark.

• Stage 0 → historical replay без зовнішніх side effects;
• Stage 1 → shadow mode на живих tickets;
• Stage 2 → canary autonomy лише для одного low-risk intent;
• Stage 3 → розширення за intent/risk tier після threshold pass;
• Rollback trigger → wrong action, policy breach, різкий eval regression або downstream anomaly;
• Model upgrade → той самий regression suite до зміни production routing.

Після переходу в production evals перестають бути лише pre-release тестами. Частина сигналів має жити в щоденному operations loop: які intents деградують, де росте escalation, які tools дають partial failures, де з’явилися нові policy gaps. Kodif описує support data як джерело business intelligence; той самий принцип варто застосувати і до самого AI-agent layer — його traces є джерелом intelligence про якість automation.

Корисна схема — розділяти Quality, Runtime і Business. Quality показує correctness і policy behavior. Runtime — latency, tool errors, retries, context size та cost. Business — containment, resolution, CSAT/retention і revenue influence. Якщо дивитися тільки на одну площину, легко отримати false-green: наприклад, containment росте, але разом із ним росте reversal rate після помилкових дій.

• Quality → task success, wrong-action rate, factual error, policy violations, escalation precision;
• Runtime → p50/p95 latency, tool failure rate, retries, token/context cost, timeout rate;
• Business → containment, time-to-resolution, CSAT/retention, cancellation recovery, revenue influence;
• Drift → зміна performance за intent, model version, knowledge version і customer segment;
• Review queue → top failures за severity × frequency, а не за кількістю скарг;
• Weekly action → кожен значущий failure має owner, fix і новий regression test.

Для довгих support threads головна помилка — щоразу віддавати моделі весь transcript і сподіватися, що останні 40 повідомлень самі перетворяться на надійний state. Anthropic зараз прямо описує context як скінченний ресурс: tool definitions і накопичені tool_result блоки роздувають prompt, а нерелевантний старий контекст погіршує фокус. Для production-повторення кейсу Kodif потрібен окремий durable case state: хто клієнт, що вже перевірено, яка policy version застосована, які дії виконані, що ще pending і хто зараз володіє кейсом — AI чи людина.

Це не твердження про внутрішню архітектуру Kodif. Це сучасний reproduction pattern для того самого класу задач. Conversation history залишається доказом і джерелом нюансів, але execution decisions повинні спиратися на структурований state із timestamp, source і freshness. Якщо refund status у CRM змінився після попереднього turn, старий transcript не має права перемогти новий authoritative read.

• Case state → customer/tenant ID, verified identity level, intent, open obligations, policy version, pending action, owner, timestamps;
• Transcript → контекст для мови й нюансів, але не canonical source для order/refund/account state;
• Кожен consequential turn починається з freshness check для змінних бізнес-даних;
• Human takeover створює ownership lock: AI не продовжує side effects, поки кейс не повернуто в automation;
• Closed case → immutable resolution summary + посилання на audit events, а не нескінченний живий prompt.

Поточний Claude Platform memory tool дозволяє зберігати й повертати інформацію між сесіями; при цьому операції виконуються client-side, а application layer контролює реальне сховище. Для support це корисно для стабільних preference, summary попередніх взаємодій або operator-approved lessons, але небезпечно використовувати memory як неявну базу істини для фінансових чи account facts.

Production rule простий: memory може допомогти згадати, що шукати, але не замінює authoritative lookup. Дані мають бути tenant-scoped, мати provenance, TTL/expiry і write policy. Персональні або чутливі дані варто мінімізувати; для customer-specific memory потрібне явне namespace isolation. Anthropic окремо радить обмежувати memory operations дозволеним directory/prefix і захищати реалізацію від path traversal — хороший нагадувач, що «памʼять агента» насправді є ще одним privileged tool.

• Memory дозволено → stable preference, approved support summary, reusable troubleshooting state;
• Memory заборонено як source of truth → balance, refund completion, subscription state, identity status;
• Write gate → provenance + tenant ID + sensitivity class + expiry;
• Read gate → тільки namespace поточного customer/tenant і лише потрібні записи;
• Conflict rule → CRM/order system/policy service завжди перемагає model memory;
• Deletion/retention → керується application layer, а не випадковим рішенням моделі.

Anthropic документує context editing для очищення старих tool results і compaction для довгих conversations; memory можна комбінувати з цими механізмами, щоб важливе переживало скорочення контексту. У support workflow це означає, що великий shipping payload або проміжний API response можна прибрати після нормалізації, але customer commitment, незавершений refund, escalation reason або підтверджена identity state мають спочатку перейти в structured case ledger.

Найнебезпечніший failure mode тут тихий: після compaction модель памʼятає загальну історію, але губить одну умову, від якої залежить side effect. Тому до і після compaction потрібен invariant check. Якщо summary не містить pending financial action, останній verified state, policy version і ownership, conversation не повинна автоматично продовжуватися на тому самому рівні автономності.

• Can compact → старі retrieval snippets, verbose tool outputs, дублікати status reads;
• Must persist → identity proof level, promises to customer, pending side effects, approvals, escalation owner;
• Before compaction → materialize critical state у ledger;
• After compaction → re-read ledger + revalidate volatile business facts;
• Context reset не скидає idempotency keys або approval binding;
• При неповному recovery → downgrade autonomy та передай кейс людині.

Customer support agent читає тексти, вкладення, knowledge articles і tool outputs — тобто постійно працює з даними, які можуть містити інструкції, що не мають права змінювати system policy. Anthropic у матеріалі про containment показує жорсткіший принцип: model-layer захистів недостатньо, якщо середовище дозволяє небезпечний side effect; filesystem/network boundaries мають блокувати дію незалежно від того, наскільки переконливим був prompt.

Для support це переноситься на памʼять і бізнес-інструменти. Текст клієнта не може сам записати нове правило refund policy, підняти authority tier або створити persistent instruction для наступних tickets. Customer-derived memory потрібно відділяти від operator-approved policy memory, а write у довгоживучий state — валідовувати. Інакше одна вдало сформульована інʼєкція переживе закриття ticket і стане подарунком наступному інциденту.

• Trust labels → user text, attachment, KB, CRM fact, policy, operator approval мають різний рівень довіри;
• Untrusted content не змінює tool permissions, policy або system instructions;
• Persistent memory write із customer content проходить schema/provenance validation;
• Policy memory → тільки versioned operator-controlled source;
• Sensitive tools → allowlist, narrow scopes, payload validation, network/egress controls де доречно;
• Security eval → indirect injection, cross-tenant recall, poisoned memory, fake approval, exfiltration attempt.

Claude Platform окремо описує чотири механізми для tool-heavy agents: tool search, programmatic tool calling, prompt caching і context editing. Для high-volume support вони вирішують різні проблеми: не тягнути десятки tool schemas у кожен turn, не платити повторно за стабільні prefixes, не накопичувати мертві tool results і не робити зайві roundtrips там, де ланцюжок безпечний для автоматичного виконання.

Але оптимізація не повинна зʼїдати control plane. Programmatic batching доречний для read-only enrichment або детермінованого збору даних; фінансові чи account-changing дії краще не ховати всередині непрозорого batch, якщо між кроками потрібні approval, precondition або human checkpoint. Для бізнесу треба рахувати не tokens per message, а cost per correctly resolved ticket з урахуванням context growth, tool latency, retries, escalations і повторних звернень.

• Large toolset → on-demand tool discovery замість завантаження всіх schemas у кожен turn;
• Stable policy/tool prefix → caching там, де це дає вимірювану економію;
• Long thread → context editing/compaction після materialization critical state;
• Read-only multi-tool enrichment → кандидат на batching/programmatic execution;
• Consequential action chain → зберігати окремі verification/approval checkpoints;
• Unit economics → AI + retrieval + tools + retries + human review + recontact cost на коректно закритий кейс.

Anthropic у методиці agent evals підкреслює, що multi-turn agents треба оцінювати через task, environment, trajectory і outcome, а не лише фінальний текст. Для customer support це особливо важливо після memory/compaction змін: одна й та сама проблема має пройти replay через короткий thread, довгий thread, context reset, human takeover і повторне відкриття кейсу.

Acceptance gate повинен ловити continuity failures: повторне питання вже перевірених даних, забуту обіцянку, stale policy, повторний refund, виконання після human takeover, cross-tenant memory leak або відповідь «готово» без підтвердженого tool result. Нову модель, prompt, retrieval rule чи context-management policy варто випускати лише якщо вона не погіршує ці сценарії. Це AI-Magister production guidance, а не твердження, що саме такий eval harness використовує Kodif.

• Replay set → real resolved tickets + incidents + long-thread edge cases;
• Continuity metrics → repeated-question rate, stale-state error rate, duplicate-action rate, takeover violations;
• Security metrics → cross-tenant recall, memory poisoning success, unauthorized tool attempt;
• Outcome grader → правильний фактичний стан у CRM/tool system після завершення;
• Trajectory grader → чи були потрібні reads, approvals, retries й escalation у правильному порядку;
• Release rule → regression у high-severity continuity/security case блокує rollout незалежно від середньої text score.

Не треба будувати ще одного агента або окремий orchestration stack. Розширення робиться навколо вже наявного workflow: додати structured case ledger, правила memory read/write, compaction invariants і continuity eval suite. Потім увімкнути це спочатку в shadow режимі на довгих та повторно відкритих tickets, де користь і ризик найбільші.

80/20 ефект дають чотири речі: canonical state поза transcript, strict tenant isolation, revalidation перед side effect і regression replay після кожної зміни context policy. Решта оптимізацій — tool search, caching, compaction thresholds — мають сенс лише після того, як ці чотири інваріанти реально вимірюються.

• 1. Визначити мінімальну schema case ledger і canonical owners кожного поля;
• 2. Позначити volatile facts, які завжди перечитуються перед action;
• 3. Розділити session context, durable customer memory і operator-controlled policy;
• 4. Додати tenant-scoped memory adapter з provenance/TTL/delete controls;
• 5. Ввести compaction invariant check і autonomy downgrade при incomplete recovery;
• 6. Зібрати continuity/security replay set з довгих, escalated і reopened tickets;
• 7. Лише після PASS оптимізувати context cost та поступово розширювати coverage.

Kodif описує Claude-powered support agents, які використовують knowledge base articles, контекст попередніх tickets і релевантну документацію для відповідей та складних workflows. Але сам факт, що документ знайшовся в search, ще не робить його правильною policy для конкретного клієнта, регіону або моменту часу. Для production-повторення кейсу потрібен policy corpus із явним ownership: кожен article або rule має document ID, owner, status, version, effective-from/effective-to, product/region/channel scope і sensitivity class.

Це AI-Magister reproduction guidance, а не твердження про внутрішню schema Kodif. Модель не повинна самостійно обирати між draft, archived і current policy лише за semantic similarity. Eligibility визначає application layer до retrieval: якщо документ не чинний або не дозволений для цього customer context, він не потрапляє в candidate set взагалі.

• Canonical metadata → document ID, owner, status, version, effective dates, product, region, channel, audience;
• Eligibility first → draft/expired/out-of-scope policy відсіюється до semantic ranking;
• Authoritative source → customer-facing rule має один визначений owner або явний precedence chain;
• Change event → нова policy version інвалідовує або переіндексовує залежні chunks;
• Sensitive guidance → окремий access scope для internal-only escalation/fraud procedures;
• Trace → відповідь і side effect зберігають policy/source IDs та versions, а не лише generated text.

Для support retrieval одного vector similarity мало. Exact identifiers, plan names, error codes і policy numbers часто краще ловляться lexical search, тоді як перефразовані customer intents — semantic retrieval. Практичний pipeline: спочатку deterministic metadata filters, потім lexical + semantic candidates, deduplication/rank fusion, за потреби reranking і лише після цього компактний evidence pack для Claude.

Anthropic у власних експериментах Contextual Retrieval повідомляє про зниження top-20 retrieval failure rate на 35% для Contextual Embeddings, на 49% для Contextual Embeddings + Contextual BM25 і на 67% після додавання reranking. Це provider-reported experimental metrics на їхніх datasets, а не універсальна обіцянка для customer support. Для вашого corpus параметри top-k, chunking, lexical weight і reranker треба підбирати на власному resolved-ticket eval set.

• Filter → tenant/product/region/language/policy-status/effective-date;
• Lexical path → точні SKU, error code, policy ID, order-state terminology;
• Semantic path → paraphrase, intent, symptom і long-form customer description;
• Rerank → лише після eligibility; дорогий reranker не виправляє неправильний access scope;
• Evidence budget → передавати top supporting chunks, а не випадкові 30 документів про всяк випадок;
• Eval → Recall@k/Hit@k, rank quality, stale-source rate і unsupported-answer rate по окремих slices.

Поточний Claude Platform підтримує citations для documents і search_result content blocks. Для власного RAG search result може містити stable source identifier, title, text blocks і citations.enabled=true; Claude повертає citation pointers до конкретних блоків. Для support це зручно не лише для UI: citation map можна використати в audit, reviewer console і regression evals, щоб бачити, які саме chunks підтримали claim.

Але citation доводить тільки те, що відповідь посилається на переданий source block. Вона не доводить, що документ чинний, авторизований для цього tenant або взагалі правильний. Тому source eligibility, freshness і precedence залишаються детермінованими application-layer gates. Інакше ви отримаєте дуже переконливу неправильну відповідь — зате з акуратним посиланням.

• Source ID → стабільний internal URI або document ID, а не назва, що змінюється;
• Fine-grained blocks → policy clause/section окремими citable blocks для точнішої attribution;
• Reviewer UI → claim + cited clause + source version + effective date поруч;
• Citation coverage → high-risk factual/policy claims без supporting source блокуються або ескалюються;
• Source validity → citation на archived/out-of-scope doc вважається failure, навіть якщо text формально збігається;
• Audit → зберігати source/version IDs і citation locations без необхідності безстроково дублювати весь corpus.

Support automation часто живе довше за одну policy version: ticket відкрився в понеділок, refund rule змінився у вівторок, а side effect виконується в середу. Structured case state вже вирішує проблему stale customer facts; той самий принцип потрібен для policy. Перед consequential action workflow має перечитати current authoritative policy version і перевірити, що approval та proposed action досі сумісні з нею.

Не кожна історична розмова повинна ретроспективно застосовувати найновіше правило — це залежить від contract/policy semantics. Саме тому effective dates і applicability повинні бути даними, а не припущенням моделі. Якщо правило змінилося після draft відповіді, старий evidence pack не має автоматично переживати change event.

• Read time → фіксуйте retrieved policy version і timestamp;
• Action time → re-read/revalidate policy для refunds, cancellations, credits, account restrictions та інших side effects;
• Approval binding → approval містить policy version; нова incompatible version інвалідовує approval;
• Long ticket → policy refresh trigger при reopen, escalation, scheduled retry або change notification;
• Historical applicability → effective-date logic задає system of record, не LLM;
• Metric → stale-policy action rate має бути zero-tolerance для high-severity workflows.

Реальний knowledge base майже завжди містить конфлікти: старий help-center article, нову internal SOP, регіональний виняток і product note, який ніхто не архівував. Ranking не вирішує precedence. Application layer має мати deterministic conflict policy: які source classes старші, коли потрібен specialist owner і які intents взагалі заборонено закривати без достатнього evidence coverage.

Для low-risk FAQ можна дозволити bounded answer із явною невпевненістю. Для refund eligibility, account restriction або інших consequential cases відсутність чинного source — це не запрошення до творчості. Правильний output: abstain, collect missing fact або escalate із зібраним evidence pack. Це дешевше за впевнену вигадку, хоча менш ефектно виглядає на демо.

• Precedence table → policy service > approved SOP > public help article > informal note; конкретний порядок визначає бізнес;
• Conflict detector → два чинні authoritative rules з несумісними conclusions блокують autonomy;
• Insufficient evidence → no-answer/escalation path є штатним результатом;
• Missing field → спочатку deterministic fetch/clarifying question, а не hallucinated assumption;
• Escalation bundle → intent, verified customer facts, conflicting sources, versions і proposed next step;
• Eval slice → conflict, expired source, wrong region, empty retrieval і intentionally unanswerable cases.

У поточній Claude Platform документації є важливе implementation constraint: citations несумісні зі Structured Outputs в одному request, бо citation blocks interleave з text, а strict JSON schema цього не дозволяє. Для support automation не треба лікувати це prompt gymnastics. Розділіть два контури: evidence-backed customer explanation і deterministic action planning/execution.

Практичний pattern: grounding stage повертає customer-facing draft із citations та internal evidence IDs; окремий planner отримує нормалізований case state, дозволені policy IDs і формує strict action object без citations. Application layer повторно перевіряє policy/version/authority та виконує tool. Так citation fidelity не конфліктує з machine-validated action schema, а model prose не стає прихованим API contract.

• Stage A — grounding → cited explanation/draft + evidence IDs;
• Stage B — planner → strict schema: intent, action, arguments, policy IDs, preconditions;
• Stage C — validator → authority, freshness, approval, idempotency, payload constraints;
• Stage D — executor → реальний side effect у CRM/order/payment system;
• Stage E — confirmation → tool result + postcondition → customer response;
• Failure rule → planner не може посилатися на policy ID, якого немає в validated evidence set.

Grounding треба оцінювати на двох рівнях. Retrieval рівень перевіряє, чи правильний policy взагалі потрапив у evidence pack. Decision рівень перевіряє, чи відповідь і side effect реально відповідають чинному rule. Хороший Recall@k не врятує workflow, якщо модель цитує правильний paragraph, а refund усе одно виконує за старим exception.

Release suite варто збирати з real resolved tickets, policy-change incidents і synthetic boundary cases. Кожна зміна chunking, embedding, reranker, metadata filter, prompt або policy corpus version проходить однакові slices. High-severity stale/conflict/unauthorized regression блокує rollout незалежно від середнього answer score.

• Retrieval → Recall@k/Hit@k, exact-ID hit rate, correct-region hit rate, stale-source leakage;
• Grounding → citation/source correctness, support coverage, unsupported claim rate, abstention quality;
• Decision → policy-to-action alignment, forbidden-action rate, correct escalation rate;
• Temporal → ticket across policy update, reopen after change, cached stale evidence, delayed retry;
• Security → unauthorized internal policy retrieval, tenant leakage, injected fake policy document;
• Release gate → zero high-severity policy/action mismatch before autonomy increases.

Новий orchestration stack тут не потрібен. Найбільший ефект дають чотири зміни навколо вже існуючого support agent: versioned policy metadata, deterministic eligibility filters, citable evidence pack і separate validated action stage. Після цього можна оптимізувати contextual retrieval, reranking, caching і chunking на власних evals.

Починати варто з двох-трьох high-volume intents, де policy чітка й side effects обмежені. Спочатку shadow replay, потім cited draft для human review, далі bounded autonomy тільки для cases без conflict/freshness flags. Якщо система не може пояснити, який чинний source дозволив дію, вона ще не готова робити цю дію самостійно.

• 1. Інвентаризувати policy corpus і додати owner/version/effective/scope metadata;
• 2. Ввести deterministic eligibility filters до retrieval;
• 3. Повернути top evidence як citable search_result/document blocks;
• 4. Розділити cited explanation і strict action planner;
• 5. Додати stale/conflict/no-answer gates та escalation bundle;
• 6. Зібрати policy-grounding regression suite з реальних resolved tickets;
• 7. Запускати shadow → human-reviewed drafts → bounded autonomy по intent slices;
• 8. Підвищувати automation coverage лише після стабільних retrieval + decision + side-effect metrics.