На щотижневому подкасті Security Intelligence від IBM Technology команда аналітиків з кібербезпеки — ведучий Метт Казінські, Мішель Альварес, Остін Зайзел та Ерблінд Моріна — розбирає один із найбільш чутливих анонсів WWDC 2026: функцію Apple Intelligence, яка сама знаходить зламані чи слабкі паролі та змінює їх за користувача. Ідея звучить як мрія для всіх, хто роками відкладає «навести лад у паролях». Але кожен крок до автоматизації безпеки тут же відкриває нові вектори ризику.

Що саме пропонує Apple Intelligence

У центрі дискусії — нова можливість Apple Intelligence: система «може визначити, чи паролі користувача слабкі або скомпрометовані, а потім змінити їх за нього за допомогою agentic‑воркфлоу». Тобто йдеться не про пасивне попередження, а про активного агента, який отримує доступ до облікових записів, ініціює зміну облікових даних і проводить ротацію без прямої участі людини.

Концептуально це радикальний зсув. Безпека паролів завжди була «головним болем користувача»: придумати складний пароль, не повторювати його, вчасно змінити після інциденту. Нова модель переносить центр тяжіння на автоматизацію: «система може виявити компрометацію та миттєво ротувати ці облікові дані від імені користувача», знімаючи більшу частину «тертя» навколо гігієни паролів.

Зручність очевидна: якщо агенти справді зможуть оперативно реагувати на витоки, користувачам не доведеться відстежувати злами сервісів, темп змін паролів зросте, а час, коли зламаний пароль залишається чинним, скоротиться. Але разом із цим виникає базове питання: хто тепер реально контролює доступ до акаунтів — людина чи автоматизована система з «імпліцитною довірою»?

«Людина в контурі»: де пролягає межа прозорості

Для Мішель Альварес ключова умова прийнятності такої функції — присутність «людини в контурі». Вона прямо формулює, від чого залежала б її власна довіра до такого агента: «Чи є людина в контурі? Думаю, це передусім. Чи отримую я сповіщення? Чи є прозорість і чи маю я право вирішувати, змінювати пароль чи ні».

Розмова швидко виходить за межі суто технічного питання й переходить у площину користувацького досвіду та управління ризиком. Сценарій, якого всі хочуть уникнути, зрозумілий: AI‑агент вирішує, що пароль слабкий, змінює його, але користувач про це не знає — і опиняється заблокованим у власних акаунтах. Навіть якщо це результат не помилки, а, наприклад, атак на сам агент через prompt‑інʼєкції, наслідки для користувача залишаються однаково болісними.

Панель наголошує на двох принципах, без яких така функція ризикує стати джерелом хаосу:

По‑перше, обов’язкове інформування. Користувач повинен чітко знати, що саме зробив агент, коли, з якої причини та як отримати доступ назад.

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

Усе це ускладнюється ще й тим, що агентивний AI для масового користувача — відносно новий клас технологій. Як зазначає Альварес, навіть фахівці «вчаться агентовому AI, і це може бути переобтяжливим», не кажучи вже про споживачів, які просто бачать нову «зручну фічу» на презентації.

Зручність проти безпеки: новий рівень довіри до агентів

Остін Зайзел оцінює задум Apple як «доволі цікавий»: це спроба «змістити безпеку з дії, що ініціюється користувачем, до AI‑автоматизації». У його баченні головна перевага — зняття звичного «тертя» навколо гігієни паролів: користувачам не потрібно пам’ятати, коли що змінювати, слідкувати за новинами про витоки, перевіряти списки зламаних сервісів.

Втім, саме в цій зручності й ховається ризик. Щоб мати змогу рятувати користувача від зламаних паролів, агент повинен володіти широкими повноваженнями й зберігати високочутливі дані. «У вас з’являється AI‑агент, який має прямий доступ до цих облікових даних… і діє на високому рівні з певною імпліцитною довірою», підкреслює Зайзел.

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

Фактично такий агент перетворюється на критично важливу інфраструктурну точку — і для захисту, і для зловмисника.

Threat intel як «топливо» агента: чи можна довіряти сигналам про витік

Ерблінд Моріна, як фахівець з інцидент‑респонсу, одразу заглядає «під капот»: якщо Apple Intelligence обіцяє змінювати «скомпрометовані» паролі, то звідки береться саме знання про компрометацію?

У більшості випадків це виявлення витоків паролів у різних джерелах — від інфостілерів до форумів у даркнеті. Моріна ставить пряме запитання: «Як компанія дізнається, що ваш пароль скомпрометований, з такою впевненістю, щоб автоматично все скидати?»

Він наголошує, що робота з threat intelligence у цій сфері «дуже орієнтована на хибні спрацювання». Значна частина даних у темному сегменті мережі — «сміття, фейкові витоки, нісенітниця». Якщо механізм ухвалення рішень агентом спирається на шумні джерела з низькою якістю, то ризик некоректних дій зростає багаторазово.

Моріна пропонує умовну «шкалу впевненості» як ключ до більш виваженої автоматизації. Якщо «впевненість у витоку облікових даних дуже висока, бо це стілер, який на одному з форумів викладає саме ваші креденшели, тоді це хороший крок — скинути пароль». У всіх інших випадках — «дуже залежить» від контексту й критеріїв.

Тут знову постає питання «людини в контурі», але вже на рівні threat intel: хтось має оцінювати достовірність джерел і типи сигналів. На панелі прямо лунає сумнів, чи «агент уже здатен робити це самостійно, без аналітика, який сидить і відсіює, що важливо, а що ні».

Коли сам AI‑агент стає новою ціллю

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

Якщо інструмент, що має прямий доступ до облікових даних, стає підконтрольним зловмиснику, спектр наслідків різко розширюється: від масового захоплення акаунтів до прихованої, поступової підміни облікових записів і каналів доступу. «Ризик може перейти від незначного, але дратівливого, до значного, якщо сам AI‑інструмент буде скомпрометований», резюмує вона.

У цьому сенсі впровадження агентів для керування паролями створює «новий шар ризику», про який не можна забувати, захоплюючись можливістю нарешті автоматизувати нудну частину безпеки. Кожна нова технологічна сутність у системі неминуче стає потенційним вектором атаки — і тут агенти не виняток.

Чи потрібен для цього взагалі AI, а не «звичайна» автоматизація

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

«Якщо йдеться тільки про сильний пароль, про розрахунок його складності — чи справді потрібен AI? Можливо, це просто проста автоматизація», міркує він. Там, де сигнал про компрометацію чіткий (наприклад, достовірний витік у темній мережі), можна застосовувати відносно прямолінійні скрипти: відключити акаунт, вимагати ручної верифікації, не вдаючись до повністю автономних рішень.

Такий підхід, на його думку, зменшує ризик надмірної реакції на фейкові або низькоякісні дані — ситуацію, коли «фейкова новина в даркнеті призводить до того, що мені відключають пароль». Він прямо каже, що це «дуже ризикований крок, якому він поки не довіряє».

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

Чи можуть агенти стати частиною вирішення «вічної проблеми» гігієни паролів

Наприкінці розмови Казінські повертає дискусію до базового питання: чи можуть такі агенти реально допомогти з хронічною проблемою слабких і повторюваних паролів, з якою індустрія бореться роками?

Зайзел бачить у цьому потенціал: він розглядає AI «як доповнення до роботи людей, а не заміну». У ролі «асистента» агент може нагадувати про зміни, підказувати слабкі місця, пропонувати варіанти ротації — і цим зменшувати імовірність того, що користувач просто ігноруватиме рекомендації.

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

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

Її основний меседж — відсутність універсального рецепта. Кожній компанії доведеться самостійно «перевіряти інструменти й технології, які вони впроваджують у своє середовище, бо не існує одного розміру, що пасує всім».

Баланс, який ще належить знайти

Дискусія навколо Apple Intelligence показує розлом, у якому зараз живе кібербезпека. З одного боку, є реальна, давно усвідомлена потреба зняти з користувачів частину рутинного навантаження та нарешті підвищити базовий рівень гігієни паролів. З іншого — кожен крок до більшої автоматизації вимагає ще більш продуманих запобіжників, прозорості та зрозумілих меж для AI‑агентів.

Чи варто дозволяти агентам змінювати наші паролі? Висновок експертів умовний, але чіткий: можливо — за умови, що людина залишається в контурі, рівень довіри до сигналів про витік високий, а самі агенти побудовані й захищені так, ніби це нова критична інфраструктура. Поки ці умови не виконані, зручність не повинна затуляти собою ціну потенційної помилки.

Джерело: Security Intelligence — AI agents can manage your passwords. Should we let them?

У новому повному курсі на каналі Tech With Tim автор покроково розбирає, як будувати AI‑агентів у Python на базі фреймворка Agentspan — від першого локального запуску до сценаріїв близьких до реального продакшну. Окрема частина курсу присвячена саме розгортанню: як вийти за межі локального сервера, підʼєднати Postgres, запустити Agentspan через Docker Compose і безпечно підключати Python‑воркери до віддаленого оркестратора.

Цей матеріал концентрується саме на цій фінальній частині — переході від «запустив на ноуті» до інфраструктури, яку можна ставити в продакшн.

Локальний сервер Agentspan: SQLite і швидкий старт

Для розробки Agentspan пропонує максимально просту модель запуску. Достатньо встановити Python‑пакет та сервер, експортувати ключ LLM‑провайдера, запустити команду agentspan server start (у прикладі — через uv run), і веб‑дашборд стає доступним на http://localhost:6767/api.

У такому режимі вся інформація про виконання агентів — стейт, історія кроків, результати викликів інструментів — зберігається в локальній SQLite‑базі:

«If you just want to use local development like we were doing, right, you just run the AgentSpan server and that’s it… it will just store in a local SQLite database.»

Для перших прототипів цього більш ніж достатньо. Розробник може:

• запускати воркер‑код локально;
• дивитися історію виконань у веб‑інтерфейсі;
• користуватися всіма можливостями платформи — черги, ретраї, human‑in‑the‑loop, multi‑agent, guardrails тощо.

Однак така конфігурація очевидно не розрахована на продакшн‑навантаження й масштабування.

Чому для продакшну потрібні Postgres і Docker Compose

Коли постає питання реального деплойменту, архітектурні вимоги змінюються. Потрібне стійкіше сховище стану, передбачуваний спосіб запуску серверу, можливість масштабувати його в межах інфраструктури.

