Ви запустили свого першого продакшн-агента — ШІ, який не просто відповідає на питання, а реально робить справи: ланцюжить 50–200 викликів інструментів (запитів до зовнішніх сервісів на кшталт Slack, Linear, GitHub), пише код, надсилає повідомлення, створює тікети. Клієнт залежить від результату. Життя прекрасне.

А потім клієнт отримує неправильну відповідь. Ваш агент написав не в той проєкт Linear, замерджив кривий PR, відправив DM у Slack генеральному директору замість джуніора. Вам треба з'ясувати чому — поки він не зробив це знову.

І ось ви тягнетесь до блискучих нових інструментів observability, які кожна велика платформа випустила у квітні 2026-го. 8 квітня Anthropic запустив Managed Agents із вбудованим трейсингом сесій та логами викликів інструментів. 10 квітня Zed випустив Agent Metrics — дашборди, що відстежують 2 мільйони сесій, 15,4 мільйона кроків, гістограми затримок для 536 різних агентів. 15 квітня OpenAI оновив свій Agents SDK з автотрейсингом, який записує кожен виклик інструменту, передачу між агентами та відповідь моделі — без жодного додаткового коду — плюс повна сумісність із OpenTelemetry (OpenTelemetry — це індустріальний стандарт збору даних про продуктивність, щось на кшталт універсальної розетки для моніторингових інструментів).

Кожен вендор вирішив ту саму задачу: покажи мені, що сталося. І зробили це добре. Відкриваєш трейси — спани (окремі записи кожної операції) для кожного виклику LLM, кожного виклику інструменту, кожного токена (шматка слова, який обробляє ШІ). Красиві водоспадні діаграми. Точні цифри затримок.

Але ось де все ламається. Трейс агента — це не трейс мікросервісу. Мікросервіси — маленькі незалежні програми, на яких тримаються більшість веб-додатків — детерміновані: один і той самий вхід, один і той самий вихід, той самий баг, відтворюваний фікс. Агенти недетерміновані: перезапустіть ту саму задачу — отримаєте інші рішення на кроці 47. Агент обрав шлях А, але ви не бачите, як виглядав шлях Б, і чому він обрав А, а не Б, маючи 80 000 токенів накопиченого контексту ("робоча пам'ять" ШІ — все, що він прочитав і згенерував до цього моменту).

Як написав Саймон Віллісон у своєму гайді з патернів агентної інженерії від 3 квітня: "Ми не можемо гарантувати, що агент діє сумлінно, або діагностувати проблеми, якщо його операції повністю непрозорі." А пост-мортем Sentry від 16 квітня точно описав типовий збій: кожен спан звітує status: ok, а на виході — повна маячня. Баг живе між агентами — один виклик інструменту тихцем псує вхідні дані для іншого агента через два кроки.

Дебажити неправильне рішення агента за його трейсом — це як дебажити людське рішення за її Google Calendar: ви бачите, на яких зустрічах вона була, але не що вона думала.

Ринковий костиль: LLM-as-judge — використання другої моделі ШІ для оцінки рішень першої. Braintrust (підняв $80M у лютому при оцінці $800M), trajectory evals від LangSmith та Arize Phoenix — всі прикручують evaluation до трейсів. Але кожен додає нову залежність, додаткову вартість токенів на кожну точку прийняття рішень, і — ось де найсмішніше — модель-суддя має ті самі архітектурні сліпі зони, що й агент, якого вона судить.

Практичний костиль на сьогодні: змушуйте свого агента генерувати структуроване обґрунтування на кожній точці розгалуження. Не просто запис виклику інструменту, а JSON з поясненням:

import json

def log_decision(step: int, options: list[str], chosen: str, reasoning: str):
    """Emit a searchable reasoning trail at every branch."""
    entry = {
        "step": step,
        "options_considered": options,
        "chosen_action": chosen,
        "reasoning": reasoning,
        "context_tokens_used": get_current_context_length(),
    }
    logger.info("agent_decision", extra=entry)
    return entry

# Inside your agent loop:
log_decision(
    step=47,
    options=["post to #general", "post to #engineering", "DM the assignee"],
    chosen="DM the assignee",
    reasoning="Ticket is labeled 'confidential', channel posting violates policy"
)

Так, це коштує додаткових токенів. Так, це сповільнює виконання. Але це єдиний спосіб побудувати пошуковий слід міркувань, який людина може проаудитувати після збою — бо самі трейси не скажуть вам, чому крок 47 пішов не туди.

Кожна платформа випустила "що сталося". Ніхто не випустив "чому цей шлях, а не інший". Перша компанія, яка побудує reasoning-native observability — не trace-native, а саме reasoning-native — отримає шар дебагінгу для кожного продакшн-агента, так само як Datadog отримав моніторинг для мікросервісів. А поки що ви читаєте календар свого агента і вгадуєте, що він думав.