Починайте з tool contracts, а не з prompt
До вибору моделі потрібно описати інструменти агента. Кожен tool має мати вузьку відповідальність, типізовані inputs, явні outputs і передбачувану поведінку при помилках. Наприклад, tool для створення клієнта не повинен тихо змінювати billing чи permissions.
Tool contracts версіонуються як API. Аргументи перевіряються на сервері, зовнішні помилки нормалізуються, timeouts і retries задаються явно, а кожен tool call логують. Prompt може спрямовувати поведінку, але authorization повинна жити поза моделлю.
Розділяйте read і write capabilities
Агент, який лише шукає документи, має інший ризик, ніж агент, який змінює CRM, відправляє гроші чи публікує контент. Це мають бути різні класи permissions. Read-only дії часто можна автоматизувати, а write-операції потребують додаткових policy checks, budgets або approval.
Сильний патерн — policy layer між моделлю і tool executor. Він знає користувача, tenant, стан workflow та рівень ризику й вирішує: дозволити дію, запросити підтвердження чи відхилити її.
Для machine decisions використовуйте structured outputs
Вільний текст зручний для пояснення людині, але слабкий як інтерфейс між системами. Production agent має повертати структурований JSON зі строгою schema, enums, обмеженнями й required fields.
Schema validation створює вимірювану межу між reasoning моделі та application logic. Некоректну відповідь можна retry, відправити у fallback або передати оператору.
Оцінюйте workflows, а не demo prompts
Кілька вдалих демо не доводять надійність агента. Потрібен evaluation set із реальних бізнес-задач, edge cases та відомих failure modes. Вимірюйте tool selection, точність arguments, policy violations, completion rate, latency та escalation rate.
Найкращі evals поєднують offline tests і production traces. Кожна суттєва помилка має перетворюватися на regression case.
Human-in-the-loop має бути явним
Людське підтвердження потрібне не всюди, а там, де помилка дорого коштує: гроші, видалення даних, зовнішні повідомлення, permissions, контрактна інформація. Низькоризиковий analysis можна залишати автоматичним.
Approval UI має показувати запропоновану дію, контекст і очікуваний результат. Користувач повинен мати можливість approve, edit або reject.
Проєктуйте на випадок відмови моделі
LLM можуть мати rate limit, timeout, refusal або нестабільність на окремих задачах. Provider abstraction, timeouts та deterministic fallback — частина production architecture.
Observability має фіксувати model, prompt version, token use, latency, tool calls, validation failures і final outcome. Без цього incident investigation перетворюється на здогадки.