У курсі це формулюється прямо:

«However, if you want to go to a deployed environment, you probably want to use Postgres SQL and some kind of Docker Compose to be running this for you.»

SQLite на одному хості зручна для локального деву, але:

• погано підходить під високий паралелізм;
• важко вбудовується в стандартні продакшн‑патерни бекенд‑сховищ;
• не масштабується горизонтально.

Postgres натомість дає стандартну, керовану й добре відому точку зберігання стану, яку можна розмістити на окремому сервері чи кластері. Docker Compose забезпечує відтворюваний запуск самого Agentspan‑сервера, який можна легко обгорнути в CI/CD.

GitHub‑репозиторій Agentspan і директорія deployment/docker‑compose

Для виходу за межі локального запуску пропонується не вигадувати власні YAML‑файли з нуля, а скористатися готовими артефактами з офіційного репозиторію:

«In order to do that, you can just pull the GitHub repo that AgentSpan has… you can go into the deployment and then docker‑compose directory.»

У структуру репозиторію входить директорія deployment/docker-compose, де зібрано все необхідне для старту сервера в контейнерному середовищі. Звідси й починається шлях до продакшн‑конфігурації.

Сам репозиторій, за словами автора, містить:

• готовий Docker Compose‑файл для Agentspan‑сервера;
• приклад конфігурації змінних середовища;
• інструкції, як запускати сервер із зовнішньою Postgres‑базою.

Це дозволяє перевести розгортання в режим «склонувати і адаптувати», замість писати весь стек із нуля.

Налаштування .env.sample: Postgres, API‑ключі й інші секрети

Ключовою частиною цієї docker‑композиції є .env.sample. Саме тут зосереджена конфігурація сервера — від доступу до бази до провайдерських ключів для LLM і додаткових сервісів.

«From docker‑compose you can just adjust the variables here inside of the .env.sample… you can put any environment variables or like API keys that you want to have. You can put the Postgres database that you want to connect to.»

Файл .env.sample виступає шаблоном:

1. його копіюють у .env;
2. заповнюють власними значеннями;
3. Docker Compose підхоплює ці змінні при старті.

У цьому файлі задаються, зокрема:

• URL для підключення до Postgres, який сервер використовуватиме замість локальної SQLite;
• ключі для LLM‑постачальників;
• будь‑які додаткові API‑ключі, що має знати оркестратор (наприклад, для веб‑інструментів чи вбудованих сервісів).

Цей підхід узгоджується з тим, як Agentspan працює з credentials загалом: частина секретів може зберігатися безпосередньо на сервері й підтягуватися воркерами лише під час виклику конкретного інструмента.

Виносимо оркестратор: як Python‑воркери підʼєднуються до віддаленого сервера

Після налаштування Docker Compose і Postgres наступний крок — повʼязати з цим сервером воркер‑код, який запускається вже не обовʼязково на тому ж хості. Логіка при цьому залишається в Python‑процесах, а Agentspan‑сервер бере на себе стейт, черги, human‑in‑the‑loop та інше.

Схема підключення гранично проста:

«As soon as this server is deployed, all you need to do is just point your workers to this server… all you have to do is just say, “Hey, here’s the URL where this is running.”»

У практичному коді це виглядає як налаштування змінної AGENTSPAN_SERVER_URL (у курсі це робиться через .env):

• для локальної розробки значенням є http://localhost:6767/api;
• для продакшну — вже зовнішній URL або внутрішнє імʼя сервісу в кластері.

Python‑воркер, який створює та запускає агентів, просто читає цю змінну. Решту — зʼєднання, реєстрація виконань, збереження стану, відновлення після крашу — бере на себе сервер.

Ключовий момент: воркери можуть жити на окремих машинах, масштабуватись незалежно від оркестратора, а сервер стає єдиною точкою координування та спостереження за всіма агентами.

Базова безпека: OAuth‑ключі між воркером і сервером

У публічній або навіть внутрішній інфраструктурі недостатньо просто відкрити HTTP‑ендпойнт Agentspan‑сервера й довіритися тому, що ним ніхто сторонній не скористається. Фреймворк дозволяє ввести базовий рівень автентифікації за допомогою OAuth‑секретів.

«You can also set an OAuth key, you can set an OAuth secret, and then you can also just configure those directly from code… so now if someone wants to connect to it, they do need to pass those values from their worker.»

Ідеться про два параметри:

• OAuth key;
• OAuth secret.

Вони налаштовуються на стороні сервера (у тій же Docker/.env‑конфігурації чи через параметри запуску), а у воркер‑коді додаються до конфігурації підключення. У результаті:

• будь‑який Python‑воркер, який намагається спілкуватися з оркестратором, має передати коректні значення;
• без них запити відхиляються, що захищає сервер від випадкових або шкідливих підключень.

Такий механізм особливо важливий, коли сервер Agentspan розгорнутий у мережевому сегменті, доступному кільком командам чи сервісам, або має публічний вхідний URL.

Самохостинг та масштабування: «просто розгорнути сервер і вказати на нього воркери»

Вся ця модель розгортання задумана як самохостинг — із власним сервером, власною базою й керуванням усією інфраструктурою з боку команди, що розробляє агентів.

Фінальне резюме звучить так:

«You also can obviously self‑host this as it says right here… it’s just a matter of essentially deploying the server and then once the server is deployed pointing your workers towards it and then adding that basic OAuth… so that not anyone can connect to the worker.»

Ланцюжок дій у підсумку виглядає лінійно:

1. Розгорнути Agentspan‑сервер (за допомогою Docker Compose з репозиторію).
2. Підʼєднати його до Postgres через змінні середовища.
3. Налаштувати OAuth‑ключ і secret.
4. У воркер‑коді:
5. вказати AGENTSPAN_SERVER_URL на новий сервер;
6. передавати OAuth‑дані при підключенні.

Після цього всі фічі, які в курсі демонструвалися локально — durable execution з можливістю підʼєднатися до наявного execution_id, human‑in‑the‑loop, багатокрокові пайплайни, логування кроків агентів, — починають працювати поверх уже продакшн‑орієнтованого середовища з Postgres та контейнеризованим сервером.

Висновок

Agentspan у курсі подається не як ще один «дев‑тул для красивих демо», а як оркестратор, який із самого початку орієнтований на продакшн. Локальний запуск з SQLite зручний, щоб швидко зібрати агента й побачити всі його кроки в дашборді. Але перехід до реального деплойменту будується за прозорою схемою: Postgres як бекенд‑сховище, Docker Compose як спосіб запуску сервера, OAuth як мінімум для контролю доступу, віддалені воркери, які просто «вказують» на новий URL.

Це дозволяє командам зберегти знайому Python‑розробку агентів, але винести стейт і оркестрацію в окремий, керований шар, який можна масштабувати, моніторити й відновлювати після збоїв.

Джерело

Build 3 PRODUCTION AI Agents in Python – Full Course (Agentspan)

У великому практичному курсі на каналі Tech With Tim автор розбирає, як будувати AI‑агентів на Python, які реально витримують продакшн‑навантаження. Один з ключових акцентів — «durable execution»: здатність агента пережити краш, довгі простої та повернення людини в процес, не втрачаючи зроблену роботу. Саме ці можливості Agentspan стають визначальними, коли агент працює не секунди, а десятки хвилин чи години.

Довгі workflow як норма, а не виняток

Вихідна постановка задачі доволі прагматична: агентам у реальному світі часто не вистачає кількох секунд інференсу. Вони оперують складними бізнес‑процесами, зовнішніми API, очікуванням відповіді від користувача й можуть «висіти» дуже довго.

Формула тут прозора: якщо агенти працюють 20, 30 або навіть 2 години, інфраструктура має це витримувати. Відмова процесу на 80‑й хвилині без можливості відновлення — це не просто незручність, а прямі втрати: від вартості LLM‑запитів до зірваних SLA.

Саме тому в Agentspan від самого початку закладена ідея, що довготривалі задачі — це не крайовий кейс. Серверна частина платформи спроєктована так, щоб завдання могло виконуватися «скільки потрібно», а стан виконання при цьому не прив’язувався до життєвого циклу окремого воркера.

Сервер як «чорний ящик» стану

Архітектура Agentspan будується навколо серверу‑оркестратора і зовнішніх Python‑воркерів. Воркери запускають код агентів, але стан усіх виконань зберігається централізовано.

Цей сервер — бекенд‑інфраструктура, проти якої запускаються агенти. Вона відстежує історію, кроки, виклики інструментів, токени, причини зупинки. Головне ж — утримує повний стан виконання в базі. Якщо відбувається краш, можна відновитися саме тому, що весь state живе на сервері, а не всередині процесу, який упав.

Наслідок для розробника очевидний: завдання може працювати стільки, скільки йому потрібно. Воркери можна перезапускати, мігрувати, оновлювати — при цьому сам execution продовжиться з того місця, де обірвався.

Демонстрація: агент «впав», а workflow живе далі

Щоб показати, як виглядає durable execution у дії, в курсі зібрано невеликий демо‑приклад. Він максимально простий за логікою, але добре розкриває ключову ідею.

Створюється агент із єдиним інструментом — повільним кроком slow_step, який займає приблизно три секунди. Інструкція для моделі: виконати 10‑кроковий workflow, послідовно викликаючи slow_step для кожного кроку. У сумі це тривала задача, яка спеціально «гальмує», щоб було зручно моделювати збої.

Скрипт має два режими — start і resume. У режимі start агент запускається звичайним чином: через runtime створюється handle, який стрімиться в термінал, де видно всі події виконання, поки процес не закінчиться.

На сервері при цьому з’являється новий execution: у веб‑інтерфейсі видно, як агент переходить від кроку до кроку. Наприклад, у якийсь момент видно, що він дійшов до кроку 3 або 4 й чекає завершення slow_step.

У цей момент воркер просто насильно «вбивається» — процес зупиняється. У терміналі все обірвалося, але в дашборді Agentspan execution усе ще позначений як «running». Лог показує, що агент дістався четвертого кроку й «завис» на повільному інструменті; подальшого прогресу немає, адже ніхто не виконує код.

Суть проблеми очевидна: як не запускати все з нуля, а продовжити з того кроку, де виконання обірвалося?

execution_id як якір відновлення

