Покрокова демонстрація агентів агровиробництва
Це супровідна інструкція до живої демонстрації. Демонстрація це не відео і не презентація, а робочий кабінет агентів на даних агрокластера 42 000 га: 684 поля на пʼяти дільницях, 123 одиниці самохідної техніки, 47 авто, власний елеватор, телеметрія на агрегатах і облікова система напряму. Показані саме ті агенти, які відзначені у заявці: поле і врожай, техніка і ТО, логістика і елеватор, R&D, гроші напряму. Тут зібрані всі 16 сценаріїв і всі 84 кроків з кадрами екранів, щоб можна було подивитись зміст, не проходячи все підряд, і перейти одразу на потрібний крок.
Як користуватись демонстрацією
- Стрілки «назад» і «далі» внизу екрана або клавіші ← →. Можна тиснути прямо по підсвіченій кнопці.
- Кнопка «Кроки» показує весь сценарій, будь-який крок відкривається одним кліком.
- На кроках зі значком «можна ввести своє» приклад замінюється вашими цифрами, і крок перебудовується.
- Кнопка «Посилання» копіює адресу саме цього кроку, щоб надіслати колезі.
- Клавіша P вмикає режим презентації: ховає бічну панель і збільшує шрифт для показу на екрані.
- Місце, де ви зупинились, зберігається. Можна закрити вкладку і повернутись пізніше.
Важливо про цифри
Усі поля, борти техніки, рейси, урожайності і суми в демонстрації умовні. Це знеособлений приклад: порядок дій і екрани справжні, назву господарства ми не називаємо, цифри змінені пропорційно. Жодних реальних даних жодного клієнта тут немає. На реальному прогоні всі ці екрани заповнюються вашими цифрами.
Чому на екранах немає вартості
Це свідомо. У матеріалах для вашої групи ми ціни на екранах не показуємо. Калькулятор у сценарії 14 рахує інше: обсяг ручної роботи, який знімається, і ціну питання на вашій власній економіці. Вартість робіт ми рахуємо за заповненим брифом вертикалі і віддаємо окремим документом разом з обсягом робіт і строками.
Поле P-118: від просідання на знімку до мінус 230 грн на тонні
супутник, скаутинг, погода, захист, карта норм, телеметрія, пальне, прогноз, гроші
Що показує цей сценарій
Це наскрізний сценарій, у ньому працюють девʼять агентів з вашої заявки поспіль, на одному полі і на одному наборі даних. Показано те, що зазвичай губиться між людьми: сигнал зі знімка, підтвердження в полі, вікно на роботу, карта норм, фактичне виконання за телеметрією і те, як усе це доходить до собівартості тонни.
- Знімок оновився вночі, агент порівняв його з попереднім і з цим самим полем торік у ту саму фазу
- Поріг не «на око»: відхилення індексу понад 0,12 від медіани поля тримається третій знімок поспіль
- Решта полів дільниці у нормі, тому про них жодного повідомлення

- Хмара і тінь відсікаються порівнянням трьох знімків поспіль
- Якщо просіли всі поля культури на дільниці, це погода, а не поле
- Кожна перевірка або лишає версію, або знімає її, і це видно в журналі

- Точки не випадкові: дві в зоні просідання, дві у здоровій частині для порівняння
- Фото повертаються в той самий діалог і чіпляються до картки поля, а не губляться в чаті
- Якщо агроном не відповів до 15:00, агент нагадає йому, а не поскаржиться керівнику

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

- Обмеження беруться з регламенту препарату, а не з відчуттів: вітер до 5 м/с, температура до 25°C, 6 годин без опадів
- Агент рахує ще й пропускну здатність: скільки гектарів обприскувач фізично встигне у це вікно
- Якщо вікно не вміщує обсяг, агент так і каже і пропонує, що робити першим

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


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

- Трек, ширина захвату і швидкість беруться з телеметрії агрегата, оновлення кожні 5 хвилин
- Перекриття 12,4% означає, що препарат і паливо на цю частину витрачені двічі
- Причина не в механізаторі: секційний контроль на агрегаті вимкнений, і це видно в налаштуваннях

- Рівень у баку береться з датчика, заправки і зливи з часом і координатами
- Норма це не «як домовились», а норматив на операцію з довідника напряму
- Агент рахує і локальну цифру по полю, і що це означає в масштабі кластера за сезон


