Я ставлю свою компанію на проактивних агентів

Агенти можуть зробити майже все, про що ви їх попросите, і в цьому проблема: вам усе одно треба просити.

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

І більшість людей цього не помітила, бо поле для запиту тихо стало тим, чим ШІ є в наших головах.

Ask anything about your stack...

Кожен інтерфейс досі є полем для запиту

Поле введення є тим, з чого почалася вся ця епоха. ChatGPT поставив його поверх моделі і став продуктом, що ріс найшвидше в історії, і ми всі його скопіювали. Кожен ШІ-продукт відтоді був варіацією тієї самої взаємодії: людина друкує, машина відповідає, машина чекає.

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

~/app

$ claude

✳ 12 files · main · last session 2h ago

> fix the failing checkout tests

? for shortcuts

Потім агенти перебралися в хмару. Codex, Devin, Claude Code у вебі. Вони працюють годинами замість хвилин, запускають субагентів, щоб розпаралелити роботу, і не вмирають, коли ви закриваєте ноутбук. Ви даєте одному задачу перед обідом і повертаєтеся до pull request.

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

Triage Sentry alerts Enabled

When

a Sentry alert fires

Do

investigate, open an incident if it's real

Then

post the findings to #incidents

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

Планувальник це ви

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

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

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

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

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

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

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

[
  {
    "signal": "memory up 3% on checkout-edge",
    "verdict": "no anomaly",
    "reasoning": "within the seasonal range for this hour on this worker"
  },
  {
    "signal": "new error pattern, 2 minutes after deploy 9f3c2a1",
    "verdict": "incident",
    "reasoning": "error class never seen on this worker, tightly correlated with a deploy"
  }
]

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

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

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

Я почав з експлуатації

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

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

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

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

Як це виглядає

Ось що робить Polylane. Ось конкретний вівторок:

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

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

Restore Hyperdrive pool size in checkout-edge

PR open coreplane/checkout-edge

Investigation report attached Checks passing

Opened by Polylane · gated on review and CI

Проактивний не означає без нагляду

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

Межа не між людиною та агентом. Вона між оборотним і необоротним. І саме тому ви не залишаєтеся таємно на чергуванні: відкат завершив інцидент о 02:33, за шість годин до того, як ви злили pull request. PR ніколи не був тим, що зупинило кровотечу. Він є тим, що не дає їй повторитися, а це може почекати до кави.

І цей бар’єр ви можете делегувати. Агенти рев’ю коду вже читають кожен pull request у вашому репозиторії. Існує світ, недалекий від цього, у якому ваш агент рев’ю читає виправлення о 02:41, звіряє його з розслідуванням, схвалює, і ваш CI розгортає в продакшн до того, як ви прокинетеся. У циклі не змінюється нічого, крім того, хто тримає кнопку схвалення. Ось де це закінчується: програмне забезпечення, яке виправляє себе саме, а ви пишете політику замість натискати «злити».

Зверніть увагу, чого немає в цьому циклі:

Ask anything about your stack...

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

У 2026 році ніхто не має бути на чергуванні.