Відповідь — у механізмі execution_id. Під час старту агента Agentspan друкує в логах ідентифікатор поточного виконання. Він також відображається в інтерфейсі сервера для кожного запуску.

Якщо цей execution_id зберегти, можна під’єднатися до вже існуючого виконання замість створювати нове. У демо‑скрипті саме так і відбувається: після крашу розробник копіює execution_id з логів та вставляє його в код у гілку resume.

У режимі resume замість start_… використовується інший шлях: спочатку запускається agent runtime, але далі handle отримується не шляхом запуску нового execution, а через під’єднання до попереднього — за тим самим execution_id.

З цього моменту відпрацьовує головна властивість durable execution: оскільки весь стан зберігається на сервері Agentspan, при реконекті воркер повертається в той самий контекст. При наступному запуску скрипта він «підхоплює» існуюче виконання і продовжує обробку — наприклад, переходить до кроку 5, 6, 7, доки не завершить усі 10 кроків.

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

Як це виглядає в платформних сценаріях

Демо‑скрипт показує базову механіку, але в розмові окремо підкреслюється, що це напряму масштабується на реальні платформи.

Якщо писати власне рішення поверх Agentspan, можна просто зберігати всі execution_id десь у своїй базі або бекенді. Якщо будь-який із них переходить у стан помилки чи «зависання» через падіння воркера, достатньо:

1. перезапустити воркер (або підняти новий),
2. замість запуску нової задачі під’єднатися до існуючої за відомим execution_id,
3. продовжити виконання, коли воркер знову онлайн.

Це особливо важливо, тому що в продакшені падіння процесів — радше норма, ніж виняток. Воркери можуть оновлюватися, рестартуватися через деплой, гинути через мережеві чи інфраструктурні збої. Без durable execution кожне таке перезавантаження означало б необхідність перезапуску довгих задач з нуля, повторних LLM‑запитів, повторних викликів зовнішніх API та очікувань.

Коли ж стан живе окремо від воркера, ці накладні витрати зникають. Платформа може спокійно масштабувати й перезапускати воркери, не боячись, що це «зламає» ланцюжок дій агента.

Тестування агентів без LLM: швидкість і безпека змін

Durability — не єдина продакшн‑орієнтована фіча, яку підкреслюють у курсі. Окремий блок присвячений тому, як тестувати агентів Agentspan без реальних LLM‑запитів.

Підхід базується на тому, що в Agentspan можна емулювати події всередині виконання агента, не звертаючись до моделі. Це дозволяє перевірити:

• чи коректно налаштовано модель та їй передається правильний model‑ідентифікатор;
• чи не конфліктує Pydantic‑response‑модель з тим, що очікує агент;
• чи коректно описані та підключені tools, включно з їхніми аргументами й очікуваними результатами;
• чи логіка обробки подій (tool call, tool result, done) поводиться так, як задумано.

У прикладі береться support‑агент із другого блоку курсу, який використовує structured output через Pydantic‑модель SupportResponse. Тестовий файл описує сценарій: агент має, наприклад, знайти інформацію про політику повернень. Для цього готується:

• змокана подія tool‑call до search_knowledge_base з певним запитом;
• змоканий результат цього tool‑виклику з шаблонною відповіддю;
• подія завершення виконання.

Далі вказується очікуваний результат для SupportResponse — з певним stage, прапорцем successful і фрагментом тексту в message. Через expect‑перевірки тест гарантує, що:

• агент завершився в статусі completed;
• у вихідному повідомленні є слово refund (або інший очікуваний фрагмент);
• під час виконання дійсно використовувався потрібний інструмент search_knowledge_base.

Коли умови виконані — тест проходить миттєво, без єдиного звернення до LLM. Якщо ж змінити очікування, наприклад замінити refund на refunded, тест одразу падає з чітким assertion‑error, вказуючи, що поведінка агента не відповідає очікуванню.

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

Чому це важливо для реального продакшену

Сукупність durable execution і можливостей для тестування без LLM формує ту «надійність за замовчуванням», якої бракує більшості іграшкових агентних демо.

З одного боку, довгі workflow перестають бути ризиком: якщо агент працює десятки хвилин чи годин, падіння воркера не обнуляє прогрес. Execution зберігається на сервері, а перезапуск воркера — лише технічна деталь.

З іншого боку, зміни в логіці агента перестають бути «темним лісом». Їх можна швидко проганяти через змокані сценарії, не обпалюючись на вартості LLM‑запитів і не чекаючи хвилинами відповіді моделі.

У результаті Agentspan виступає не просто як черговий агентний фреймворк, а як інфраструктурний шар, який вирішує типові продакшн‑болі: краші, довгі простої, залежність від зовнішніх моделей і потребу в швидкому, передбачуваному тестуванні. Саме ці риси й роблять durable execution центральною ідеєю, коли йдеться про запуск AI‑агентів у реальних продуктах, а не лише у вікні термінала.

Джерело

Build 3 PRODUCTION AI Agents in Python – Full Course (Agentspan)

Python‑розробник і автор каналу Tech With Tim у великому курсі про production‑агентів показує третій, найскладніший приклад — мультиагентний оркестратор на базі Agentspan. Це вже не «чатик з моделлю», а дослідницька фабрика з низкою спеціалізованих агентів, які взаємодіють між собою через різні стратегії — від послідовної до паралельної та вкладеної (nested). У центрі прикладу — реалістичний пайплайн для аналітичних звітів, який спирається на веб‑скрейпінг через Firecrawl.

Дослідницька фабрика: дослідник, райтер, редактор і команда аналітиків

Третій агент у курсі визначений як «multi‑agent orchestrator where we actually have multiple AI agents running at the same time to achieve a longer running task». Ідея проста: замість одного «універсального» асистента запускається кілька вузьких агентів, кожен зі своїм набором інструкцій і роллю в процесі.

У прикладі формується повноцінна дослідницька команда:

• researcher agent — відповідає за первинний збір інформації;
• writer agent — формує чернетку тексту на основі зібраних даних;
• editor agent — редагує й полірує текст;
• market analyst, risk analyst, financial analyst — три профільні аналітики;
• analysis team — надбудова, що об’єднує трьох аналітиків в окрему мультиагентну «команду».

Такий склад потрібен не заради ефектного демо, а щоб показати, як в Agentspan розбивати складний workflow на логічні ролі. У реальному запуску автор пропонує сценарії на кшталт: «I’m going to tell it hey I want to do research on Tech With Tim… and the strategy I want to use for the research is sequential», після чого вся зв’язка агентів збирає інформацію та видає готовий дослідницький репорт.

Кожен агент у цій схемі — звичайний Agentspan‑agent із власними інструкціями. Наприклад, дослідник отримує доступ до інструментів для пошуку і скрейпінгу, тоді як редактор працює переважно з текстом. Над ними стоїть оркестратор, який керує порядком запуску та обміном результатами.

Багато стратегій для багатьох агентів: handoff, sequential, parallel і не тільки

Базова можливість, яку демонструє цей блок курсу, — підтримка в Agentspan різних multi‑agent стратегій: «AgentSpan supports these multi‑agent strategies… first is handoff… then you have sequential… then we have parallel… then we have router… we have swarm… round robin, random and manual.»

Handoff використовується як дефолтна модель, коли «ln chooses which sub agent to handle the request». По суті, один «верхній» агент має доступ до інших як до підагентів, і LLM вирішує, до кого передати конкретний запит. У коді це виглядає як агент із переліком інших агентів і стратегією handoff. Далі можна «чатися» з цим оркестратором, а він у фоні делегує задачі.

Sequential — це класичний конвеєр: «we always run the agents in a linear path… we run them one by one and then we take the result of one agent and we pass it to the other». У документації це ілюструється прикладом із трьома агентами — researcher, writer, editor — які викликаються один за одним. Результат дослідника стає вхідними даними для райтера, результат райтера — для редактора.

Parallel, навпаки, «allows us to run these all concurrently. This means that I can run all three agents at the exact same time at scale. So I don’t need to wait for one response before I get the next.» Замість чекати, поки кожен агент послідовно завершить свою частину роботи, Agentspan запускає їх одночасно, а потім збирає результати.

Окрім цих трьох, у фреймворку є й інші моделі:

• router — окремий агент‑«класифікатор» маршрутизує запити до потрібного підагента;
• swarm — режим «рою» з багатьма можливими переходами;
• round robin, random, manual — різні підходи до того, як розподіляти задачі між агентами.

Але в прикладі з дослідницькою фабрикою фокус робиться саме на трьох ключових: послідовному, паралельному та їхній комбінації у вигляді nested‑пайплайнів.

Parallel‑команда аналітиків: analysis_team як окремий вузол

Щоб показати перевагу паралельного режиму, у коді формують спеціальний мультиагентний блок: «I then create an analysis_team… and this analysis team, I want to run in parallel where I say, hey, for the market_analyst, the risk_analyst, and the financial_analyst… we want to run those at the exact same time.»

Analysis_team — це фактично оркестратор усередині оркестратора. Він тримає три аналітичні агенти й запускає їх у стратегії parallel. Ключова перевага така: замість чекати, поки кожен аналітик по черзі підготує свій шматок розбору, система одночасно запускає ринковий, ризиковий і фінансовий аналіз, а потім зводить результати.

У веб‑дашборді Agentspan це виглядає як один execution із кількома дочірніми агентами: «you can see that this is running. We actually have three agents running… analysis_team, financial, risk, and market». Після завершення зʼявляється повідомлення «the report was saved», а відкривши файл звіту, можна побачити повний текст із трьома різними точками зору.

Такий блок можна використовувати як будівельний елемент для складніших сценаріїв: аналітика в паралелі, а генерація та редагування тексту вже в послідовному режимі.

Nested‑пайплайн: спершу паралельна аналітика, потім дослідження і текст

Найцікавіший момент прикладу — nested‑стратегія, де поєднуються паралель і послідовність. «For my nested_pipeline this is where I take my analysis team which I run in parallel and then after that… I write the researcher, writer and editor. So I run this whole thing sequentially but this first step runs these three agents in parallel.»

Nested_pipeline — це конвеєр із двох великих етапів.

Спочатку запускається analysis_team у режимі parallel. Три аналітичні агенти одночасно оцінюють тему (в одному з прикладів це «Nvidia stock»), формують свої висновки й повертають їх як узагальнений проміжний результат.

