Crash Course: Always-on agents

Що ви вивчите

• – Визначення always-on: цикл, що не зупиняється, і п'ять дієслів курсу (sense, decide, remember, act, evaluate)
• – Live demo на десктопі, телефоні та годиннику
• – Шар збору даних: розгортається там, де працюють ваші системи, і лише передає сигнали; issue та першопричини визначає core
• – Один агент охоплює кластери Kubernetes і хости Linux та має конектори до хмарних провайдерів
• – Агент виявляє віртуальні застосунки серед ваших навантажень і вимірює їх за допомогою eBPF, cgroups і метрик, побудованих на логах, у вигляді сигналів USE, RED, SIG і LOG
• – Усе передається через одне вихідне захищене з'єднання WebSocket

OpenTelemetry · OBI (eBPF) · USE · RED · golden signals · kagent connector

Лабораторна робота 1 · SENSE

Розгорніть агента на тестовому навантаженні, простежте, як автоматичне виявлення будує карту сервісів, і проаналізуйте той самий сервіс через USE, RED і SIG.

Що ви вивчите

• – Кожну подію одразу після надходження класифікують як шум, сигнал або issue за допомогою рефлекторних правил і моделі ембедингів
• – Більшість подій не потрапляє до великої моделі
• – Jev вирішує, що проходить guardrail, куди маршрутизується подія, наскільки вона серйозна і що, імовірно, відбудеться далі
• – Повільніші цикли виконують reflection щодо розв'язаних issue, встановлюють причини й записують отримані висновки в пам'ять у вигляді фактів і патернів

System 1 · System 2 · Jev · Gemini on Vertex AI · Nomic Embed

Лабораторна робота 2 · DECIDE

Надішліть у тестовий workspace набір типових і нетипових подій. Простежте кожну з них через класифікацію, рішення та маршрутизацію й визначте момент, коли дешевої відповіді вже недостатньо.

Що ви вивчите

• – Спостереження агента та його висновки зберігаються як комірки пам'яті: за ними можна шукати за змістом, вони входять до живого графа, консолідуються циклами reflection та knowledge і вилучаються, коли втрачають актуальність
• – Структура пам'яті відповідає CoALA: issue і події як епізоди, факти й патерни як знання, скомпільовані правила як процедури
• – Через MCP xray надає будь-якому агенту операції recall, remember і forget
• – Граф коду будується за допомогою Tree-sitter

CoALA memory · HNSW · Tree-sitter · MCP

Лабораторна робота 3 · REMEMBER

Підключіть власного кодового агента до xray через MCP. Збережіть рішення (remember), знайдіть його за змістом у новій сесії, потім видаліть (forget) і переконайтеся, що його більше немає.

Що ви вивчите

• – Tria знає workspace, його сервіси та зв'язки між ними, минулі issue і висновки, які команда з них зробила
• – Tria першою повідомляє, коли issue відкривається або розв'язується, і називає ймовірну причину на основі того, що workspace бачив раніше
• – У чаті workspace можна згадати @tria, і відповідь побачить уся кімната, або звернутися до Tria голосом; перед будь-якою зміною Tria запитує підтвердження
• – Як знання зростає з кожним issue, та месенджер, на якому все це працює

Gemini Live voice · Continuwuity · Matrix · Workspace chat

Лабораторна робота 4 · TRIA

Відкрийте тестове issue, запитайте Tria про ймовірну причину в чаті та голосом і порівняйте відповідь із тим, що workspace зберігає про схожі issue.

Що ви вивчите

• – Spot стежить за вашою інфраструктурою через Triage і продовжує працювати, поки вас немає
• – Це harness, що поєднує пам'ять, інструменти, навички та пісочницю, з конекторами до Kubernetes, моніторингу, хмарних сервісів, месенджерів і MCP
• – Модель можна замінити, а harness зберігає ідентичність агента
• – Кожен spot працює у власній пісочниці на Agent Substrate як актор: у разі простою він призупиняється, зберігає snapshot і відновлюється з усіма завданнями та діалогом
• – Як середовище виконання spot використовує Claude Code: постійну сесію з інструментами Triage через MCP

Agent Substrate · RustFS snapshots · Claude Code runtime · MCP

Лабораторна робота 5 · SPOT

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

Що ви вивчите

• – ego добирає живі сесії з трейсів OpenTelemetry, які ваші агенти вже генерують, оцінює їх і сповіщає про падіння якості
• – SDK не потрібен, а самого агента ego ніколи не перезапускає
• – Цикл складається з кроків: вибірка, оцінювання, виявлення, діагностика, корекція та верифікація
• – Коли оцінки падають, ego пояснює причину, передає діагноз агенту через MCP, фіксує внесену агентом зміну й перевіряє, чи оцінки відновилися
• – Для агента always-on ego розглядає роботу як єдиний безперервний потік
• – На завершення — порівняння п'яти складових і вибір, з якої почала б ваша команда

OpenTelemetry traces · agentevals · agentgateway · MCP

Лабораторна робота 6 · EVALUATE

Ознайомтеся з findings для тестового агента, виберіть один, внесіть єдину зміну й перегляньте вердикт. Порівняйте оцінки до і після.