Технічний контекст: що саме Anthropic випустили в прод
Я уважно розглянув Programmatic Tool Calling (PTC) в документації Anthropic, і мені сподобалося головне: вони перестали змушувати модель грати в «пінг-понг», випускаючи JSON на кожен виклик інструменту. Тепер Claude може написати і виконати Python-код, всередині якого вже є цикли, умови, перетворення даних і обробка помилок.
PTC доступний у public beta разом із Claude Sonnet 4.6 та Opus 4.6 на Claude Developer Platform та через API. За цінами, які я бачу в релізі: Sonnet 4.6 — $3/$15 за мільйон токенів (вхід/вихід), Opus 4.6 — $5/$25.
Технічна «фішка» вмикається на рівні інструменту: ви позначаєте tool як придатний для code execution (наприклад, code_execution) і задаєте, хто може його викликати (наприклад, allowed_callers). В результаті Claude імпортує/викликає ваші tools прямо з Python, а в модель повертається підсумок, а не сирі 50KB таблиці.
Anthropic заявляє про економію до 98% токенів на багатоскладових сценаріях. Я вірю в порядок цифр: коли ви перестаєте «тягати» JSON-відповіді інструментів назад у контекст, вартість і затримка падають драматично.
Вплив на бізнес та автоматизацію: що змінюється в архітектурі
З PTC у мене змінюється стандартна AI-архітектура агентних рішень. Раніше в проді я майже завжди робив прошарок-оркестратор (у сервісі або workflow-движку), тому що «модель + JSON tool calls» погано переносить довгі ланцюжки: контекст розпухає, ретраї ламають логіку, а вартість стає непередбачуваною.
Тепер частину оркестрації можна легально і контрольовано винести у виконуваний код, який генерує Claude. Для ШІ автоматизації це означає стабільніші сценарії типу: «вивантаж дані → очисти → сагрегуй → перевір умови → запиши в ERP/CRM → сформуй звіт» без десятків кіл спілкування моделі з інструментами.
Виграють команди, які будують агентів навколо даних: фінанси, логістика, закупівлі, план-факт, support із глибокими інтеграціями. Програють ті, хто намагався «економити» на інженерії і покладався на магію промпту: PTC робить систему потужнішою, але вимагає дисципліни в інструментах, схемах доступу та спостережуваності.
З нашого досвіду в Nahornyi AI Lab, критичний момент — не сам виклик інструменту, а контракт даних та управління помилками. PTC нарешті дозволяє описувати retries, дедуплікацію, ліміти, backoff і валідацію не в «міркуваннях моделі», а в явному коді, який простіше тестувати і версіонувати.
Стратегічний розбір: чому це тягне ринок до «code-first» агентів
Я бачу в PTC не просто нову фічу Claude, а зсув парадигми: агент стає не чат-ботом, який час від часу викликає функції, а генератором виконуваних «мікро-пайплайнів». Це ближче до того, як бізнес реально працює: багато умов, винятків, форматів і кривих даних.
У проектах впровадження ШІ зазвичай ми впираємося у два обмеження: вартість на токенах і непередбачуваність на edge cases. PTC б'є по обох. Сирі дані залишаються поза контекстом, а модель повертає компактний підсумок; при цьому розгалуження і цикли відбуваються в коді, а не в багаторазових JSON-обмінах.
Мій неочевидний прогноз: через 6–12 місяців «правильний» прод-агент буде оцінюватися не за промптом, а за якістю бібліотеки tools, політик виконання коду та спостережуваності. Тобто конкурентною перевагою стане архітектура ШІ-рішень: пісочниця виконання, контроль витоків, трасування викликів та суворі контракти входів/виходів.
Я б також не намагався вмикати PTC «всюди». Для простих single-call завдань старий tool use може бути швидшим за часом впровадження. Але як тільки з'являється таблиця на тисячі рядків, кілька API та умовна логіка — я у своїх рішеннях буду закладати PTC як базовий механізм оркестрації.
Цей розбір підготував Вадим Нагорний — провідний практик Nahornyi AI Lab з AI-архітектури, агентів та AI-автоматизації в реальному секторі. Якщо ви хочете зробити ШІ автоматизацію з Claude у проді (інтеграції з ERP/CRM, документообіг, фінконтроль, аналітика), я запрошую вас обговорити завдання: зберу цільову архітектуру, оціню ризики виконання коду та запропоную план впровадження під ваші KPI.