Далі в хід ідуть три інші агенти — researcher, writer, editor — але вже в режимі sequential. Вони виконують класичний маршрут: дослідження, написання, редагування. У вхід досліднику передається те, що напрацювала команда аналітиків, далі цей результат підхоплює райтер, потім — редактор.

У дашборді цей nested‑пайплайн виглядає як єдиний execution із кількома шарами агентів: «we now have a bunch of agents running, right? So we have the analysis team, researcher, writer, editor, the analyst team, market risk, financial, and these are going to run sequentially.» Спочатку видно паралельний блок аналізу, потім — покрокове проходження дослідника, райтера й редактора.

У фіналі код зберігає звіт у вигляді markdown‑файлу в окремій директорії. Для прикладу з Nvidia у файлі зʼявляється «full markdown report about Nvidia stock analysis with the different sources», а посилання ведуть на реальні сторінки, які були використані в дослідженні.

Firecrawl як інструмент для веб‑досліджень

Щоб мультиагентна система могла працювати не в ізоляції, їй потрібен інструмент виходу в зовнішній світ. У прикладі на цю роль обрано Firecrawl: «I’m using Firecrawl to just search the web for a bunch of pages on whatever topic we’re going to look up… this will allow you to do a ton of scraping and searching of the web more effectively than with like a default search.»

У коді це реалізовано двома інструментами‑функціями:

• search_web (у поясненні його називають саме так) — використовує Firecrawl для пошуку релевантних сторінок за темою;
• fetch_page — отримує вміст конкретної сторінки й віддає агенту повний текст.

Ці інструменти позначаються як tools в Agentspan і підключаються до researcher agent. Решта агентів працюють уже з результатами пошуку, а не напряму з веб‑ом.

Важливий момент — робота з credential‑ами. Для Firecrawl використовується API‑ключ, який не зберігається в коді. Натомість у сигнатурі інструмента зазначається, що йому потрібні credentials, а всередині функції значення підтягується з os.environ. Ключ задається через CLI Agentspan і потім зберігається на сервері; при виклику tool‑а сервер тимчасово передає його воркеру.

Ця модель дозволяє не «зашивати» секрети в код і не тримати їх постійно в середовищі виконання, а підвантажувати тільки тоді, коли цього справді потребує інструмент.

Реальне виконання: від запуску пайплайна до збереженого звіту

У прикладі з nested‑режимом користувач запускає скрипт із режимом nested і темою «Nvidia stock». Далі все виглядає як типовий production‑workflow:

1. Agentspan створює execution та піднімає analysis_team у режимі паралелі.
2. Три аналітичні агенти викликають Firecrawl‑інструменти, отримують сторінки, дістають текст і будують власні фрагменти аналізу.
3. Після завершення paralell‑блоку їхні результати об’єднуються й передаються в researcher agent.
4. Дослідник продовжує роботу з веб‑даними, ще раз викликає Firecrawl, збирає додатковий контент і формує більш цілісну картину.
5. Writer agent перетворює агреговані дані на зв’язний текстовий звіт.
6. Editor agent редагує й полірує текст.
7. Пайплайн завершується, а допоміжні функції в коді зберігають фінальний звіт у markdown‑файлі з людиночитабельним slug‑іменем у директорії reports.

Автор окремо звертає увагу на те, як це відображається в UI: у вкладці agents видно, які саме агенти працюють просто зараз, які вже завершили роботу і як передаються результати між ними. Це важливо не лише для дебагу, а й для розуміння, що саме відбувається всередині багатокрокового процесу.

Висновки: мультиагентні стратегії як основа складних AI‑workflow

Приклад із «multi‑agent researcher» у курсі наочно показує одну річ: як тільки задачі виходять за межі простого питання‑відповіді, одного LLM‑виклику стає замало. Потрібні ролі, пайплайни, різні стратегії виконання й чітке розділення на етапи: паралельні й послідовні.

Agentspan пропонує для цього готову модель:

• окремі агенти з інструкціями та інструментами;
• гнучкі стратегії оркестрації — від handoff до parallel і nested;
• інтеграцію з зовнішніми інструментами на кшталт Firecrawl;
• прозоре логування й візуалізацію виконання в дашборді.

Для команд, які будують складні workflow поверх LLM, мультиагентний підхід із таким набором стратегій дає змогу переходити від «демо‑бота» до багатоступеневих дослідницьких систем, що реально можуть працювати в продакшені.

Джерело

Build 3 PRODUCTION AI Agents in Python – Full Course (Agentspan)

У новому повному курсі на YouTube розробник і автор каналу Tech With Tim показує, як будувати production‑готові AI‑агенти в Python на базі фреймворку Agentspan. Один із найцікавіших прикладів — сапорт‑агент, що працює за RAG‑логікою, вміє шукати по базі знань і замовленнях, видає структурований Pydantic‑вивід, вимагає людського погодження перед рефандом і блокує prompt‑інʼєкції через guardrails. Саме цей агент вартий окремого розгляду як прототип реального AI‑сапорту.

Від «майже RAG» до реального сапорт‑сценарію

Другий агент у курсі позиціонується як «kind of a RAG‑based agent where we’re going to be able to look up some info in something like a database or documentation or whatever we have». Автор одразу застерігає: це не повний RAG зі векторними індексами — але логіка та інтерфейси максимально наближені до реального сценарію.

Замінником векторного пошуку виступають прості Python‑інструменти:

• один шукає по «документації» — мок‑базі знань зі статтями підтримки,
• інший звертається до мок‑бази замовлень,
• третій відповідає за запуск рефанду.

На цьому шарі інструментів будується повноцінний сапорт‑флоу: агент спершу шукає відповідь у знаннях, за потреби дістає дані по замовленню, а коли справа доходить до повернення коштів — зупиняється й чекає на схвалення людини.

Важлива деталь: цей агент не просто генерує «гарний текст». Він повертає жорстко структуровану відповідь через Pydantic‑модель, що робить його придатним для вбудовування в будь‑який бекенд чи сапорт‑панель.

Pydantic‑відповідь: коли LLM повертає не текст, а структуру

Щоб уникнути вільного текстового виводу та полегшити інтеграцію, агент налаштований на структурований output. Для цього оголошується Pydantic‑клас:

class SupportResponse(BaseModel):
    stage: str = Field(description="stage like answered, refunded, or rejected")
    successful: bool
    message: str

Автор підкреслює: «I want this AI model to actually give me output that has the following fields… a stage… successful boolean… and then we’re going to have a message».

Stage описує етап обробки звернення («answered», «refunded», «rejected» тощо), successful сигналізує, чи завершився запит успішно, message містить текст для користувача.

Сенс такого підходу в тому, що LLM більше не розглядається як «генератор тексту». Модель виводить дані, які гарантовано вкладаються в схему. Сам автор акцентує: «This is a super basic structured response, but if we wanted it to give us like a price or a number or a time… we’d just set that as a field and the model will automatically fill in these values».

Тобто будь‑які додаткові параметри — сума, дата, SLA, категорія тікету — легко перетворюються на окремі поля Pydantic‑моделі. Це важливо для бізнес‑логіки: система може не лише показати текст оператору, а й автоматично приймати рішення на основі полів stage і successful.

Пошук по базі знань: простий keyword‑інструмент замість складного RAG

Перша критична для сапорту можливість — пошук по knowledge base. Замість складної інфраструктури з векторами використовується максимально простий інструмент:

«The first tool is going to be one that can search our knowledge base… we’re just doing a quick keyword search… if any keyword of what the user typed in was in this… then we’re just going to return whatever the body or the content of this is».

Функція перебирає пари title, body у мок‑словнику документації, приводить запит до нижнього регістру і перевіряє, чи входить заголовок статті у запит. У разі збігу повертається body — текст статті підтримки. Якщо нічого не знайдено, повертається фраза на кшталт «no matching support articles found».

Це далеко не ідеальний пошук, але він чітко показує патерн:

1. Ззовні це оголошений tool Agentspan з чітким описом («search support docs»).
2. Усередині — будь‑яка логіка Python: від простого keyword‑пошуку до реального RAG‑провайдера.

LLM бачить цей інструмент як функцію, яку можна викликати. Якщо користувач запитує про «shipping», агент викликає tool пошуку в документації, отримує текст статті про доставку і вже на його основі формує структуровану SupportResponse.

Замовлення та помилки: lookup_order як базовий building block

Друга група функцій — робота з замовленнями. Тут використовується окремий інструмент:

«We’re going to have some tools related to looking up some orders… define lookup_order… return the mock_db[‘orders’].get(order_id)… or return a dict error: order not found.»

Логіка знову ж проста:

• на вхід — order_id (рядок),
• спроба знайти его в mock_db['orders'],
• у разі успіху — повертається словник із деталями замовлення (включно із сумою),
• у разі невдачі — словник {"error": "order not found"}.

Для LLM це ще один tool, яким можна скористатися після уточнення ID замовлення. Для розробника — очевидний шаблон: місце, де в реальній системі підключається справжня БД або API.

Цей інструмент критичний ще й тому, що він готує дані для наступного кроку — рефанду. Саме з відповіді lookup_order агент дістає суму, яку згодом пропонує повернути.

Рефанд із human‑in‑the‑loop: approval_required як запобіжник

Ключова частина сценарію підтримки — обробка повернень коштів. Автор одразу задає бізнес‑умову: «We’re going to have one tool that will allow the user to refund. However, before we call that tool, we are going to ask for a human in the loop approval because we don’t want to just automatically refund something unless the user actually allows that.»

Для цього оголошується третій tool — process_refund — із особливим параметром:

«This time we are going to say approval_required is equal to True… this means that we need to manually approve this in order for the function to execute.»

Функція приймає order_id і amount та повертає рядок на кшталт «refunded $amount for order order_id». Насправді ж це лише мок, жодних реальних транзакцій немає. Але логіка human‑in‑the‑loop реалізована повноцінно.

Механіка така:

1. LLM, дійшовши до необхідності рефанду, формує виклик process_refund з параметрами.
2. Agentspan, бачачи approval_required=True, не запускає функцію автоматично, а ставить агент у стан очікування.
3. Код на Python отримує подію типу WAITING у стримі подій.

Далі включається CLI‑шар: розробник показує, як цим станом керувати вручну.

Обробка очікування: події, approve/reject і прозоре UX для оператора

