Мовна модель пише вільно і часом помиляється впевнено. У чаті це коштує однієї поганої відповіді. В агенті з пам’яттю — більше: агент зберігає помилку, міркує з неї й завтра повторює. Пошук не може сказати, яка з двох суперечливих нотаток правильна, а друга модель у ролі судді лише передбачає правдоподібний вердикт. Ліки не нові. До глибокого навчання експертні системи, як-от MYCIN і XCON, тримали знання у вигляді правил, застосовували їх щоразу однаково й відповідали на «чому?» і «як?». Підвело їх одне: внесення знань, бо кожне правило вводили вручну. Саме це LLM уміють дуже добре. Нейросимвольний ШІ знову з’єднує дві половини. Доповідь проходить цей шлях на одному наскрізному прикладі: асистент, чия LLM «пам’ятає» зустріч у Берліні, тоді як у календарі та сама людина в цю годину в Лісабоні. Ми розберемо дедукцію, індукцію й абдукцію і те, чому LLM сильні саме в останній; міркування над графом знань із Prolog і Datalog; і те, чому логічне програмування вищого порядку (λProlog) добре пасує агентам: типи, що відкидають некоректний вивід LLM, відношення як значення, локальні припущення «а що як», правила про правила й доведення, які перевіряє мале ядро. Наприкінці — робочий агент, чия LLM пише λProlog за шістьма вартовими, і чесні цифри про те, що логічний шар ловить, а чого не може. Для інженерів ШІ та агентів, які знають Python і LLM. Знань логіки чи математики не потрібно.

AI-агент знає лише те, що ви йому показали, і не підкаже рішення, про існування якого не підозрюєте ви самі. А ще він забуває все між чатами. Доповідь пояснює, які знання потрібні людині, щоб агент працював на повну, і як побудувати для нього пам'ять: від локальних файлів до спільної пам'яті через MCP-сервер. Ви дізнаєтесь: — чому агент не пропонує очевидних рішень і як це виправити — патерн memory bank і готову структуру файлів, з якої можна почати — рівні пам'яті агента: чати, локальні файли, Obsidian, git, MCP-сервер пам'яті — практичні правила, як тримати пам'ять агента актуальною

Ми створили self-aware infrastructure: систему з пам’яттю, класифікаторами, моделями прийняття рішень у стилі Jev, оцінками та агентами, які здійснюють triage подій в інфраструктурі. Здебільшого агенти розгортаються або як обробники запитів без збереження стану, або як один спільний агент, що обслуговує всіх. Для автономних Triage агентів та командних експериментів нам потрібно було щось інше. Кожна команда або інженер отримує власного агента, що завжди увімкнений (always-on), - Spot. Він запам’ятовує поставлені завдання, продовжує працювати після того, як вони завершують сесію, і чекає на них, коли вони повертаються. Ви можете голосом попросити «RCA для кожної проблеми минулого тижня», закрити сесію і через кілька годин побачити, що робота виконана. У цій доповіді йдеться про те, як ми створили https://triageagent.dev Що отримають учасники: 1. З чого ми почали. Наше експериментальне середовище для масштабного запуску агентів, побудоване на kagent, agentgateway, ego та substrate. 2. Що ми отримали — «Triage Spots». Реальний приклад використання життєвого циклу агента, що завжди активний: один агент на користувача, який активується подіями, має власну пам’ять та квоту. 3. Чесний перелік наших помилок. Історія, що стоїть за цим кейсом: Замість відкриття запитів на платформі та отримання дозволу, ми запровадили для наших команд ізольоване середовище, щоб зменшити масштаб можливих наслідків від ненадійного або експериментального коду на спільних кластерах у великих масштабах. Цей підхід є конкретним, відкритим прикладом створення середовища для розробників на базі agent substrate, включаючи triageagent — переможця Національної премії Індії AI Gamechanger 2026.

