Агенти завжди новачки. Пора нам це враховувати у дизайні.

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

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

Контекст: Чому кодування було першим

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

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

Якщо це вірно для програмного забезпечення, однієї з найкраще задокументованих галузей, легко зрозуміти, чому агенти стикаються з труднощами у багатьох інших індустріях вже з першого дня. У охороні здоров’я та праві велика частина інституційних знань, що формує щоденну роботу, засвоюється та інтерналізується. Вона живе в досвіді людей, а не в формальній документації. Юридичний агент може не знати, яку структуру, тон або аргументацію віддає перевагу конкретний партнер у брифі, тоді як медичний агент може не розуміти місцевих робочих процесів і практик ескалації, які зайнята клініка використовує для підтримки триажу під керівництвом лікаря. Одна лише документація не закриє цей розрив, бо проблема не лише у доступі до інформації; вона у передачі контексту. Щоб надати агентам те, що їм потрібно для успіху, ми маємо вводити їх у роботу так само, як новачка.

Напрямок: Чому осмос не працює

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

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

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

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

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

Намір: Чому агенти схильні до середини

Важливо пам’ятати, що агенти — це машини, що підбирають шаблони, навчені на величезних об’ємах знань і природно схильні видавати статистичне середнє. Без чіткого, явного наміру саме це середнє і буде результатом. Попросіть агента «додати кінцеву точку автентифікації користувачів», і він згенерує textbook‑подібний маршрут Express з базовим хешуванням пароля. Це працює, але повністю ігнорує ваш власний сервіс автентифікації, пропускає необхідну телеметрію та порушує ваш уніфікований формат помилок. На папері це задовільна функція, але в контексті це архітектурна помилка. Легкість, з якою подібні «баги» потрапляють у код, важко переоцінити.

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

У людських взаємодіях багато простору для невизначеності. Хтось може поділитися з вами першою версією, і ви разом обговорюєте, що сильне, а що потребує покращення. Це працює, бо ми не очікуємо, що наші людські колеги будуть автономними машинами. Щоб по‑справжньому використати потенціал агентних колег (яких нам дійсно потрібно робити більш автономними…), ми можемо інженерно впровадити багато таких перевірок спрямування. Обмін «туди‑сюди» все ще потрібен, але він не може повністю лягати на ручну працю. Якщо наперед задати чіткі критерії прийняття та правила верифікації, ви дозволяєте агенту запускати власні внутрішні цикли зворотного зв’язку. Проектування запобігання помилкам — ще один надійний принцип UX, який ми можемо застосувати у цьому новому світі: надати агентам можливість позначати низьку впевненість перед виконанням дії, замість того, щоб беззвучно переходити до найкращої здогадки.

Де метафора руйнується

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

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

Відповідальність агента залежить від дизайну

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

Наступного разу, коли ви передасте завдання агенту, не просто перевіряйте результат. Спершу перевірте власні вхідні дані. Чи надали ви йому контекст, який новачок потребував би в перший день? Чи було ваше спрямування достатньо конкретним, щоб витримати буквальне тлумачення? Чи був ваш намір достатньо ясний, щоб «середня відповідь» не була найкращим, що він міг би зробити?

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