Щоб коректно реагувати на запити рефанду, агент підключається до потоку подій (handle.stream()) і переглядає їх у циклі. Автор додає декілька умовних блоків, які зчитують потрібні дані з подій типу tool_call та tool_result: шукають order_id і amount у аргументах та результатах інструментів.

Критичний фрагмент — обробка події очікування:

«What I’m going to do is… if event.type is equal to EventType.WAITING… I’m going to print… “approval required, refund $amount for order order_id”… ask them approve yes or no… if decision is ‘y’ then handle.approve, otherwise handle.reject.»

У CLI це виглядає як:

• вивід повідомлення «approval required, refund $49.99 for order A100»;
• input‑запит «approve yes or no»;
• у разі y викликається handle.approve(), що запускає рефанд‑tool;
• інакше — handle.reject("user rejected").

По суті, це мінімалістичний інтерфейс оператора сапорту, підʼєднаний до AI‑агента через стрим подій Agentspan. У реальній системі це повідомлення легко перетворити на UI‑кнопку в адмінці, але патерн лишається тим самим: LLM ініціює дію, інфраструктура ставить її «на паузу», людина підтверджує або блокує.

Guardrails проти prompt‑інʼєкцій: фільтрація ще до LLM

Останній важливий шар захисту сапорт‑агента — guardrails. Вони дозволяють перехопити потенційно шкідливі або неприйнятні запити ще до того, як вони потраплять у LLM.

Автор пояснює: «I’m going to show you how we write a guardrail… block obvious prompt injection attempts… before the LLM even sees it… we can actually prevent against that by building in these guardrails.»

Створюється guardrail‑функція safe_support_request, яка приймає prompt: str і повертає GuardrailResult. Усередині формується список підозрілих фраз:

blocked = ["ignore", "ignore previous", "system prompt", "jailbreak"]
passed = not any(phrase in prompt.lower() for phrase in blocked)
return GuardrailResult(
    passed=passed,
    message="please ask a normal question this is blocked"
)

Потім вона підʼєднується до агента як окреме правило:

«We have this guardrail… safe_support_request… position is Position.INPUT and then on_fail is OnFail.RAISE… so as soon as we get some input to our agent, run it through the guardrail… if there is something wrong, then tell us and fail.»

Ключові параметри:

• position=Position.INPUT — guardrail застосовується до вхідного запиту, до LLM;
• on_fail=OnFail.RAISE — у разі порушення правило генерує помилку й повністю зупиняє виконання.

Результат: будь‑яка спроба «jailbreak this prompt» чи «ignore previous instructions» не дійде до моделі, а користувач отримає відповідь із повідомленням guardrail‑функції.

У поєднанні зі структурованим виводом і human‑in‑the‑loop це створює цікавий тришаровий захист: інʼєкції блокуються на вході, реквест‑флоу описаний у схемі, а критичні операції підтверджує людина.

Висновок: прототип сапорт‑бота, який можна вбудовувати в продакшн

Сапорт‑агент із курсу Tech With Tim показує один із найпрактичніших шаблонів використання Agentspan:

• базовий RAG‑подібний пошук через інструменти по документації та замовленнях;
• структурований Pydantic‑вивід (SupportResponse) зі stage і прапорцем successful;
• явний human‑in‑the‑loop для рефандів через approval_required=True і обробку подій WAITING;
• input‑guardrails, що блокують примітивні prompt‑інʼєкції до звернення до LLM.

Для команд, які будують AI‑сапорт‑сервіси, це готовий каркас: достатньо замінити мок‑базу на реальні джерела, поглибити пошук до повноцінного RAG і перенести CLI‑схвалення в веб‑інтерфейс. Важливіше, однак, інше — цей приклад демонструє, як будувати агентів одразу з продакшн‑вимогами: контроль, прозорість, безпека та передбачуваний вивід закладені в архітектуру з першого дня.

Джерело

YouTube: Build 3 PRODUCTION AI Agents in Python – Full Course (Agentspan)

Платформа Tech With Tim у новому форматі: замість короткої демки — повноцінний курс із побудови продакшн‑готових AI‑агентів на Python. Перший приклад у цій системі — базовий, але показовий: простий розмовний агент із памʼяттю, підключеним LLM та власними інструментами, який працює через сервер Agentspan і повністю проглядається у веб‑дашборді.

Від «hello world» до живого асистента

Початкова ціль — зробити «простого розмовного агента, що має доступ до розмовної памʼяті». Тобто чат‑асистента, з яким можна спілкуватися у терміналі, а всі його кроки при цьому видно в інтерфейсі Agentspan.

Архітектура виглядає так: на локальній машині працює Python‑воркер, що містить логіку агента, а окремо запускається Agentspan Server. Сервер відповідає за стан виконання, історію, черги задач, ретраї й те, що тут особливо важливо, — observability: повний лог кожного запиту, відповіді та виклику інструментів у веб‑UI.

У Python‑коді все починається з ініціалізації середовища та базового агента. Через .env задається AGENTSPAN_SERVER_URL — URL локального сервера на http://localhost:6767/api. Потім за допомогою load_dotenv() Agentspan автоматично дізнається, куди стукатись.

Далі створюється агент:

assistant = Agent(
    name="personal assistant",
    model="openai/gpt-4.5-mini"  # в курсі використовувалась GPT‑5.4, але синтаксис той самий
    instructions="""
    You are a concise personal assistant.
    Use tools when they help and remember useful user details across turns.
    """,
    tools=[],
    memory=None,  # памʼять додадуть пізніше
)

Головна «оболонка» для спілкування — нескінченний while‑loop з введенням тексту, у якому виконуються запити до агента через run() у контексті AgentRuntime. Так формується мінімальний, але вже цілком продакшн‑орієнтований скрипт: є підключення до серверу, модель, цикл діалогу і можливість дивитися все це в дашборді.

«Усе, що ми фактично зробили, — імпортували кілька потрібних речей, налаштували ENV для звʼязку з сервером, створили асистента — це супер базовий асистент — і запустили while‑loop, щоб спілкуватися з ним», — так характеризується перша версія.

Чому без памʼяті агент «забуває» все, що ви сказали

Після першого запуску цей асистент працює як типовий LLM‑чат без контексту між сесіями. Можна сказати: «Мене звати Тім», отримати ввічливе «Приємно познайомитися, Тім», але наступне питання «Як мене звати?» поверне чесне «Я не знаю вашого імені».

Причина проста: «За замовчуванням, якщо ви не додаєте памʼять, я можу сказати: “Гей, моє імʼя Тім.” … А потім наступного разу, коли я щось запитаю, він це повністю забуде, бо не зберігає попередні відповіді».

У цій моделі памʼять не «вбудована» автоматично, її потрібно явно створити й підʼєднати. Для цього використовується ConversationMemory з модуля agentspan.agents. Після додавання змінної:

conversation_memory = ConversationMemory(max_messages=50)

агент отримує параметр memory=conversation_memory. Це обмежує контекст 50 останніми повідомленнями — після цього старі записи просто вирізаються, щоб не роздувати prompt.

Спочатку розробник забуває ще один крок: додати реальні повідомлення до памʼяті. Через це агент, навіть із підключеною ConversationMemory, не може згадати імʼя користувача. Проблему вирішує явне додавання в кожному циклі:

readable_result = result.output.get("result")

conversation_memory.add_user_message(prompt)
conversation_memory.add_assistant_message(readable_result)

Після цього сценарій «Мене звати Тім» → «Як мене звати?» нарешті працює: агент дістає імʼя з памʼяті й відповідає коректно. Підкреслюється, що це класична помилка інтеграції: памʼять створено й передано в агент, але історія діалогів туди не записується, тож у моделі немає, що читати.

Інструменти: від голого тексту до дій у реальному світі

Базовий агент без інструментів фактично «вміє» лише одне: формувати текстову відповідь. Щоб перетворити його на корисного помічника, треба дати можливість виконувати дії чи отримувати дані ззовні.

У термінах Agentspan це роблять tools. Формулювання просте: «Інструмент — це щось, що AI‑агент може викликати, щоб отримати певну відповідь або виконати певну дію».

Як оголошується інструмент

У курсі для демонстрації беруть елементарну функцію отримання поточного часу:

@tool
def get_current_time() -> str:
    """Returns the current local time."""
    now = datetime.now()
    return str(now)

Структура має кілька обовʼязкових елементів.

По‑перше, імпорт декоратора @tool із Agentspan.

По‑друге, у сигнатурі функції треба явно вказати тип виходу (і, за потреби, типи вхідних аргументів). Коментар до цього підкреслює: «наприклад, я скажу: функція get_current_time повертатиме рядок… а потім ви просто конвертуєте це в рядок і повертаєте».

По‑третє, докстрінг. Саме він стає описом інструмента для моделі: що робить, які аргументи приймає, що повертає. Це критично, тому що LLM ухвалює рішення, який інструмент викликати, орієнтуючись саме на такі текстові описи.

«Щоб додати інструмент — супер просто… Ми просто визначаємо функцію, позначаємо її як інструмент через цей декоратор @tool… Назва інструмента автоматично буде назвою функції», — так описується типовий патерн.

Як Agentspan викликає інструменти під капотом

Коли інструмент оголошено, його треба додати до списку tools в агенті:

assistant = Agent(
    ...,
    tools=[get_current_time],
    memory=conversation_memory,
)

Із цього моменту модель може, орієнтуючись на інструкції та запит користувача, вирішити, що їй потрібні свідчення ззовні, й сформувати спеціальний «виклик інструмента» замість прямої відповіді.

Цей процес описується так: «Тепер Agentspan нативно визначає можливість виклику інструментів… назва цього інструмента була get_current_time… потім ми викликали інструмент, отримали вихід… і передали його в модель».

Механіка така:

1. Асистент отримує запит, наприклад: «Котра зараз година?».
2. Модель, замість відповіді, повертає JSON із інструкцією викликати get_current_time.
3. Runtime Agentspan, що обертає агента, автоматично викликає однойменну Python‑функцію.
4. Отриманий результат (рядок з датою й часом) додається до контексту діалогу.
5. Модель вдруге викликається вже з новим контекстом, де є результат інструмента, і формує фінальну текстову відповідь.

Це добре видно в дашборді: окремо показаний крок LLM із запитом на виклик get_current_time, результат функції й фінальна відповідь для користувача.