- Витрати на гектар беруться з облікової системи напряму, а не набиваються руками
- Врожай береться з прогнозу, а після 28 вересня замінюється фактом з вагової
- Різниця показана і на тонні, і на полі, бо це різні розмови з різними людьми

- Запис у журналі не можна відредагувати з інтерфейсу, тільки додати коментар
- У кожної цифри в журналі видно джерело: знімок, датчик, документ обліку або людина
- Журнал вивантажується у звичний формат і зберігається у вашому контурі

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

Підсумок
Осередок побачили 12 червня, а не в серпні на збиранні. Працювали по 38,4 га замість 214, тому втручання коштувало 84 тис. грн, а не 467. Прогноз піднявся з 9,87 до 10,45 т/га, це 124 тонни з одного поля. Собівартість тонни впала з 4 843 до 4 613 грн. Жодне рішення агент не ухвалював сам: він звузив картину до того, що людина може підтвердити за годину.
Що потрібно з вашого боку, щоб це працювало на реальних даних
- Контури 684 полів у тому вигляді, у якому вони вже є: вивантаження з системи агрообліку, KML або шейпфайл.
- Доступ до знімків по цих контурах і до даних метеостанцій, яким ви довіряєте.
- Історія робіт по полях за 2 до 3 сезонів: культура, дата, норма, агрегат, врожайність.
- Телеметрія техніки на читання: треки, мотогодини, витрата палива, ширина захвату.
- Одна людина з боку напряму, яка перші два місяці підтверджує або відхиляє висновки агента.
Тиждень агронома: 684 поля і 11 сигналів, з яких три справжні
як агент розставляє пріоритет, а не завалює сповіщеннями
Що показує цей сценарій
Найпоширеніший страх від такої системи: «нас завалить сповіщеннями». Тут показано зворотне. З 684 полів агент за тиждень віддає людині три задачі, кожну з ціною питання і строком, а решту або закриває сам, або тримає під наглядом і мовчить.
- Список формується щодня, але задачі агент віддає пакетом на початок тижня
- Кожен рядок уже має тип відхилення, а не просто «щось не так»
- Три поля позначені як нові, решта вже були на попередньому тижні

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

- Ціна зволікання рахується з динаміки пошкодження і фази культури, а не з відчуттів
- Черга це пропозиція, а не наказ: керівник дільниці міняє порядок, агент перерахує наслідки
- Якщо у вікно не вміщується все, агент прямо каже, що доведеться лишити на потім

- Повідомлення надсилається за розкладом, а критичне поза розкладом і окремо
- Кнопки під задачею це підтвердження, а не листування
- Якщо людина не відкрила повідомлення до обіду, агент нагадає один раз, а не пʼять

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

Підсумок
Агроном дільниці за тиждень отримав 3 задачі замість 11 сирих сигналів. Черга робіт вибудувана за ціною зволікання, а не за тим, хто голосніше попросив. Два сигнали агент зняв сам, ще шість тримає під наглядом без жодного повідомлення.
Що потрібно з вашого боку, щоб це працювало на реальних даних
- Пороги на кожен тип сигналу: з якого відхилення це вже задача людині. Стартові пороги ставимо ми, далі ви їх правите.
- Календар робіт напряму, щоб агент розумів, що вже стоїть у плані.
- Список відповідальних по дільницях: хто отримує задачу і хто підтверджує.
Сівозміна, 340 договорів оренди і вуглецевий слід
що сіємо наступного року, які поля ризикуємо втратити і що з цього рахує ринок
Що показує цей сценарій
Три агенти, які працюють не на тиждень, а на сезон вперед: планування сівозміни, земельний банк і вуглецевий слід. Показано, як план наступного року збирається з фактичних даних полів, а не з памʼяті, і де в цьому лежать гроші.
- Обмеження це не побажання: повернення соняшнику не раніше ніж через 4 роки, кукурудза після сої дає бонус по азоту
- Врожайність береться фактична по полю, а не середня по кластеру
- Кожен рядок плану має підставу, тому його можна оскаржити предметно

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

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