Розробка ПЗ переходить від агентів, які допомагають писати код, до автономних систем, що беруть затверджену вимогу, пишуть код і самі перевіряють результат майже без нагляду людини, — software factories. Підхід новий, але OpenAI, Anthropic, Stripe, Uber та інші компанії вже публічно описали свої фабрики. У кожної — власний шлях, проте через усі ці історії проходять спільні принципи: що фабриці дозволено будувати, як вона доводить, що результат правильний, наскільки можна довіряти її агентам і як зробити, щоб вона окупалася. У доповіді я розбираю ці принципи й пояснюю, навіщо потрібен кожен, спираючись на публічні описи та на фабрики, які будую в Dev AI Consulting. Мірило успіху — фабрика, чиєму «готово» можна вірити.

Чому майбутнє автоматизації — не в кількості розробників, а в доступності AI-агентів Традиційна автоматизація вимагає часу, бюджету та залучення IT-команд. Але що, якщо кожен співробітник зможе самостійно автоматизувати власні процеси? Agentic Workforce змінює сам принцип організації роботи. Люди визначають цілі, агенти виконують задачі, а платформа забезпечує інструменти, доступи, безпеку та контроль. Розповім про наш досвід побудови та впровадження Agentic Workforce продукту в ентерпрайз організації, архітектуру агентної платформи, управління цифровими виконавцями та те, як ми бачимо трансформацію корпоративної автоматизації.

Нашою метою на 2026 рік було підвищити ефективність роботи команди на 15–20%... а ми досягли 30–50%. Цикл розробки програмного забезпечення (SDLC) з використанням ШІ перетворився на цикл, повністю заснований на ШІ, де люди працюють разом з агентами з чітким розподілом обов’язків: люди — за логіку та контроль, агенти — за рутинні завдання. Ми використовуємо підхід «human-in-the-loop» та експериментуємо з циклами агентів. Чи можна це розглядати як «фабрику програмного забезпечення на базі ШІ»? Давайте разом поміркуємо... Я продемонструю, як ми працюємо, на прикладі одного з наших найбільших рішень, що складається зі 152 проєктів із 2,5 млн рядків вихідного коду та 18,7 млн токенів для опису спільного контексту. Як ми це підтримуємо? Як ми долаємо обмеження розміру вікна контексту? Побачимося на події!

В епоху, коли AI-агенти стають основою робочих процесів, ми об’єднаємо всі дані ваших проєктів в одному місці та надамо агентам доступ до них. Обговоримо, які проблеми це допоможе вирішити, як правильно збирати й перевіряти дані та підтримувати їх в актуальному стані. А також покажемо, як такий підхід може змінити роботу вашої команди.

Чому з тими самими інструментами одні команди прискорюються, а інші тонуть у слопі? Розберемо типові антипатерни роботи з AI-агентами в розробці: від «згенеруй усе одразу» до сліпої довіри до результату. Покажу, до чого вони призводять на практиці і що робити замість цього.

Кожна нова хмара в компанії зазвичай означає ще один набір Terraform, ще одну інструкцію з деплою і ще один спосіб зробити все по-своєму. Витрати ростуть швидше, ніж кількість провайдерів. Platform engineering дозволяє розірвати цю залежність: golden path стає інтерфейсом, а конкретна хмара — реалізацією. Розробник описує, що йому потрібно — сервіс і production-база даних — а платформа сама вирішує, як це виглядає у гіперскейлері, а як у локального провайдера. У живому демо розробник створює новий сервіс через портал самообслуговування. Один шаблон, один Kubernetes-маніфест — і застосунок розгортається у двох хмарах одночасно. Однакова заявка на PostgreSQL в одній хмарі стає керованим сервісом бази даних, в іншій — базою під управлінням оператора в Kubernetes. Окремо — про межі підходу: IAM, сторедж і бекапи абстракція не приховує, і я покажу, чому це нормально. Після доповіді ви знатимете, як влаштований патерн «заявка → композиція» для баз даних у різних хмарах, з чого почати свій перший golden path без побудови власного PaaS, і які відмінності між хмарами варто показувати розробникам явно.

Розгортання та оптимізація LLM-інференсу в продакшні на GPU від L4 до 4xH200: вибір інференс-двигунів та конфігурацій, баланс між пропускною здатністю, затримкою та вартістю, а також як «вичавити» максимум із обладнання й уникнути типових помилок тюнінгу