Після запуску й запиту «What time is it?» система повертає коректний час, а в UI Agentspan можна побачити, як у логах зʼявляється крок із викликом get_current_time та його результатом.

Веб‑дашборд як обовʼязковий елемент продакшн‑агента

Цей перший агент навмисно простий логічно, але вже повністю використовує інфраструктурні переваги Agentspan. Одне з ключових — прозорість виконання.

У дашборді для кожного «запуску» агента видно, що саме відбулося:

• вхідний prompt користувача;
• вихід моделі (проміжні та фінальний);
• виклики інструментів: імʼя, аргументи та повертовані дані;
• метадані на кшталт тривалості кроку та токенів.

Саме цей сценарій — задати запит у терміналі, а потім зайти в браузер та подивитися повний трейс — і демонструє, як Agentspan пропонує робити продакшн‑розробку: навіть найпростіша версія агента з самого початку будується «поверх сервера» з durable execution та observability, а не як ізольований скрипт.

Крок до продакшну: один файл — вже робочий агент

У підсумковій версії «агент №1» — це один Python‑файл, який:

• підʼєднується до Agentspan Server через змінну середовища;
• створює агента з моделлю, інструкціями, розмовною памʼяттю та хоча б одним інструментом;
• запускає нескінченний цикл спілкування в терміналі, де користувач може вийти, ввівши q;
• додає кожне повідомлення користувача й відповіді асистента до памʼяті;
• дозволяє Agentspan автоматично обробляти виклики інструментів і зберігати повний лог сесій.

Важливий акцент — цей агент із перших рядків коду задуманий для реального середовища, а не як «демо в ноутбуку». Памʼять, інструменти, підключення до серверу та веб‑дашборд — усе це розглядається не як add‑on, а як базовий набір для практичного використання.

Джерело

YouTube — Build 3 PRODUCTION AI Agents in Python – Full Course (Agentspan)

У тривалому курсі на каналі Tech With Tim розробник і контентмейкер Тимофі Бьючемі показує, як перейти від «демок у терміналі» до реально продакшн‑готових AI‑агентів на Python. У центрі — фреймворк Agentspan від Orkes: сервер для оркестрації стану плюс воркери, які виконують код. Саме через цю призму він розбирає головні проблеми реального запуску агентів і те, які фундаментальні властивості мають бути в інфраструктури, якщо її планують навантажувати тисячами користувачів.

Чому «демо‑агенти» сиплються в реальному світі

Тим починає з критики того, як сьогодні виглядає більшість навчальних матеріалів по агентам: «Most AI agent tutorials show you demos that fall apart the moment you try to run them in the real world.» Код, який здається переконливим у відео чи Jupyter‑ноутбуку, майже ніколи не враховує два базові факти продакшену: процеси падають, а користувачі поводяться непередбачувано.

Одна з перших реальних проблем — краші посеред виконання. «First we have processes that crash mid run… your AI agent just gets killed and that means that a lot of the work that’s done can be completely wasted.» Причини можуть бути будь‑які: нестабільна мережа, зависла база даних, рестарт контейнера. Якщо виконання агента привʼязане до одного процесу без збереження стану, будь‑який збій означає втрачений контекст і змарновані токени.

Друга категорія клопоту — часові розриви через участь людини. Агент може дійти до кроку, де потрібно натиснути кнопку «підтвердити повернення коштів» або схвалити видалення файлу. Цей крок може висіти хвилини, години чи дні. Якщо архітектура не передбачає «заморожування» і відновлення таких сесій, все ланцюжок доводиться проганяти з нуля.

Третя проблема, яку Тим називає «однією з найважливіших» — відсутність видимості: «A lot of times when you build these AI agents, you have no idea what they’re actually doing. So you need observability into the platform to see what step it’s on, where is it going wrong, what tools is it calling.» У звичайних фреймворках на кшталт базового LangChain розробник часто бачить лише вхід і вихід моделі, але не розуміє, як саме агент обходив інструменти, скільки було спроб, на якому саме кроці все розвалилося.

І нарешті — масштабування. Тим прямо формулює обмеження популярних «легких» стеків: «A lot of times if you just build a simple like LangChain agent or something, it’s not going to scale to tens of thousands of users and you have to pretty much reinvent the wheel and spend most of your time deploying out all of this infrastructure.» Інакше кажучи, якщо потрібні десятки тисяч одночасних користувачів, доводиться окремо будувати черги, стійке зберігання стану, обробку ретраїв, тестування — замість того, щоб концентруватися на логіці самого агента.

Сім ознак «справжнього» продакшн‑агента

На цьому тлі Тим формулює набір із семи властивостей, без яких агент не можна вважати продакшн‑готовим: «There’s seven things that you need if you want to have an AI agent actually be production ready… durability… retries… human in the loop… observability… long‑running tasks… and then scale and testing.»

Першою він називає durability — стійкість виконання. Суть: якщо агент падає, він має відновитися з того місця, де зупинився, «and it doesn’t need to completely restart». Тобто стан усієї сесії не повинен бути привʼязаний до одного процесу — його потрібно зберігати деінде і мати можливість підʼєднатися повторно.

Друге — retries. «Sometimes a step will fail. That doesn’t mean we should completely exit the process. We should retry it multiple times.» З точки зору інфраструктури це означає, що кожний крок workflow повинен мати політику повторів, а черга — механізм перезапуску завдань без ручного втручання.

Третя властивість — human in the loop. Агент повинен вміти повертати завдання людині з чіткою формою: «”Hey, are you sure you want to do this? Do you want to issue the refund? Do you want to delete this file? XYZ.”» І головне — вміти чекати скільки завгодно, не втрачаючи стану, поки людина не підтвердить або не відхилить операцію.

Четверта — observability. «We need to be able to actually see what’s going on in real time.» Йдеться не лише про логи, а про структурований огляд: на якому кроці агент, які інструменти викликає, які аргументи передає, що відповідає LLM і як змінюється стан від кроку до кроку.

Пʼята характеристика — підтримка long‑running tasks. «If agents take 20, 30, 2 hours to run, we should be able to handle that.» Тобто система має витримувати сценарії, де один агент виконує складний робочий процес протягом годин, з численними зверненнями до зовнішніх API, баз даних і людськими підтвердженнями.

Шоста й сьома — scale and testing. Масштабування означає можливість обробляти багато одночасних workflow без ручного мікроменеджменту кожного процесу. Тестування — можливість проганяти агентів у симульованих сценаріях, у тому числі без реальних викликів LLM, щоб виявляти помилки в інструментах, схемах виводу та конфігурації до того, як код потрапить у бойове середовище.

Усі ці вимоги виходять далеко за межі простого «виклику моделі» і наближають агентів до повноцінних розподілених систем workflow‑оркестрації.

Архітектура Agentspan: сервер стану та легкі воркери

Для реалізації цього набору властивостей Тим використовує Agentspan — фреймворк, який, за його словами, «comes from Orks» і є повністю open source. Ключова ідея — розділити код агентів і керування станом між воркером та спеціалізованим сервером.

«Orkes essentially gives us a server which is going to handle all of the different state and kind of track the progress of the multiple AI agents that we’re running.» Цей сервер виступає бекенд‑інфраструктурою: зберігає історію, статуси завдань, рішення про ретраї, human‑in‑the‑loop, multi‑agent‑оркестрацію. Воркери ж запускаються там, де зручно команді, — на локальній машині, на VPS чи в будь‑якому іншому середовищі.

Код агента у Python виглядає як звичайний клієнт: «from the worker side, we pretty much just say, “Hey, we’re building an agent. We’re going to connect to this server.” All of the rest of the code stays exactly the same.» Вказується URL сервера (через змінну середовища), а все, що пов’язано з durable execution, бере на себе Agentspan‑сервер.

Схема, яку показує Тим, складається з трьох блоків: воркер, сервер Agentspan і будь‑який LLM‑провайдер. «We have a worker. The worker is what we’re going to write ourselves. We have the agent span server. This is already provided to us… And then, of course, we have an LLM. We can use any LLM that we want.» Важливий момент: сервер вміє зберігати credentials до LLM‑провайдерів у себе, тож ключі не потрібно хардкодити у воркер‑код.

Такий поділ означає, що воркер можна зупинити й перезапустити в будь‑який момент, не втрачаючи прогресу. «If there was a crash, for example, we could recover from that crash because all of the state is stored on this server… we could just reconnect, restart where we left off and it’s not a big deal and this task can run for as long as it needs to.» Ця властивість безпосередньо закриває проблему крашів посеред виконання і робить допустимими багатогодинні workflow.

Durable execution, черги, ретраї та «людина в середині»

На практичних прикладах Тим показує, як Agentspan поєднує кілька із перелічених семи вимог в одну архітектуру.

По‑перше, durable execution. Сервер зберігає execution_id кожного запущеного workflow. Якщо воркер падає на пʼятому з десяти кроків, виконання залишається «живим» на сервері. Достатньо перезапустити воркер і підʼєднатися до вже існуючого виконання за цим ідентифікатором. Система продовжить з того самого кроку, не повторюючи вже успішні операції й не витрачаючи додаткові токени.

По‑друге, ретраї та черги. На дашборді, який працює поверх Agentspan‑сервера, Тим показує, як один агент генерує багато «tasks» усередині одного виконання, а сервер тримає для них вбудовану чергу. Це дозволяє автоматично перебирати кроки, що тимчасово падають (наприклад, через тимчасову помилку API), не перериваючи весь процес.

По‑третє, human‑in‑the‑loop. У другому прикладі сапорт‑агента використовується інструмент process_refund з прапорцем approval_required. Сценарій виглядає так: агент сам шукає замовлення, обчислює суму, формулює, що саме хоче повернути, але зупиняється в статусі waiting. У стримі подій воркер бачить, що агент чекає схвалення, виводить користувачеві пояснення, яку суму і за яке замовлення планує повернути, і на основі відповіді людини викликає handle.approve або handle.reject. При цьому «this can take any amount of time. It could take a day. It could take an hour or it could take 10 minutes. Doesn’t matter. The server will keep running here.» Стан очікування живе на сервері стільки, скільки потрібно.

По‑четверте, підтримка довгих завдань. Тим окремо демонструє агент з «повільним кроком», який кожного разу чекає кілька секунд і має виконати десяток таких кроків. Коли воркер зупиняють посередині, сервер продовжує «тримати» виконання. Перезапущений воркер через connect до попереднього execution_id бачить уже виконані кроки і рушає далі, не перезапускаючи весь процес.

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