Підсумок
План сівозміни на 2027 зібрано за півдня замість двох тижнів звірок. 118 договорів оренди, за які треба боротись, підняті за три місяці до строку, а не за три тижні. Вуглецевий слід порахований за визнаною методикою, з даними, які можна показати покупцю.
Що потрібно з вашого боку, щоб це працювало на реальних даних
- Реєстр договорів оренди з датами, ставками і кадастровими номерами. Excel цілком підходить для старту.
- Історія культур по полях за 3 до 5 сезонів.
- Норми внесення і фактичні витрати палива по операціях, вони вже є в телеметрії і обліку.
Комбайн борт 03 стане на ТО 21 вересня, у розпал збирання кукурудзи
напрацювання вузлів, вікно ТО, запчастина зі строком 24 дні, підрядник
Що показує цей сценарій
Тут працюють шість агентів техніки з вашої заявки. Показано найдорожчу поломку в агровиробництві: не аварію, а планове ТО, яке за темпом напрацювання потрапляє рівно у пік збирання, і запчастину, яку треба замовити за 24 дні до того, як вона знадобиться.
- Мотогодини і напрацювання беруться з телеметрії, оновлення кожні 5 хвилин
- Готовність це не «стоїть на базі», а пройдене ТО плюс закриті заявки на ремонт
- Календар збирання агент знає, тому міряє час не в днях, а у відстані до піку

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

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


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

- Заявка створюється у вашій системі обслуговування, а не в окремому кабінеті агента
- Норми часу беруться з регламенту, факт з відмітки бригади
- Якщо на роботу немає вільної бригади у вікні, агент каже про це одразу, а не в день ТО

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

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

- Ці чотири цифри ми домовляємось міряти на старті, щоб було з чим порівнювати
- Аварійні зупинки не зникають повністю, і ми цього не обіцяємо
- Головний показник тут не «економія», а частка ТО, зроблених у вільному вікні

Підсумок
ТО перенесено у вікно 18 до 24 серпня, коли парк вільний. Ланцюг похилої камери замовлено 5 серпня, за два дні до критичної дати. Комбайн не зупинився в жнива, і це коштувало планової роботи замість аварійної, приблизно у вісім разів дешевше.
Що потрібно з вашого боку, щоб це працювало на реальних даних
- Вивантаження мотогодин і напрацювання з телеметрії або з бортових систем, на читання.
- Довідник регламентів ТО по кожній моделі: періодичність, перелік робіт, норми часу.
- Залишки складу запчастин і строки постачання по критичних позиціях.
- Календар збирання по культурах, щоб агент знав, де саме пік.
Сушарка: чому нічна зміна палить на 14% більше за ту саму тонну
енергомоніторинг обладнання, питомі витрати на тонно-відсоток
Що показує цей сценарій
Показано агента енергомоніторингу на найпростішому і найдорожчому прикладі жнив: сушіння зерна. Тут добре видно різницю між «спожили багато» і «спожили багато на тонно-відсоток», і чому без другої цифри керувати нічим.
- Тонно-відсоток це одна тонна, висушена на один відсотковий пункт, єдина порівнювана одиниця
- Маса і вологість беруться з вагової і лабораторії, а не з журналу оператора
- Споживання береться з лічильників, крок 15 хвилин

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

- Завантаження сушарки видно з ваги партій і часу роботи вузлів
- Недозавантажена сушарка палить майже стільки ж, скільки повна, тому питомі витрати ростуть
- Причина лежить не в елеваторі, а в логістиці, і це видно тільки коли дані зведені разом


- Витрати на сушіння лягають на партію, а партія на поле і культуру
- Тому ефект видно і в собівартості кукурудзи, і в собівартості конкретного поля
- Перерахунок робиться після закриття місяця, автоматично

Підсумок
Різниця між змінами знайдена за один день замість здогадок цілий сезон. Причина не в людях, а в режимі і завантаженні сушарки. Три дії дають близько 9% питомих витрат, і це відразу видно в собівартості тонни.
Що потрібно з вашого боку, щоб це працювало на реальних даних
- Лічильники газу і електроенергії по вузлах з можливістю читання, або їхнє вивантаження.
- Дані вагової: маса партії, вологість на вході і на виході.
- Журнал режимів сушарки, хоча б у тому вигляді, у якому його веде оператор.
2 236 тонн за 4 дні: маршрути, черга на вагах і 47 хвилин простою
планування рейсів, автопарк, пальне автопарку, простої під завантаженням
Що показує цей сценарій
Чотири агенти логістики з вашої заявки на одному робочому епізоді жнив. Головна думка сценарію: втрати на жнивах ховаються не в кілометрах, а в очікуванні, і побачити їх можна лише коли рейси, ваги і паливо зведені разом.

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

