Agentic AI готова змінити досвід клієнтів і операційну ефективність, вимагаючи від керівництва нового стратегічного підходу. Ця еволюція штучного інтелекту дозволяє системам планувати, виконувати та наполегливо виконувати завдання, переходячи від простих рекомендацій до проактивних дій. Для команд UX, менеджерів із продуктів і керівників розуміння цього зрушення має вирішальне значення для відкриття можливостей в інноваціях, оптимізації робочих процесів і переосмислення того, як технології служать людям. Легко сплутати Agentic AI з Robotic Process Automation (RPA), тобто технологією, яка зосереджується на завданнях на основі правил, які виконуються на комп’ютерах. Різниця полягає в жорсткості проти аргументації. RPA чудово виконує суворий сценарій: якщо трапиться X, виконайте Y. Він імітує людські руки. Agentic AI імітує людські міркування. Він не дотримується лінійного сценарію; це створює один. Розгляньте робочий процес підбору персоналу. Бот RPA може сканувати резюме та завантажувати його в базу даних. Він ідеально виконує повторювані завдання. Система Agentic переглядає резюме, помічає, що кандидат вказує конкретну сертифікацію, порівнює це з новою вимогою клієнта та вирішує написати персоналізований електронний лист із підкресленням відповідності. RPA виконує заздалегідь визначений план; Agentic AI формулює план на основі мети. Ця автономія відокремлює агентів від інструментів прогнозування, які ми використовували протягом останнього десятиліття. Іншим прикладом є вирішення конфліктів на зустрічах. Прогностична модель, інтегрована у ваш календар, може аналізувати ваш розклад зустрічей і розклади ваших колег. Тоді він може запропонувати потенційні конфлікти, наприклад дві важливі зустрічі, заплановані одночасно, або зустріч, заплановану на час, коли ключовий учасник перебуває у відпустці. Він надає вам інформацію та позначає потенційні проблеми, але ви несете відповідальність за вжиття заходів. Агентський штучний інтелект за таким же сценарієм виходить за рамки простої пропозиції конфліктів, яких слід уникати. При виявленні конфлікту з ключовим учасником агент може діяти:
Перевірка наявності всіх необхідних учасників. Визначення альтернативних часових проміжків, які підходять кожному. Розсилання запропонованих нових запрошень на зустріч усім учасникам. Якщо конфлікт пов’язаний із зовнішнім учасником, агент може скласти та надіслати електронний лист, пояснюючи необхідність перепланування та пропонуючи альтернативний час. Оновлення вашого календаря та календарів ваших колег новими деталями зустрічі після підтвердження.
Цей агентський штучний інтелект розуміє мету (вирішення конфлікту наради), планує кроки (перевірка доступності, пошук альтернатив, надсилання запрошень), виконує ці кроки та продовжує діяти, доки конфлікт не буде вирішено, усе з мінімальним прямим втручанням користувача. Це демонструє «агентну» різницю: система вживає проактивних заходів для користувача, а не просто надає йому інформацію. Системи агентського штучного інтелекту розуміють мету, планують низку кроків для її досягнення, виконують ці кроки та навіть адаптуються, якщо щось піде не так. Подумайте про це як про проактивного цифрового помічника. Базова технологія часто поєднує великі мовні моделі (LLM) для розуміння та міркування з алгоритмами планування, які розбивають складні завдання на керовані дії. Ці агенти можуть взаємодіяти з різними інструментами, API і навіть іншими моделями штучного інтелекту для досягнення своїх цілей, і, що важливо, вони можуть підтримувати постійний стан, тобто вони пам’ятають попередні дії та продовжують працювати над досягненням мети з часом. Це робить їх принципово відмінними від типового генеративного ШІ, який зазвичай виконує один запит, а потім скидає налаштування. Проста таксономія поведінки агентів Ми можемо розділити поведінку агента на чотири різні режими автономії. Хоча вони часто виглядають як прогресія, вони функціонують як незалежні режими роботи. Користувач може довіряти агенту діяти автономно для планування, але залишати його в «режимі пропозицій» для фінансових транзакцій. Ми вивели ці рівні, адаптувавши галузеві стандарти для автономних транспортних засобів (рівні SAE) до контексту цифрового досвіду користувача. Спостерігай і пропонуй Агент виконує функцію монітора. Він аналізує потоки даних і позначає аномалії чи можливості, але не виконує жодних дій. Диференціація. На відміну від наступного рівня, агент не створює складного плану. Це вказує на проблему. Приклад. Агент DevOps помічає стрибок ЦП сервера та сповіщає чергового інженера. Він не знає, як або намагається це виправити, але він знає, що щось не так. Наслідки для проектування та контролюНа цьому рівні,розробка та нагляд повинні надавати пріоритет чітким, ненав’язливим сповіщенням і чітко визначеному процесу, за допомогою якого користувачі можуть діяти відповідно до пропозицій. Основна увага зосереджена на наданні користувачам своєчасної та актуальної інформації без контролю. Практики UX повинні зосередитися на тому, щоб пропозиції були зрозумілими та легкими для розуміння, тоді як менеджери з продуктів повинні переконатися, що система надає цінність, не перевантажуючи користувача. Плануй і пропонуй Агент визначає ціль і генерує багатоетапну стратегію для її досягнення. Він представляє повний план для перевірки людиною. Диференціація Агент діє як стратег. Він не виконується; він чекає на схвалення всього підходу. Приклад Той самий агент DevOps помічає стрибок ЦП, аналізує журнали та пропонує план виправлення:
Оберніть два додаткових екземпляри. Перезапустіть балансир навантаження. Архівуйте старі журнали.
Людина переглядає логіку та натискає «Затвердити план». Наслідки для розробки та контролю Для агентів, які планують і пропонують, розробка повинна гарантувати, що запропоновані плани легко зрозумілі, а користувачі мають інтуїтивно зрозумілі способи їх змінити або відхилити. Нагляд має вирішальне значення для моніторингу якості пропозицій і логіки планування агента. Практики UX повинні розробити чіткі візуалізації запропонованих планів, а менеджери продуктів повинні встановити чіткі робочі процеси перевірки та затвердження. Акт-з-підтвердженням Агент завершує всю підготовчу роботу і переводить фінальну дію в інсценований стан. Він ефективно утримує двері відкритими, чекаючи кивка. Диференціація Це відрізняється від «Плануй і пропонуй», оскільки робота вже виконана та поставлена. Це зменшує тертя. Користувач підтверджує результат, а не стратегію. Приклад. Агент з підбору персоналу складає проекти п’яти запрошень на співбесіду, знаходить відкриті години в календарях і створює події в календарі. Він представляє кнопку «Надіслати все». Користувач надає остаточний дозвіл для запуску зовнішньої дії. Наслідки для дизайну та нагляду Коли агенти діють із підтвердженням, дизайн повинен забезпечувати прозорі та стислі підсумки запланованих дій із чітким окресленням потенційних наслідків. Нагляд повинен переконатися, що процес підтвердження є надійним і що користувачів не просять сліпо схвалювати дії. Практики UX повинні розробляти зрозумілі підказки для підтвердження та надавати всю необхідну інформацію, а менеджери продуктів повинні надавати пріоритет надійному журналу аудиту для всіх підтверджених дій. Діяти-самостійно Агент виконує завдання самостійно в межах визначених меж. Розрізнення Користувач переглядає історію дій, а не самі дії. Приклад. Агент з найму бачить конфлікт, переносить співбесіду в резервний слот, оновлює кандидата та повідомляє менеджера з найму. Людина бачить лише сповіщення: співбесіду перенесено на вівторок. Наслідки для проектування та нагляду Для автономних агентів проект повинен встановити чіткі попередньо схвалені межі та забезпечити надійні інструменти моніторингу. Нагляд вимагає постійного оцінювання продуктивності агента в цих межах, критичної потреби в надійному журналюванні, чітких механізмах перевизначення та визначених користувачем перемикачах відключення для підтримки контролю та довіри користувача. Практики UX повинні зосередитися на розробці ефективних інформаційних панелей для моніторингу поведінки автономних агентів, а менеджери продуктів повинні забезпечити чітке управління та етичні принципи.
Давайте подивимося на реальну програму HR-технологій, щоб побачити ці режими в дії. Розгляньте «Агента з координації співбесід», призначеного для логістики найму.
У режимі підказки агент помічає, що інтерв’юер заброньовано двічі. Він підкреслює конфлікт на інформаційній панелі рекрутера: «Попередження: Сару двічі записали на співбесіду о 14:00». У режимі планування агент аналізує календар Сари та доступність кандидата. У ньому представлено рішення: "Я рекомендую перенести співбесіду на четвер о 10:00. Це вимагає перенести Сарру на 1:1 з її менеджером". Рекрутер переглядає цю логіку. У режимі підтвердження агент складає проекти електронних листів для кандидата та менеджера. Він заповнює календар запрошень. Рекрутер бачить підсумок: «Готові перенести на четвер. Надіслати оновлення?» Рекрутер натискає «Підтвердити». В автономному режимі агент миттєво вирішує конфлікт. Він дотримується попередньо встановленого правила: «Завжди віддавайте пріоритет співбесідам з кандидатами, а не внутрішнім співбесідам 1:1». Він переносить зустріч і надсилає сповіщення. Рекрутер бачить запис у журналі: «Вирішеноконфлікт розкладу для кандидата Б».
Буквар для дослідження: що досліджувати і як Розробка ефективного агентного штучного інтелекту вимагає чіткого дослідницького підходу порівняно з традиційним програмним забезпеченням або навіть генеративним штучним інтелектом. Автономна природа агентів штучного інтелекту, їх здатність приймати рішення та їхній потенціал для проактивних дій вимагають спеціальних методологій для розуміння очікувань користувачів, відображення складної поведінки агентів і передбачення можливих збоїв. У наступному дослідницькому посібнику описано ключові методи вимірювання та оцінки цих унікальних аспектів агентного ШІ. Ментально-модельні інтерв'ю Ці інтерв’ю розкривають упереджені уявлення користувачів про те, як повинен поводитися агент ШІ. Замість того, щоб просто запитувати, чого хочуть користувачі, увага зосереджена на розумінні їхніх внутрішніх моделей можливостей і обмежень агента. Ми повинні уникати використання слова «агент» з учасниками. Це науково-фантастичний багаж або цей термін занадто легко сплутати з людиною-агентом, що пропонує підтримку чи послуги. Натомість обговоріть «помічники» або «систему». Нам потрібно з’ясувати, де користувачі проводять межу між корисною автоматизацією та нав’язливим контролем.
Метод: попросіть користувачів описати, намалювати або розповісти про очікувану взаємодію з агентом у різних гіпотетичних сценаріях. Ключові дослідження (відображають різні галузі): Щоб зрозуміти межі бажаної автоматизації та потенційні занепокоєння щодо надмірної автоматизації, запитайте: Якщо ваш рейс скасовано, що б ви хотіли, щоб система зробила автоматично? Що б вас хвилювало, якби він зробив це без ваших чітких вказівок?
Щоб дізнатися, як користувач розуміє внутрішні процеси агента та необхідну комунікацію, запитайте: Уявіть, що цифровий помічник керує вашим розумним будинком. Якщо пакунок доставлено, які кроки, на вашу думку, потрібно виконати та яку інформацію ви очікуєте отримати?
Щоб розкрити очікування щодо контролю та згоди в рамках багатоетапного процесу, запитайте: Якщо ви попросите свого цифрового помічника запланувати зустріч, які кроки ви передбачаєте? У яких моментах ви хотіли б, щоб з вами проконсультувалися чи дали вибір?
Переваги методу: розкриває неявні припущення, висвітлює області, де запланована поведінка агента може відрізнятися від очікувань користувачів, і інформує про розробку відповідних засобів контролю та механізмів зворотного зв’язку.
Карта подорожі агента: Подібно до традиційного відображення шляху користувача, відображення шляху агента спеціально зосереджується на очікуваних діях і точках прийняття самого агента ШІ, а також на взаємодії користувача. Це допомагає завчасно виявляти потенційні підводні камені.
Метод: створіть візуальну карту, яка окреслює різні етапи роботи агента, від початку до завершення, включно з усіма потенційними діями, рішеннями та взаємодією із зовнішніми системами або користувачами. Ключові елементи для карти: Дії агента: які конкретні завдання чи рішення виконує агент? Інформаційні входи/виходи: які дані потрібні агенту та яку інформацію він створює або передає? Пункти прийняття рішень: де агент робить вибір і які критерії для цього вибору? Точки взаємодії з користувачем: де користувач вводить дані, переглядає чи затверджує дії? Точки невдач: вкрай важливо визначити конкретні випадки, коли агент міг неправильно витлумачити інструкції, прийняти неправильне рішення або взаємодіяти з неправильною сутністю. Приклади: неправильний одержувач (наприклад, надсилання конфіденційної інформації не тій особі), овердрафт (наприклад, автоматичний платіж, що перевищує доступні кошти), неправильне тлумачення намірів (наприклад, бронювання рейсу на неправильну дату через двозначне висловлювання).
Шляхи відновлення: як агент або користувач може відновитися після цих збоїв? Які існують механізми для корекції чи втручання?
Переваги методу: забезпечує цілісне уявлення про операційний потік агента, розкриває приховані залежності та дозволяє проактивно розробляти засоби захисту, обробки помилок і точки втручання користувача для запобігання або пом’якшення негативних наслідків.
Імітаційне тестування на неправильну поведінку: Цей підхід призначений для стрес-тестування системи та спостереження за реакцією користувачів, коли агент штучного інтелекту виходить з ладу або відхиляється від очікувань. Йдеться про розуміння відновлення довіри та емоційних реакцій у несприятливих ситуаціях.
Метод: у контрольованих лабораторних дослідженнях навмисно вводьте сценарії, коли агент робить помилку, неправильно інтерпретує команду або поводиться несподівано. Типи «неналежної поведінки» для імітації: КомандаНеправильне тлумачення: агент виконує дію, дещо відмінну від запланованої користувачем (наприклад, замовляє два предмети замість одного). Перевантаження/недовантаження інформації: агент надає занадто багато нерелевантної інформації або недостатньо важливих деталей. Небажана дія: агент виконує дії, яких користувач явно не хотів або не очікував (наприклад, купівля акцій без схвалення). Системний збій: агент аварійно завершує роботу, перестає відповідати або видає повідомлення про помилку. Етичні дилеми: агент приймає рішення з етичними наслідками (наприклад, визначаючи пріоритетність одного завдання над іншим на основі непередбаченої метрики).
Фокус спостереження: Реакція користувачів: як користувачі реагують емоційно (розчарування, гнів, збентеження, втрата довіри)? Спроби відновлення: які кроки роблять користувачі, щоб виправити поведінку агента або скасувати його дії? Механізми відновлення довіри: чи допомагають вбудовані механізми відновлення системи або зворотного зв’язку відновити довіру? Як користувачі хочуть отримувати інформацію про помилки? Зміна ментальної моделі: чи змінює неправильна поведінка розуміння користувачем можливостей або обмежень агента?
Переваги методу: Вирішальний для виявлення прогалин у проекті, пов’язаних із відновленням помилок, зворотним зв’язком і контролем користувача. Він дає уявлення про те, наскільки користувачі стійкі до збоїв агентів і що потрібно для підтримки або відновлення довіри, що призводить до більш надійних і поблажливих агентських систем.
Інтегруючи ці дослідницькі методології, практики UX можуть вийти за межі простого створення агентних систем придатними для використання та зробити їх надійними, контрольованими та підзвітними, сприяючи позитивним і продуктивним відносинам між користувачами та їхніми агентами ШІ. Зауважте, що це не єдині методи, які стосуються ефективного вивчення агентного ШІ. Існує багато інших методів, але вони найбільш доступні для практиків найближчим часом. Раніше я вже розповідав про метод «Чарівника країни Оз» — дещо просунутіший метод тестування концепцій, який також є цінним інструментом для вивчення концепцій агентного ШІ. Етичні міркування в методології дослідження При дослідженні агентного штучного інтелекту, особливо при моделюванні неправильної поведінки або помилок, етичні міркування є ключовими для врахування. Є багато публікацій, присвячених етичним дослідженням UX, у тому числі стаття, яку я написав для журналу Smashing, ці рекомендації від Інституту дизайну UX і ця сторінка з Inclusive Design Toolkit. Ключові показники для Agentic AI Вам знадобиться повний набір ключових показників, щоб ефективно оцінити продуктивність і надійність агентних систем ШІ. Ці показники дають уявлення про довіру користувачів, точність системи та загальну взаємодію з користувачем. Відстежуючи ці показники, розробники та дизайнери можуть визначати області для покращення та гарантувати, що агенти ШІ працюють безпечно та ефективно. 1. Рівень втручання Для автономних агентів ми вимірюємо успіх мовчанням. Якщо агент виконує завдання, а користувач не втручається або не скасовує дію протягом встановленого вікна (наприклад, 24 години), ми зараховуємо це як прийняття. Ми відслідковуємо рівень втручання: як часто людина стрибає, щоб зупинити або виправити агента? Високий рівень втручання сигналізує про розбіжність у довірі чи логіці. 2. Частота ненавмисних дій на 1000 завдань Цей критичний показник кількісно визначає кількість дій, виконаних агентом штучного інтелекту, які не були бажаними або очікуваними користувачем, нормалізовано на 1000 виконаних завдань. Низька частота ненавмисних дій свідчить про добре налагоджений ШІ, який точно інтерпретує наміри користувача та працює в межах визначених меж. Цей показник тісно пов’язаний із розумінням ШІ контексту, його здатністю усунути неоднозначність команд і надійністю його протоколів безпеки. 3. Показники відкату або скасування Цей показник відстежує, як часто користувачам потрібно скасовувати або скасовувати дію, виконану ШІ. Високі показники відкату вказують на те, що ШІ часто робить помилки, неправильно тлумачить інструкції або діє так, що не відповідає очікуванням користувачів. Аналіз причин цих відкатів може надати цінний зворотний зв’язок для вдосконалення алгоритмів штучного інтелекту, розуміння уподобань користувачів і його здатності передбачати бажані результати. Щоб зрозуміти чому, ви повинні провести мікроопитування щодо дії скасування. Наприклад, коли користувач скасовує зміну розкладу, просте запит може запитати: "Не той час? Не та людина? Або ви просто хотіли зробити це самі?" Дозволяє користувачеві вибрати варіант, який найкраще відповідає його міркуванням. 4. Час до вирішення після помилкиЦей показниквимірює тривалість, необхідну користувачеві для виправлення помилки, допущеної штучним інтелектом, або для відновлення самої системи ШІ з помилкового стану. Короткий час вирішення вказує на ефективний і зручний процес відновлення помилок, який може зменшити розчарування користувача та зберегти продуктивність. Це включає в себе легкість ідентифікації помилки, доступність механізмів скасування або виправлення та чіткість повідомлень про помилки, які надає AI.
Збір цих показників вимагає інструментів вашої системи для відстеження ідентифікаторів дій агента. Кожна окрема дія, яку виконує агент, як-от пропозиція розкладу або бронювання рейсу, має генерувати унікальний ідентифікатор, який зберігається в журналах. Щоб виміряти коефіцієнт втручання, ми не очікуємо негайної реакції користувача. Ми шукаємо відсутність протидії в межах визначеного вікна. Якщо ідентифікатор дії генерується о 9:00 ранку, і жоден користувач-людина не змінює або не скасовує цей ідентифікатор до 9:00 ранку наступного дня, система логічно позначає його як прийнятий. Це дозволяє нам кількісно оцінити успіх на основі мовчання користувача, а не активного підтвердження. Для показників відкату необроблених підрахунків недостатньо, оскільки їм бракує контексту. Щоб виявити основну причину, ви повинні застосувати логіку перехоплення для функцій Undo або Revert вашої програми. Коли користувач скасовує дію, ініційовану агентом, ініціювати легке мікроопитування. Це може бути простий модальний режим із трьома варіантами, який пропонує користувачу класифікувати помилку як фактично неправильну, бракує контексту або просте перевагу виконати завдання вручну. Це поєднує кількісну телеметрію з якісним розумінням. Це дозволяє командам інженерів розрізняти несправний алгоритм і невідповідність уподобань користувача. Ці показники, якщо їх послідовно відслідковувати та комплексно аналізувати, забезпечують надійну основу для оцінки продуктивності агентських систем штучного інтелекту, дозволяючи постійно покращувати контроль, згоду та підзвітність. Проектування проти обману Оскільки агенти стають все більш здібними, ми стикаємося з новою небезпекою: Agentic Sludge. Традиційний осад створює тертя, що ускладнює скасування підписки чи видалення облікового запису. Агентний мул діє навпаки. Це усуває тертя до помилки, тому користувачеві надто легко погодитися на дію, яка приносить користь бізнесу, а не його власним інтересам. Розгляньте можливість агента, який допоможе з бронюванням подорожі. Без чітких огорож система може віддати пріоритет авіакомпанії-партнеру або готелі з вищою прибутковістю. Він представляє цей вибір як оптимальний шлях. Користувач, довіряючи авторитету системи, приймає рекомендацію без перевірки. Це створює оманливу модель, коли система оптимізує дохід під виглядом зручності. Ризик помилково уявної компетентності Обман не може випливати зі злих намірів. Це часто проявляється в ШІ як уявна компетентність. Великі мовні моделі часто звучать авторитетно, навіть якщо є неправильними. Вони представляють неправдиве підтвердження бронювання або неточне резюме з такою ж впевненістю, як перевірений факт. Користувачі, природно, можуть довіряти цьому впевненому тону. Ця невідповідність створює небезпечний розрив між можливостями системи та очікуваннями користувачів. Ми повинні розробляти спеціально для подолання цього розриву. Якщо агенту не вдається виконати завдання, інтерфейс має чітко повідомити про це. Якщо система невпевнена, вона повинна виражати невпевненість, а не маскувати її відшліфованою прозою. Прозорість через примітиви Протиотрута як від шламу, так і від галюцинацій — це походження. Кожна автономна дія вимагає певного тегу метаданих, що пояснює походження рішення. Користувачам потрібна можливість перевірити логічний ланцюжок результату. Щоб досягти цього, ми повинні перетворити примітиви на практичні відповіді. У розробці програмного забезпечення примітиви відносяться до основних одиниць інформації або дій, які виконує агент. Для інженера це виглядає як виклик API або логічний шлюз. Для користувача це має виглядати як чітке пояснення. Завдання проектування полягає в тому, щоб зіставити ці технічні кроки з обґрунтуваннями, зрозумілими людині. Якщо агент рекомендує певний рейс, користувач повинен знати чому. Інтерфейс не може ховатися за загальною пропозицією. Він має розкривати основний примітив: Логіка: Cheapest_Direct_Flight або Логіка: Partner_Airline_Priority. Рисунок 4 ілюструє цей потік перекладу. Ми беремо необроблений системний примітив — фактичну логіку коду — і відображаємо його на рядок, який відкриває користувач. Наприклад, примітивна перевірка календарного розкладу зустрічі стає чіткою заявою: я запропонував 16:00засідання. Цей рівень прозорості гарантує, що дії агента виглядають логічними та вигідними. Це дозволяє користувачеві переконатися, що агент діяв у його інтересах. Викриваючи примітиви, ми перетворюємо чорну скриньку на скляну, гарантуючи, що користувачі залишаються остаточним авторитетом у своєму цифровому житті.
Створення основи для дизайну Побудова агентурної системи вимагає нового рівня психологічного та поведінкового розуміння. Це змушує нас вийти за рамки звичайного тестування зручності використання та перейти до сфери довіри, згоди та відповідальності. Методи дослідження, які ми обговорювали, від дослідження ментальних моделей до симуляції неправильної поведінки та встановлення нових показників, забезпечують необхідну основу. Ці практики є основними інструментами для проактивного визначення місць, де автономна система може вийти з ладу, і, що більш важливо, як відновити зв’язок між користувачем і агентом, коли це станеться. Перехід до агентського штучного інтелекту – це перевизначення відносин між користувачем і системою. Ми більше не розробляємо інструменти, які просто реагують на команди; ми розробляємо для партнерів, які діють від нашого імені. Це змінює імператив дизайну з ефективності та простоти використання на прозорість, передбачуваність і контроль. Коли штучний інтелект може забронювати авіарейс або торгувати акціями без останнього клацання, дизайн його «вхідних рамп» і «вихідних рамп» стає першорядним. Ми несемо відповідальність за те, щоб користувачі відчували себе на місці водія, навіть коли вони передали кермо. Ця нова реальність також підвищує роль дослідника UX. Ми стаємо хранителями довіри користувачів, співпрацюючи з інженерами та менеджерами з продуктів, щоб визначити та перевірити захист автономії агента. Крім того, що ми дослідники, ми стаємо прихильниками контролю користувачів, прозорості та етичних гарантій у процесі розробки. Перетворюючи примітиви на практичні питання та симулюючи найгірші сценарії, ми можемо створювати надійні системи, які є одночасно потужними та безпечними. У цій статті описано «що» і «навіщо» досліджувати агентний ШІ. Це показало, що наших традиційних наборів інструментів недостатньо і що ми повинні прийняти нові, перспективні методології. Наступна стаття базуватиметься на цьому фундаменті, надаючи конкретні шаблони проектування та організаційні практики, які роблять утиліту агента прозорою для користувачів, гарантуючи, що вони зможуть використовувати потужність агентського ШІ з упевненістю та контролем. Майбутнє UX полягає в тому, щоб зробити системи надійними. Для додаткового розуміння агентського штучного інтелекту ви можете дослідити такі ресурси:
Блог Google AI про Agentic AI Дослідження Microsoft агентів AI