Observability як обовʼязкова умова

Особливий акцент у курсі робиться на видимість того, що робить агент у кожен момент. Через веб‑інтерфейс серверу Тим показує історію виконань: список агентів, кожен execution, окремі turns, токени, причину зупинки, тривалість кроків.

«For any given AI agent… You can see a full log of everything that’s actually gone on. And you can see this in real time.» Для кожного кроку відображається вхід у LLM, JSON‑опис викликів інструментів, їхні аргументи та результати. Це дає можливість буквально покроково відмотати, чому агент ухвалив саме таке рішення, де саме відбулась помилка, якою була відповідь інструмента.

Ця observability повʼязана не лише з налагодженням, а й з довірою до системи, яка приймає бізнес‑рішення. У прикладі з поверненням коштів можна в будь‑який момент відкрити виконання, побачити, який order_id було використано, яку суму агент збирався повернути і на підставі якого документа прийняв це рішення.

У масштабному сценарії з «дослідницькою фабрикою», де працюють кілька агентів‑аналітиків, дослідник, райтер і редактор, той самий інтерфейс дозволяє відслідковувати, коли паралельні агенти завершили роботу, як їх результати були передані далі й як у підсумку було сформовано фінальний звіт.

Масштаб і тестування: від локального запуску до тисяч користувачів

Повертаючись до своєї тези, що «simple like LangChain agent… is not going to scale to tens of thousands of users», Тим показує, як Agentspan намагається зробити цей перехід менш болісним.

По‑перше, шлях масштабування воркерів стає тривіальним: кожен воркер — це звичайний Python‑процес, який реєструється на одному й тому самому сервері. Сервер тримає чергу, роздає завдання воркерам, відстежує стан, робить ретраї. Якщо потрібно обробити більше навантаження, додаються нові воркери, не чіпаючи центральний стан.

По‑друге, тестування вбудовано безпосередньо в фреймворк. Тим демонструє, як можна створювати «мок‑тести» агентів, описуючи очікувані виклики інструментів, результати та фінальний structured output, і проганяти їх без звернення до реального LLM. Це дає змогу швидко перевіряти, що агент правильно інтегрує інструменти, коректно збирає schema‑відповіді й не ламається на базових сценаріях.

Комбінація цих речей — durable execution, черги, human‑in‑the‑loop, observability, тестування — робить Agentspan більше схожим на оркестратор бізнес‑процесів для LLM‑агентів, ніж на черговий обгортковий фреймворк до API моделей.

Висновок: від «іграшкових» ботів до робочих AI‑систем

Курс Tech With Tim показує, що перехід від демонстраційних агентів до продакшн‑сервісів — це не стільки про «кращий промпт», скільки про інженерію навколо LLM: стійке збереження стану, обробку збоїв, участь людини, спостережуваність, можливість довго працювати і масштабуватися.

«At the end of this video, you could very easily go deploy this app by just deploying the server and deploying your workers and you’re good. That’s it. because of the way that we built it as opposed to if you use a lot of the other frameworks out there.» Ця проста формула — сервер+воркери — може бути особливо привабливою для команд, які сьогодні мають ефектний агент у ноутбуку, але не розуміють, як безболісно винести його в бойове середовище.

Для українських продуктових і аутсорсингових команд, що будують AI‑фічі для реальних користувачів, головне в цьому підході — чітке формулювання вимог до «дорослої» агентної інфраструктури. Сім ознак, які перераховує Тим, — це фактично чек‑лист, без якого будь‑який AI‑агент ризикує залишитися красивою, але крихкою демкою.

Джерело

Build 3 PRODUCTION AI Agents in Python – Full Course (Agentspan)

Майже через три роки після запуску як конкурента Twitter (нині X) Threads досяг позначки у 500 мільйонів активних користувачів на місяць, повідомила компанія у вівторок. Соцмережа, що належить Meta, також анонсувала низку нових функцій, зокрема інструмент “Your Algo”, який дозволяє користувачам керувати тим, що вони бачать у своїй стрічці.

Нова функція Your Algo розвиває інструмент платформи “Dear Algo”, запущений у лютому. Він дозволяє користувачам повідомляти Threads, чого вони хочуть бачити більше або менше у своїй стрічці, публікуючи відкритий пост на кшталт: “Dear Algo, show me more posts about podcasts” (“Дорогий алгоритме, показуй більше постів про подкасти”). З Your Algo користувачі можуть керувати наповненням стрічки приватно, без публічних дописів.

Можна вказати, що ви хочете бачити більше чи менше дописів на певні теми, і обрати, як довго діятиме запит: один, три або сім днів. Ці налаштування бачите лише ви.

Your Algo починають розгортати сьогодні в США, Канаді, Великій Британії, Австралії та Новій Зеландії.

Надаючи користувачам можливість тимчасово впливати на вміст своєї стрічки, Threads отримує перевагу над X та іншими конкурентами, пропонуючи функцію, якої немає на rival-платформах.

Threads також виводить функцію “Communities” (Спільноти) із бети й додає нові затребувані можливості. Запущений торік як ще одна відповідь X, цей інструмент дає користувачам окремі простори в додатку, де вони можуть глибше занурюватися в обговорення тем, які їх цікавлять, наприклад, баскетбол, телебачення, K-pop, книжки тощо. Тепер користувачі зможуть знаходити спільноти через новий “Communities Hub”. Крім того, спільноти отримують власні відмінні іконки, щоб їх було легше помічати й упізнавати.

“Discovery Hub — це спосіб показати більшу кількість спільнот більшій кількості людей”, — розповів керівник Threads Коннор Гейс у коментарі TechCrunch. — “Ми помітили, що коли люди користуються застосунком із чіткою метою та швидко знаходять “своїх” у додатку, їхній досвід стає значно кращим. Однією з проблем від запуску цієї функції протягом минулого року було те, що інколи складно органічно знайти спільноти, які для тебе справді важливі. Тож Discovery Hub — велике оновлення”.

Threads також оголосив про розширення функції Live Chats (живі чати) для більшої кількості спільнот, а також додав можливість спів-хостингу чатів і цитування окремих моментів у власну стрічку. Запущені у квітні Live Chats дозволяють вести розмови в реальному часі під час культурних подій на кшталт чемпіонату світу ФІФА. До липня всі спільноти зможуть запускати Live Chats.

“Один із позитивних відгуків, який ми часто чуємо про Threads, — це те, що людям подобається тиша в додатку в світі, де більшість соцмереж відеоцентричні й гучні. І ці Live Chats стали приємним “другим екраном” для людей, які щось дивляться, але хочуть паралельно стежити за коментарями”, — сказав Гейс.

Розширення Live Chats допоможе Threads скоротити відставання від X у частині розмов у реальному часі. На відміну від X, який давно виконує роль своєрідної глобальної “площі” для новин та прямих подій, Threads на старті поступався X за актуальністю та оперативністю, оскільки в ньому бракувало багатьох можливостей X, зокрема потужного пошуку, хештегів і хронологічної стрічки. Однак з часом ці функції додали, і тепер Threads намагається краще конкурувати з X, запроваджуючи можливість, якої немає навіть у застосунку, що належить Ілону Маску.

Новий показник MAU (щомісячна активна аудиторія) свідчить, що Threads вдалося залучити ще 100 мільйонів користувачів за останні 10 місяців: у серпні 2025 року компанія повідомляла про 400 мільйонів активних користувачів на місяць.

Джерело

TechCrunch

SpaceX домовилася придбати стартап зі штучного інтелекту для програмістів Cursor у рамках угоди на $60 млрд у вигляді акцій. Це сталося всього за кілька днів після історичного IPO космічної компанії та менш ніж за два місяці після оголошення про їхню співпрацю.

Угода має посилити AI‑підрозділ SpaceX, побудований навколо компанії xAI Ілона Маска, яку SpaceX об’єднала зі своєю структурою раніше цього року. Цей напрямок покликаний наздогнати провідні AI‑лабораторії. Попри те, що штучний інтелект став ключовою частиною обіцянок SpaceX під час IPO, її AI‑напрямок перебуває в процесі реструктуризації після низки скандалів — зокрема через те, що користувачі могли генерувати несанкціоновані дипфейки за участю жінок і дітей.

SpaceX у вівторок заявила, що закриття угоди очікується в третьому кварталі цього року.

До появи SpaceX Cursor готувався закрити раунд фінансування на $2 млрд від інвесторів на кшталт Andreessen Horowitz, Thrive і Nvidia, який оцінював стартап у $50 млрд, повідомляв TechCrunch.

Компанія Маска ще у квітні, напередодні IPO, оголосила незвичайну угоду: вона або викупить Cursor за $60 млрд акціями, або сплатить $10 млрд як штраф, якщо угода зірветься.

На момент оголошення цієї угоди Cursor швидко зростав. Але одне з джерел TechCrunch тоді зазначало, що запланованих $2 млрд йому все одно не вистачить для досягнення беззбитковості. І це попри те, що раніше стартап залучив $900 млн у раунді Series C у червні 2025 року та ще $2,3 млрд наприкінці 2025‑го.

Заснований у 2022 році під назвою Anysphere, Cursor демонстрував стрімке зростання на хвилі популярності AI‑інструментів для програмування за останні два роки. У 2024 році він пройшов акселератор OpenAI, а згодом залучив достатньо коштів, щоб отримати оцінку близько $29 млрд до оголошення угоди зі SpaceX.

Ознаки інтересу SpaceX до Cursor з’явилися на початку цього року, коли xAI найняла двох старших інженерних керівників стартапу. Потім у квітні Business Insider повідомив, що xAI вирішила здавати частину своїх потужностей дата‑центру в оренду Cursor — натяк на подібні угоди, які SpaceX уклала з Anthropic і Google напередодні IPO. Ці переговори між SpaceX і Cursor швидко переросли в нинішню угоду.

Усе це відбувалося на тлі фактичного розпаду xAI.