- Кожна складова міряється окремо за відмітками системи, а не оцінюється
- Частина простою неусувна: зважування і відбір проби займають фізичний час
- Усувна частина це те, що ми беремо в роботу, і саме на неї даємо оцінку ефекту

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

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

- Пробіг і ТО автопарку рахуються так само, як напрацювання техніки: по вузлах і від дати заміни
- Потреба в авто береться з плану збирання, а не з середнього минулого року
- Найманий транспорт агент рахує окремо, разом із строком подання

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

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

Підсумок
Простій під завантаженням з 47 хвилин доведено до 28. На жнивах кукурудзи по кластеру це 2 713 годин авто, у грошах близько 1,68 млн грн. Розбіжність по паливу на одному авто знайдена за добу, а не в кінці місяця при звірці.
Що потрібно з вашого боку, щоб це працювало на реальних даних
- Дані вагової: час заїзду і виїзду, брутто і нетто, номер авто, поле.
- GPS автопарку і перевізників на читання, з часом на точках.
- Датчики рівня палива або хоча б заправні відомості з часом і місцем.
- Норми витрати по марках авто і тарифи на години роботи.
Гібрид з дослідної ділянки: коли 0,4 т/га це справжня різниця, а коли похибка
генетика і селекція, кормова наука, наукова література
Що показує цей сценарій
Три агенти R&D з вашої заявки. Найважливіше тут не «підібрати кращий гібрид», а не помилитись: різниця в 0,4 т/га на одній ділянці часто виявляється похибкою, і рішення на 18 400 гектарів коштує дорого. Агент рахує статистику чесно і показує, коли даних ще замало.
- Повторність це та сама причина, чому одна ділянка нічого не доводить
- Агент рахує похибку досліду і мінімальну істотну різницю, а не «на скільки більше»
- Якщо схема досліду порушена, він так і пише, а не робить вигляд, що все гаразд

- Мінімальна істотна різниця це поріг, нижче якого різниця не відрізняється від випадковості
- Гібрид, який дав +0,28 т/га при похибці ±0,31, не кращий, він просто в межах шуму
- Так виглядає різниця між звітом і рішенням на 18 400 гектарів


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

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

- Агент сам звіряє висновок публікації з вашими власними даними за минулі сезони
- Якщо ваші дані суперечать публікації, він пише про це, а не приймає чужий результат на віру
- План дослідів змінює керівник R&D, агент лише готує пропозицію

Підсумок
З 24 гібридів на дослідах статистично підтверджену перевагу мають три, а не вісім, як виглядало на першій таблиці. Одна публікація змінила план дослідів на 2027 рік. Рішення про виробничі площі ухвалює агрономічна служба, агент дає лише цифри і межі довіри.
Що потрібно з вашого боку, щоб це працювало на реальних даних
- Дані дослідних ділянок: схема досліду, повторності, врожайність по кожній ділянці, а не середнє по гібриду.
- Аналізи лабораторії по зерну і кормах.
- Доступ до наукових баз, які ви вже використовуєте, або відкриті джерела.
Собівартість пшениці 4 182 замість 4 050: розкладка до документа
собівартість продукції, бюджет і план-факт, платіжний календар
Що показує цей сценарій
Три фінансові агенти вашої заявки. Пшениця вже зібрана, тому по ній є факт, а не прогноз. Показано, як відхилення у 132 гривні на тонні розкладається на причини за хвилини, і як агент підсвічує помилки в самих даних, а не тільки рахує.
- Витрати беруться з обліку напряму по замовленнях на поле і культуру
- Врожай береться з вагової, а не з форми звітності
- Розрахунок оновлюється щодня, тому цифра не чекає закриття кварталу

- Розкладка робиться на тих самих даних, з яких зібрана собівартість, тому сума завжди сходиться
- Врожайність вища за план дала мінус 34 грн на тонні, і агент це показує, а не ховає
- Кожен драйвер можна розкрити до документів, це наступний крок

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

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