До кінця березня всі 11 співзасновників xAI, окрім Маска, залишили компанію, а сам Маск публічно визнав, що xAI «спочатку була побудована неправильно» і що він перебудовує її «з нуля». Це стало продовженням низки інцидентів: зокрема, чат‑бот Grok у 2025 році називав себе «MechaHitler», а також дозволяв користувачам генерувати оголені зображення та сексуальні дипфейки за участю жінок і дітей. У проспекті до IPO SpaceX попередила інвесторів, що така поведінка несе ризики для бізнесу, і зараз компанія стикається з низкою судових позовів через ці інциденти.

Розбір xAI збігся у часі з підготовкою SpaceX до того, що зрештою стало найбільшим IPO в історії. Під час цього процесу SpaceX та її банкіри презентували інвесторам бачення загального обсягу ринку близько $28 трлн. Майже вся ця сума — $26 трлн — припадала на напрямок штучного інтелекту.

SpaceX заявляла інвесторам, що бачить потенційний ринок на $2,4 трлн у сфері AI‑інфраструктури (включно з планами створити супутникове сузір’я для обробки AI‑обчислень) і можливість заробити $22,7 трлн на «корпоративних застосунках».

Тепер SpaceX робить ставку на Cursor, щоб реалізувати частину цих обіцянок. Поглинання стартапу після успішного IPO, імовірно, здається ще легшим кроком: від п’ятниці, коли SpaceX вийшла на біржу, її акції зросли з $135 за штуку до понад $200 на премаркеті у вівторок вранці. Це додало до капіталізації компанії майже $1 трлн — приблизно «вартість 16 Cursor» — усього за кілька днів.

Джерело

TechCrunch

Те, як люди легують метали, по суті не змінилося від часів бронзової доби: різні метали розплавляють у тиглі та змішують, доки не вийде новий, кращий сплав.

Молодий стартап Foundation Alloy розробив нову техніку легування, у якій інгредієнти не плавлять, а буквально «вибивають» з них новий матеріал.

«Ми фактично стискаємо та збиваємо частинки металевого порошку одна з одною, а не розплавляємо їх», — розповів TechCrunch співзасновник і CEO Foundation Alloy Джейк Ґуґлін. — «Ми можемо створювати властивості, яких інші отримати не можуть».

Поки що стартап продає свої індивідуально розроблені метали невеликими партіями, але, за словами Ґуґліна, компанію «обмежує здатність виробляти, а не попит».

Судячи з індустрій, у які вже постачає матеріали Foundation Alloy, кращих наявних металів або зовсім нових сплавів хочуть усі. Ґуґлін каже, що стартап проводить пілотні проєкти з компаніями в автомобільній, аерокосмічній, напівпровідниковій та оборонній галузях, а також із виробниками кухарських ножів і люксових годинників.

«Ми можемо заощадити їм купу грошей і купу тонн відходів», — каже він.

Щоб масштабувати виробництво до кількох тонн на тиждень до 2027 року, Foundation Alloy залучила $22 млн інвестицій у раунді серії A під проводом Voyager Ventures, про що стартап ексклюзивно повідомив TechCrunch. У раунді також взяли участь Trust Ventures, Yamaha Motors, America’s Frontier Fund, Overlap Holdings, Material Impact, Engine Ventures, El Cap і Kanematsu Corporation. Остання також займатиметься дистрибуцією металів стартапу в Японії та Південно-Східній Азії.

Технологія Foundation Alloy виросла з наукових досліджень останніх 20 років. Тим Руперт і Кріс Шух вивчали, що відбувається з металами на нанорівні — це й стало основою технології стартапу. Шух не новачок у світі стартапів: раніше він співзаснував Desktop Metal і Xtalic.

Якщо майже всі комерційні сплави сьогодні створюють шляхом плавлення різних металів, то Foundation Alloy використовує спеціальний тип млина, який багаторазово стискає та ударяє частинки різних металевих порошків, доки вони не перетворяться на один новий метал. Відмовившись від плавлення, компанія, за словами Ґуґліна, знижує енергоспоживання приблизно на порядок завдяки твердотільному процесу.

Мета будь-якого процесу легування — створити кристалічну структуру на молекулярному рівні, яка поєднує два чи більше металевих елементів. Ідеальний сплав був би повністю однорідним — тобто кожен кристалічний «візерунок» рівномірно повторювався б у всьому матеріалі.

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

Твердотільний процес легування дозволяє Foundation Alloy створювати матеріали, які знімають давні компроміси. Зазвичай метали налаштовують або на витривалість до високих температур, або на механічну міцність, адже спроба поєднати обидві якості зазвичай дає посередній результат. Метали для печей зазвичай крихкі, а міцніші сплави, якими, наприклад, штампують автодеталі, швидко деградують під дією тепла.

Foundation Alloy вдалося подолати цю суперечність, створивши метали, які витримують і високу температуру, і значні навантаження. За словами Ґуґліна, серед перших продуктів компанії — інструментальна оснастка для автовиробників, а також деталей для аерокосмічної та оборонної галузей. В оборонці одним із перших ринків стали комплектуючі для дронів, де деякі ланцюжки постачання спочатку проєктувалися під виробництво деталей для винищувачів F-35.

«Вони мислили категоріями 100 ідеальних деталей на рік, — каже Ґуґлін, — тоді як дронам потрібно радше 10 000 на місяць».

За словами Ґуґліна, легування схоже на кулінарію. Двоє різних кухарів можуть використовувати ті самі інгредієнти, але отримати страви з різним смаком — кращим або гіршим, якщо вони не дотримуються однакових процедурних кроків.

«Якість готової страви визначається не лише інгредієнтами, а й тим, як ви готуєте, — говорить він. — У нас з’явився новий спосіб готувати».

Джерело

TechCrunch

Із зростанням можливостей великих мовних моделей (LLM) проблема «галюцинацій» залишається вперто невирішеною. Помилки з’являються навіть у найрозумніших моделях, і хоча існують способи їх виявляти, індустрія все ще шукає найкращий підхід.

Стартап Probably, який щойно залучив $9 млн посівних інвестицій від Andreessen Horowitz, прагне створити більш сувору систему виявлення таких помилок.

Як пояснює засновник компанії Пітер Еліас, мета Probably — не допустити, щоб до користувача доходили галюцинації та прості фактичні помилки, і досягти рівня точності 99,99%, звичного для детермінованих систем, але значно складнішого для ШІ. Як з’ясувалося, вивести LLM на такий рівень точності означає переосмислити багато базових припущень інженерії штучного інтелекту.

Перший продукт Probably — це інструмент для роботи з даними, створений для швидких відповідей на основі складних наборів даних. Кожен результат супроводжується посиланням на джерело та «аудиторським слідом» того, як він був отриманий — це дедалі поширеніша практика серед інструментів ШІ.

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

«Ми зрозуміли, що чим кращою є ваша інженерія обв’язки, тим слабкішою може бути модель», — каже Еліас. — «Якщо ви достатньо добре очистите й звузите контекст, моделі не потрібно дуже напружуватися, щоб зробити правильну річ. По суті, це вправа зі зменшення неоднозначності».

Це дозволяє інструменту Probably для роботи з даними працювати на суттєво менших моделях ШІ. За словами Еліаса, поточна версія працює на моделі, яка «на чотири класи слабкіша за найпотужніші моделі». Завдяки цьому її можна запускати на локальному «залізі» (тобто на звичайному настільному комп’ютері, а не в дата-центрі), що значно зменшує витрати на токени при використанні ШІ.

Ця ідея виглядає особливо привабливою в час, коли вартість токенів зростає, а багато клієнтів переглядають свої бюджети на ШІ. Ідеї Еліаса не обмежуються лише аналітикою даних: той самий рушій можна розширити на сценарії на кшталт бухгалтерії чи медичних сервісів — як каже засновник, «будь-який кейс, чутливий до точності».

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

Джерело

TechCrunch

Використовувати штучний інтелект як зручне пояснення для скорочення персоналу, схоже, швидко виходить з моди.

На відміну від багатьох колег по техіндустрії, які цього року звільнили тисячі людей, посилаючись на потребу «перебудувати команди» заради максимально ефективного використання ШІ, гендиректор Robinhood Влад Тенєв у своїй записці до працівників про звільнення 10% штатних співробітників — близько 290 людей — показово взагалі не згадав ШІ.

Не згадувалося про ШІ й у регуляторному повідомленні компанії, де рішення було подано як «реструктуризація».

Водночас Тенєв зазначив, що компанія й надалі використовуватиме «передові технології, щоб ще більше підсилити нашу ефективність» — формулювання, яке виглядає як свідоме уникання прямої згадки штучного інтелекту. Це не дивно: ставлення до ШІ та пов’язаних з ним інфраструктурних проєктів останнім часом погіршується, навіть попри те, що невелика група керівників техкомпаній заробляє на цьому величезні гроші.

Тенєв також підживив нинішній наратив про те, що компаніям «тепер необхідно працювати меншими командами і з пласкішою організаційною структурою». Він написав: «Ми не можемо за замовчуванням працювати як сильно розшарована організація. Ми маємо бути компактною, гіперфокусованою командою, де кожен окремий співробітник уповноважений робити величезний внесок».

Схожу риторику ми вже чули від компаній різних профілів — Amazon, Block, Coinbase, GitLab, Intuit. У їхніх оголошеннях про скорочення лунають ті самі тези, що великі команди, бюрократія та «силосні» департаменти стали небажаними витратами в час, коли інструменти ШІ обіцяють суттєво підвищити продуктивність.

Дехто вважає, що це ще й непряме визнання того факту, що техгіганти надмірно наростили штати після пандемії COVID-19, а тепер згортають їх, оскільки витрати стрімко зростають — особливо пов’язані з масовим використанням ШІ.

Як би там не було, ці компанії почуваються цілком упевнено. Акції техсектору загалом стрімко дорожчають, на тлі рекордної виручки, покращення маржі прибутку (GitLab минулого місяця відзвітував про валову маржу в 88%), вибухового попиту на хмарні сервіси та віри в те, що мільярдні інвестиції в дата-центри принесуть віддачу на порядки вищу.

Сам Robinhood у квітні повідомив про зростання виручки в першому кварталі на 15%. Компанія додає, що другий квартал поки що виглядає ще кращим завдяки зростанню комісій у «ринках передбачень», підписної виручки, а також високим обсягам торгівлі акціями та опціонами на тлі стабілізації ринків.

У вівторок компанія також заявила, що закриє «невелику кількість» відкритих вакансій та понесе близько $28 млн витрат, пов’язаних зі скороченнями.

Джерело

TechCrunch