- Календар збирається з графіка платежів, зобовʼязань і очікуваних надходжень
- Агент рахує не «в середньому за місяць», а по днях, бо розрив це завжди про конкретну дату
- Він показує розрив за 7 днів, а не в день платежу, і це головна цінність

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

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

Підсумок
Відхилення 5,3 млн грн розкладено на шість драйверів, кожен розкривається до документів. Дві помилки в даних знайдені до того, як цифра пішла у звіт. Касовий розрив 11 до 13 серпня побачили за тиждень, а не в день платежу.
Що потрібно з вашого боку, щоб це працювало на реальних даних
- Доступ до облікової системи напряму на читання: витрати по замовленнях на поле і культуру.
- Бюджет напряму у тому вигляді, у якому він затверджений.
- Графік платежів і залишки на рахунках напряму, хоча б вивантаженням.
- Правила, за якими ви розподіляєте непрямі витрати на культуру. Якщо правил немає, зафіксуємо їх разом.
Звідки агент бере дані і що буде, якщо джерело мовчить
системи, датчики, файли, люди: що читаємо, що пишемо, з якою частотою
Що показує цей сценарій
Найчастіше питання після демонстрації: «а звідки він це бере». Тут перелічені всі джерела показаних сценаріїв, з чесною поміткою, де агент лише читає, де пише, і що відбувається, коли джерело недоступне.
- Колонка «читає або пише» тут найважливіша: на старті агент нічого не пише у ваші системи
- Частота це не «в реальному часі», а конкретний інтервал, який ми узгоджуємо
- Для старту достатньо частини джерел, повний список це горизонт, а не умова

- Мінімум підбирається під ту вертикаль, з якої стартуємо
- Кожне наступне джерело додає точності, але не блокує роботу
- Якщо якогось джерела немає взагалі, агент рахує без нього і позначає це в результаті

- Агент ніколи не домальовує дані, яких немає, і не бере «приблизно як учора»
- Кожна діра в даних видно на екрані, а не ховається в середньому значенні
- Якщо через дірку висновок стає ненадійним, агент не дає висновку взагалі

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

Підсумок
Видно, що більшість даних уже пишеться у вас, і нового обладнання для старту не потрібно. Найслабше місце не інтеграція, а якість довідників: контури полів і норми по операціях.
Що потрібно з вашого боку, щоб це працювало на реальних даних
- Технічний користувач з правами на читання у кожній системі зі списку.
- Рішення, як віддаємо дані: API або регулярне вивантаження. Для старту вистачає вивантаження.
- Відповідальний з боку ІТ, з яким узгоджуємо доступи.
Під капотом: журнал, у якому видно кожну цифру і її джерело
що саме робив агент, коли, на яких даних і хто це підтвердив
Що показує цей сценарій
Показано, чим агент відрізняється від чорної скриньки. Кожна дія лежить у журналі з часом, підставою і джерелом, а кожну цифру на екрані можна розкрити до документа або до датчика.
- Записи не редагуються з інтерфейсу, можна лише додати коментар
- Записи агента і рішення людей лежать в одному журналі, тому видно всю картину
- Журнал вивантажується у звичний формат для аудиту

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

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

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

- Стартові пороги ми ставимо з досвіду і одразу показуємо вам
- Кожен поріг має і числове значення, і адресата, тому ясно, кому це прилетить
- Зміна порогу фіксується в журналі: хто і коли змінив

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

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

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

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

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

Підсумок
Видно, що навчання це не «модель сама щось запамʼятала», а конкретний список правил з автором, датою і підставою. Будь-яке правило можна вимкнути, і все повернеться як було.
Що потрібно з вашого боку, щоб це працювало на реальних даних
- Домовитись, хто має право підтверджувати правила по кожній вертикалі. Зазвичай це один-два фахівці.
- Домовитись про періодичний перегляд правил, раз на квартал вистачає.
Як ми тестуємо агента до того, як він побачить ваші робочі дані
історичні дані, сліпа перевірка, паралельний режим, приймання
Що показує цей сценарій
Показано, що між «агент готовий» і «агент працює у вас» стоїть чотири етапи перевірок. Головний з них: агент рахує на історії сезону, який ви вже прожили, і його результат порівнюється з тим, що сталось насправді.
- Етапи йдуть послідовно, і кожен має критерій виходу
- На двох перших етапах агент взагалі не бачить поточних даних
- Паралельний режим це найчесніша перевірка: агент і люди працюють одночасно і незалежно

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

- У паралельному режимі агент нікому не заважає: люди працюють як звикли
- Щодня формується коротке порівняння: що побачив агент, що побачили люди
- Приймання це чек-лист із цифрами, який ви підписуєте, а не демонстрація

Підсумок
Ви отримуєте не обіцянку точності, а цифру на своїх власних даних: скільки подій агент знайшов би, скільки пропустив, скільки разів помилився. Приймання підписується за цим числом, а не за враженням.
Що потрібно з вашого боку, щоб це працювало на реальних даних
- Історичні дані за один-два минулі сезони, у будь-якому вигляді, який у вас є.
- Перелік подій минулого сезону, які ви вважаєте важливими: що сталось, коли помітили, чим закінчилось.
- Дві-три людини з боку напряму на приймання, по 2 до 3 годин на тиждень протягом пілота.
Ваші обсяги: скільки роботи знімається і яка ціна питання
живий калькулятор на ваших гектарах, полях і техніці
Що показує цей сценарій
Тут немає нашої вартості, і це навмисно: у матеріалах для вашої групи ми ціни не показуємо. Калькулятор рахує інше, і насправді важливіше: скільки ручної роботи знімається і яка ціна питання на вашій власній економіці.
- Перевірок поля за сезон це те, що агент робить замість обходів і телефонних дзвінків
- Години ручного збору даних це оцінка за нашим досвідом схожих контурів, її можна перевірити у себе
- Останній повзунок навмисно ваш: ставте обережну цифру, а не нашу

- Вартість залежить від обсягу, кількості агентів і того, як влаштовані ваші дані
- Чесна цифра зʼявляється після брифу, а не до нього
- Бриф це 30 до 35 питань чіпами, після нього ми даємо розрахунок і строки

Підсумок
Ви бачите обсяг роботи агента у ваших цифрах і можете самі перевірити, чи лишається сенс при обережних припущеннях. Вартість ми рахуємо за заповненим брифом під конкретну вертикаль і віддаємо окремо.
Що потрібно з вашого боку, щоб це працювало на реальних даних
- Заповнений бриф вертикалі, з якої починаємо. Це 30 до 35 питань чіпами, займає близько 15 хвилин.
- Ваші реальні обсяги: гектари, поля, техніка, рейси. Вони і є основою розрахунку вартості.
Що потрібно від вас: готовий список для вашого ІТ
доступи, дані, люди, строки. Один екран, який можна переслати
Що показує цей сценарій
Цей екран зроблений так, щоб його можна було переслати своєму ІТ і отримати відповідь по кожному пункту. Ніяких загальних слів на кшталт «потрібна інтеграція»: конкретні системи, конкретні права, конкретні люди.
- На старті всі доступи тільки на читання, без винятків
- Технічний користувач окремий, іменний, з обмеженим набором обʼєктів
- Запис зʼявляється тільки після пілота і тільки на ті обʼєкти, які ви явно дозволите

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

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

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

Підсумок
Після цього списку у вас є все, щоб оцінити роботу зі свого боку. Мінімальний старт це три доступи і одна людина, решта підключається поетапно.
Що потрібно з вашого боку, щоб це працювало на реальних даних
- Відповідальний з боку ІТ, який зведе доступи.
- Відповідальний з боку напряму, який підтверджує висновки агента перші два місяці.
- Рішення про контур: наша інфраструктура чи ваша.
Безпека: що виходить за периметр, що ні і на яких умовах
контур розгортання, знеособлення, доступи, NDA, воєнні ризики
Що показує цей сценарій
Відповідь на питання, яке зазвичай ставить не бізнес, а безпека і ІТ. Показано три варіанти контуру, що саме передається у кожному з них і що робиться з даними, які взагалі не мають виходити назовні.
- Варіант 3 дорожчий і повільніший на старті, але повністю закритий
- Більшість розрахунків узагалі не потребує мовної моделі, тому в закритому контурі втрачається небагато
- Вибір робиться один раз на старті і фіксується в договорі

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

- Агент має працювати, коли немає світла і звʼязку, інакше він марний саме тоді, коли найпотрібніший
- Координати полів і треки техніки це чутливі дані, і поводитись з ними треба відповідно
- Ці речі закладаються в рішення на старті, а не дописуються потім

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