{
  "slug": "armia-agentnykh-tsykliv",
  "url": "https://neurodrift.org/blog/armia-agentnykh-tsykliv/",
  "title": "Після промпту: народження армії агентних циклів",
  "description": "Промпт більше не головна зброя роботи з AI. Головною стає цикл: контекст, агент, інструменти, артефакт, перевірка, пам'ять, повторення. Та сама архітектура, що в дронах Мадяра — тільки в коді.",
  "author": "Дністер",
  "language": "uk-UA",
  "published": "2026-05-16T07:00:00.000Z",
  "updated": null,
  "category": {
    "id": "ai",
    "label": "AI",
    "labelEn": "AI"
  },
  "tags": [
    "AI",
    "агенти",
    "Claude Code"
  ],
  "hasEnglish": true,
  "englishUrl": "https://neurodrift.org/en/blog/armia-agentnykh-tsykliv/",
  "sourceUrl": null,
  "body": "> Ще пів року тому головним героєм роботи з AI був користувач, який шукав правильне формулювання. У травні 2026-го це вже не так. Виграє не той, хто красивіше пише промпт, а той, хто швидше замикає цикл: контекст, агент, інструменти, артефакт, перевірка, пам'ять, повторення. Це нова операційна логіка — і дуже знайома.\n\n## Чат більше не виглядає як чат\n\nЩе недавно взаємодія з AI виглядала просто.\n\nТи відкривав ChatGPT або Claude. Писав запит. Чекав. Копіював текст. Виправляв. Знову писав. Знову чекав. Знову копіював.\n\nЦе була **епоха промпту**.\n\nУ ній центральним героєм був користувач, який намагався знайти правильне формулювання. *«Напиши як senior developer»*. *«Дій як McKinsey consultant»*. *«Постав мені 10 уточнювальних питань»*. *«Не галюцинуй»*. *«Будь точним»*. *«Пиши без води»*. *«Think step by step»*.\n\nЦе справді працювало. Певний час.\n\nАле в травні 2026 року стало видно, що ця логіка вже застаріває. Не тому, що prompt engineering зник — він залишився як один із шарів. А тому, що він перестав бути центром системи.\n\nТепер головне питання вже не *«як сформулювати запит?»*.\n\nВоно інше:\n\n<aside class=\"pullquote\"><p><strong>Як побудувати середовище, у якому AI стабільно виконує роботу, не губить контекст, не ламає продукт і не змушує людину по колу повторювати одне й те саме?</strong></p></aside>\nЦе вже не чат. Це **операційна система**.\n\nOpenAI 5 травня викотив у ChatGPT *memory sources* — можливість бачити, які саме saved memories, минулі чати, custom instructions, файли або підключений Gmail вплинули на відповідь. Пам'ять перестає бути містичним чорним ящиком і стає видимим робочим шаром. <sup>[[1]](#src-openai-memory)</sup>\n\nЗа дев'ять днів OpenAI викотив **Codex у мобільний ChatGPT**. І тут важлива не сама «мобілка». Важливо інше: Codex тепер можна вести як живого віддаленого працівника. З телефону можна бачити активні threads, project context, screenshots, terminal output, diffs, test results, approvals, перемикати моделі або запускати нову задачу. Понад **4 мільйони людей** уже використовують Codex щотижня. <sup>[[2]](#src-openai-codex-mobile)</sup>\n\nЦе радикальна зміна UX.\n\nAI більше не сидить у чаті й не чекає одного ідеального запиту. Він **працює в середовищі**. Бачить файли. Запускає тести. Пише diff. Чекає approve. Має hooks. Підключається по Remote SSH. Залишає сліди.\n\nПромпт стає лише кнопкою запуску.\n\nРобота відбувається в **циклі**.\n\n## Кінець магічного промпту\n\nУ старій епосі prompt engineering був схожий на шаманство.\n\nЛюди збирали «ідеальні промпти». Колекції команд. Ролі. Секретні формули. Markdown-шаблони. «Ultimate Claude Code prompt». «Best ChatGPT prompt for developers». «One prompt to build your SaaS».\n\nЦе було природно. Коли інструмент новий, люди намагаються керувати ним мовою.\n\nАле з часом стало ясно: **один великий prompt — це поганий спосіб управляти складною роботою**.\n\nВеликий prompt легко роздувається. Він суперечить сам собі. Він змішує правила, контекст, цілі, винятки, стиль, технічні обмеження, історію, безпеку й формат відповіді. Він стає не інструкцією, а сміттєвим баком.\n\nІ найгірше: він не масштабується.\n\nОдин prompt може допомогти написати текст, виправити функцію або пояснити помилку. Але він погано тримає довгий процес:\n\n- дослідити тему;\n- зібрати джерела;\n- створити структуру;\n- написати код;\n- розгорнути на сервері;\n- перевірити;\n- отримати фідбек;\n- внести правки;\n- оновити пам'ять;\n- зробити наступну версію.\n\nУ такому процесі prompt — лише **один шар**. Поруч із ним є контекст, пам'ять, tools, hooks, permissions, runtime, evals, logs, sandboxes, human approvals.\n\nDataHub у квітні сформулював це прямо: prompt engineering оптимізує те, як ти **формулюєш** інструкцію, а context engineering управляє всім **інформаційним середовищем**, у якому працює модель. У їхньому дослідженні **82% IT і data-leaders** сказали, що prompt engineering alone вже недостатній для AI at scale, а **95% вважають context engineering важливим** для масштабування агентів. <sup>[[3]](#src-datahub-context)</sup>\n\n<aside class=\"pullquote\"><p><strong>Prompt engineering питає: «Як мені це сказати?» Context engineering питає: «Що модель має знати саме зараз?»</strong></p></aside>\nРізниця величезна.\n\nУ першому випадку людина шліфує формулювання. У другому — будує систему доставки правильного контексту в правильний момент.\n\nЦе як різниця між красивим наказом і нормальною логістикою. Генерал може написати ідеальний наказ. Але якщо карта стара, зв'язок зламаний, підрозділ не знає місцевість, паливо не доїхало, а штаб не бачить фронт — наказ нічого не вартий.\n\nТак само з AI. Модель може бути дуже розумною. Prompt може бути красивим. Але якщо контекст поганий, пам'ять шумна, tools невпорядковані, а approval logic не визначена — система буде ламатися.\n\n## Нова формула сили: не модель, а цикл\n\nСтара AI-логіка мислила платформами.\n\nGPT. Claude. Gemini. Llama. Grok. DeepSeek. ([Який саме фронтір-моделі підбирати під яке завдання](/blog/cg4kpsh9r1-yaku-model-sh-vibrati-dlya-vashogo-zavda/) — окрема стаття, бо ландшафт швидко змінюється.)\n\nНова логіка мислить циклами.\n\n```text\nнамір\n  → контекст\n  → агент\n  → інструменти\n  → артефакт\n  → перевірка\n  → фідбек\n  → пам'ять\n  → наступна ітерація\n```\n\nУ старій логіці ти питав: *«Яка модель найкраща?»*\n\nУ новій логіці треба питати:\n\n- як агент отримує контекст?\n- які tools він може викликати?\n- де він має право писати?\n- коли він має зупинитися?\n- що він логуватиме?\n- хто approve-ить ризикові дії?\n- як результат перетворюється на наступний цикл?\n- що з цього зберігається в пам'ять?\n- які помилки стають eval tests?\n\nЦе вже не магія відповіді. Це **інженерія повторення**.\n\nLangChain у звіті *State of Agent Engineering* пише, що **57.3%** опитаних уже мають агентів у production, ще **30.4%** активно розробляють агентів із планами deploy. Найбільший production-блокер — якість, її назвали **32% респондентів**. Observability уже впровадили **89%** організацій, тоді як evals мають лише **52.4%**. <sup>[[4]](#src-langchain-state)</sup>\n\nЦі цифри показують одну річ: агенти вже не демо. Вони стали робочою інфраструктурою. І тепер головний біль — не *«як змусити модель щось написати»*, а **як зробити її роботу надійною**.\n\n<aside class=\"pullquote\"><p><strong>AI більше не треба вражати. AI треба контролювати.</strong></p></aside>\n## Codex у кишені: агент як віддалений працівник\n\nOpenAI назвав травневий реліз просто: «Work with Codex from anywhere».\n\nФормально це мобільний доступ до Codex у ChatGPT app. Але культурно це зовсім інше — це перший масовий образ AI coding agent як **процесу, який не закінчується відповіддю в чаті**.\n\nТи запускаєш задачу на ноутбуці, Mac mini або devbox. Агент працює у твоєму середовищі. Він бачить project context. Запускає команди. Виводить terminal output. Створює diff. Робить screenshots. Запускає tests. Питає дозволу.\n\nТи в цей момент можеш бути в таксі, на прогулянці, у спортзалі або між дзвінками — і з телефону дати йому рішення.\n\nЦе не *«писати код на телефоні»*. Це **керувати циклом виконання з телефону**.\n\nOpenAI прямо пише: маленький check-in може не дати роботі зупинитись, уникнути unnecessary rework або допомогти Codex рухатись із правильним контекстом. Звідси і набір дій: review outputs, approve commands, change models, start something new. <sup>[[2]](#src-openai-codex-mobile)</sup>\n\nЦе дуже важливий момент для всіх, хто працює з AI.\n\nЛюдина більше не сидить перед моделлю як оператор текстового поля. Людина стає **диспетчером довгих задач**.\n\n```text\nлюдина:\n  ставить намір\n  дає обмеження\n  ухвалює рішення\n  перевіряє результат\n\nагент:\n  читає код\n  викликає tools\n  пробує варіанти\n  створює артефакт\n  повертає evidence\n```\n\nЦе новий rhythm. Не *«один запит — одна відповідь»*. А *«одна задача — багато мікровтручань»*.\n\nУ цьому сенсі смартфон стає не пристроєм для споживання AI, а **пультом управління агентом**.\n\n## Claude Code і проблема довгих циклів\n\nAnthropic теж рухається не просто в бік розумнішої моделі, а в бік **довшого execution loop**.\n\n6 травня Anthropic подвоїв п'ятигодинні Claude Code rate limits для Pro, Max, Team і seat-based Enterprise планів, прибрав peak-hours limit reduction для Claude Code на Pro і Max, а також суттєво підняв API limits для Opus models. У тому ж релізі — partnership зі SpaceX, що дає доступ до понад **300 MW нової capacity і понад 220 000 NVIDIA GPUs** протягом місяця. <sup>[[5]](#src-anthropic-claude-code-limits)</sup>\n\nЦі цифри звучать як infrastructure news. Але насправді це новина про UX.\n\nЧому AI coding tools так швидко впираються в ліміти?\n\nБо агентна розробка спалює не «повідомлення». Вона спалює **цикли**.\n\nАгент читає репозиторій. Шукає файли. Пробує патч. Запускає тести. Отримує помилку. Читає лог. Переписує. Запускає знову. Робить diff. Дає summary. Чекає людини. Продовжує.\n\nЦе довга сесія. Може тривати хвилини або години.\n\nLangChain описує це так: long-running agents потребують durable execution, memory, multi-tenancy, human-in-the-loop і observability. Агент може працювати хвилини або години, чекати human approval, переживати deploy або crash, і **не втрачати прогрес**. <sup>[[6]](#src-langchain-deep)</sup>\n\nТобто справжній bottleneck — не тільки intelligence.\n\nСправжній bottleneck — **тривалість і надійність циклу**.\n\nЯкщо агент не може працювати довго, він залишається autocomplete.\n\nЯкщо може працювати довго, зберігати стан, питати дозволу, відновлюватися і залишати audit trail — він стає **працівником системи**.\n\n## Control plane: де насправді йде нова війна\n\nVentureBeat 15 травня дуже точно назвав наступний фронт: не model war, а **agent control plane**.\n\nІдея проста: компанії вже не просто обирають, яка модель відповідає краще. Вони обирають, **де житиме операційна машина AI**: у Microsoft stack, OpenAI API layer, Anthropic managed runtime, open framework або hybrid mix.\n\nЗа VB Pulse, у лютому 2026 Microsoft Copilot Studio і Azure AI Studio мали **38.6% primary-platform adoption** серед enterprise agent orchestration respondents, OpenAI Assistants і Responses API — **25.7%**, Anthropic tool use and workflows — **5.7%** (вибірка маленька, тож VB прямо застерігає від перебільшення). <sup>[[7]](#src-vb-controlplane)</sup>\n\nАле навіть із цією обережністю сигнал сильний.\n\nМодель можна змінити. Control plane змінити складніше. Бо саме там живуть:\n\n- permissions;\n- memory;\n- tools;\n- approvals;\n- logs;\n- auditability;\n- sandboxing;\n- integrations;\n- cost controls;\n- security policies;\n- workflow state.\n\nУ старій AI-логіці vendor lock-in був на рівні моделі. У новій — він на рівні **runtime**. Це набагато глибше.\n\nЯкщо твоя команда зберігає workflows, permissions, memory, hooks і agent tasks в одному середовищі, ти вже не просто «користуєшся моделлю». Ти будуєш **операційну тканину** навколо неї.\n\nНе *«який LLM найрозумніший?»*. А *«де живе моя робота?»*.\n\n## RAG більше не достатній\n\nЩе один зсув: класичний RAG перестає бути універсальною відповіддю.\n\nКілька років тому було модно казати: *«Підключимо документи до vector database, і агент усе знатиме»*.\n\nАле agentic workflows швидко показали слабкість цього підходу.\n\nКоли агент працює в довгому циклі, йому потрібен не просто **пошук** документів. Йому потрібна **скомпільована структура знання**: що є джерелом істини, як пов'язані сутності, які є permissions, які дані stale, який формат потрібен для наступного tool call, що можна викинути з context window.\n\nVentureBeat 4 травня описав це як перехід від RAG pipeline до compilation-stage knowledge layer. У прикладі Pinecone Nexus один financial analysis task, який раніше споживав **2.8 млн токенів**, був виконаний із **4 000 токенів** — заявлене скорочення на **98%** (це внутрішній benchmark Pinecone, ще не customer-validated). <sup>[[8]](#src-vb-knowledge)</sup>\n\nНавіть якщо ставитися до цифри обережно, напрям очевидний.\n\nМайбутнє не в тому, щоб закидати модель більшим context window. Майбутнє в тому, щоб давати їй **менший, чистіший, структурованіший контекст**.\n\n```text\nпогано:\n  усі документи\n  вся історія\n  всі інструкції\n  весь шум\n\nкраще:\n  релевантні факти\n  поточний стан\n  чіткі constraints\n  потрібні tools\n  коротка пам'ять\n  evidence links\n```\n\nВеликий контекст без дисципліни — це не сила. Це сміття з великим лімітом.\n\n<aside class=\"pullquote\"><p><strong>Context window — це не архів. Це оперативна пам'ять агента.</strong></p></aside>\nІ якщо в цю пам'ять потрапляє шум, агент деградує **ще до того**, як у нього закінчаться токени.\n\n## GitHub показав, як не плодити агентів\n\nОдин із найкращих практичних прикладів тижня — GitHub accessibility agent.\n\n15 травня GitHub описав експеримент із general-purpose accessibility agent. Його задача — відповідати на accessibility questions у Copilot CLI та VS Code integration, а також ловити й автоматично виправляти прості, об'єктивні accessibility issues **до production**. Агент уже переглянув **3 535 pull requests** і має **68% resolution rate**. <sup>[[9]](#src-github-a11y)</sup>\n\nАле найцікавіше не це. Найцікавіше — **архітектура**.\n\nGitHub спершу мав monolithic agent, але він швидко вперся в межі. Команда перейшла до sub-agent architecture. Багато гідів радять робити **цілий зоопарк агентів**, але GitHub виявив, що це працює гірше. Вони залишили **лише двох**:\n\n1. passive reviewer / researcher;\n2. active implementer.\n\nВони sandboxed і не передають content напряму один одному. Натомість кожен створює **structured, templatized output**, який parent orchestrating agent споживає, перевіряє і маршрутизує.\n\n```text\norchestrator\n  → reviewer\n  → structured findings\n  → orchestrator validates\n  → implementer\n  → changes or guidance\n  → re-audit\n```\n\nТут видно нову культуру AI workflow.\n\nАгенти **не мають «спілкуватися як люди»**. Це звучить мило, але швидко створює хаос. Їм треба передавати структуровані артефакти.\n\nGitHub прямо пише, що без template schema агенти починали б довільно комунікувати, що створює higher token expenditure, hallucinations, unnecessary code changes і **майже неможливий audit**. <sup>[[9]](#src-github-a11y)</sup>\n\n<aside class=\"pullquote\"><p><strong>Не давай агентам балакати. Давай їм схеми передачі роботи.</strong></p></aside>\nЩе важливіше — GitHub ввів **complexity-based behavior**. Якщо код занадто складний, агент не має права генерувати зміни. Він переходить у guidance-only mode або ескалює людині. Також є high-risk patterns, де агенту **заборонено писати код**: drag and drop, toasts, rich text editors, tree views, data grids.\n\nЦе mature agent design. AI не повинен завжди діяти. Іноді найкраще, що може зробити агент, — **зупинитися**.\n\n## Межа автоматизації: 36% не піддається\n\nУ тому ж матеріалі GitHub дає ще одну сильну цифру.\n\nІз **55 WCAG level A and AA Success Criteria** лише **35** можуть бути виявлені deterministic automated code checkers. Тобто приблизно **36% критеріїв** вимагають manual evaluation. <sup>[[9]](#src-github-a11y)</sup>\n\nЦе не просто accessibility-факт. Це модель реальності для **будь-яких AI workflows**.\n\nУ кожній складній сфері є частина, яку можна автоматично перевірити. І є частина, де потрібен **людський judgment**.\n\n```text\nавтоматизується:\n  синтаксис\n  тести\n  очевидні помилки\n  формат\n  повторювані патерни\n  частина compliance\n\nпотребує judgment:\n  UX\n  репутаційний ризик\n  етична неоднозначність\n  контекст клієнта\n  стратегічний компроміс\n  смислова якість\n```\n\nПроблема багатьох AI-систем у тому, що вони поводяться так, ніби 100% реальності можна перетворити на tool call. Це неправда.\n\nСильна AI-архітектура **не заперечує** людський judgment. Вона ставить його в **правильну точку циклу**.\n\n## Human-in-the-loop — це не QA в кінці\n\nСтаре уявлення про human-in-the-loop виглядало так: AI щось робить, людина перевіряє, approve або редагує. Це слабка модель.\n\nСильніша модель: людина не просто перевіряє output. Людина **формує траєкторію**.\n\nLangChain описує agent improvement loop як процес, у якому команда швидко створює першу версію агента, запускає її в production-like середовище, збирає дані, аналізує outputs і eval scores, а людський feedback впливає на context engineering та наступні ітерації. <sup>[[10]](#src-langchain-improvement)</sup>\n\nТобто людина не редактор після моделі. Людина — **тренер циклу**.\n\nВона бачить, де агент плутається. Яких джерел не вистачає. Де треба стиснути контекст. Де додати приклад. Де заборонити дію. Де потрібен escalation gate. Де помилку треба перетворити на тест.\n\n```text\nrun\n  → failure\n  → human judgment\n  → eval case\n  → context patch\n  → workflow patch\n  → next run\n```\n\nЦе ключ до зменшення wasted iterations. Не просити модель *«бути кращою»*. А брати **кожен збій** і перетворювати його на новий елемент системи.\n\n## Hooks: правила переїжджають із промпту в runtime\n\nOpenAI у Codex-релізі підкреслив: **Hooks тепер generally available** на всіх планах. Їх можна використовувати для secret scanning, validators, conversation logging, memory creation або repo-specific behavior customization. <sup>[[2]](#src-openai-codex-mobile)</sup>\n\nClaude Code теж рухається у цю саму логіку. У документації Claude Code за квітень-травень видно цілу хвилю runtime primitives: **Routines, `/usage`, `/ultrareview`, effort levels, hooks, monitor tools, permission logic, sandbox rules**. Routines запускають templated cloud agents за schedule, GitHub event або API call. `/usage` показує, що саме споживає ліміти. `/ultrareview` запускає parallel multi-agent analysis і adversarial critique pass для code review. <sup>[[13]](#src-claude-runtime)</sup>\n\nЦе означає, що правила дедалі більше переїжджають **із prompt у runtime**.\n\nНе треба писати в prompt:\n\n*«Будь ласка, не видаляй важливі файли, не пуш секрети, не міняй production configs, не роби небезпечні Bash-команди, не генеруй код у high-risk zones»*.\n\nЦе треба кодувати в **hooks, policies, deny-lists, validators і approval gates**.\n\n<aside class=\"pullquote\"><p><strong>Промпт просить. Runtime змушує.</strong></p></aside>\nЦе фундаментальна різниця.\n\nGitHub 13 травня також викотив **Agent tasks REST API** для Copilot cloud agent у public preview. Copilot Business і Enterprise користувачі можуть програмно запускати cloud agent tasks. Агент працює у власному development environment, може робити й валідувати code changes, а потім відкривати pull request. GitHub наводить сценарії: fan out refactors across repositories, one-click repo setup з internal developer portal, weekly release preparation із release notes. <sup>[[12]](#src-github-restapi)</sup>\n\nЦе ще один крок від чату до **інфраструктури**. Коли агент запускається через REST API, він стає не помічником у вікні, а **частиною pipeline**.\n\n## Sakana Conductor: маленький менеджер сильніший за великого генія\n\nНайінтелектуальніший сигнал останніх тижнів — робота Sakana AI про *Conductor*.\n\nІдея майже елегантна: не тренувати ще одну модель, яка сама вирішує все. Навчити **маленьку модель керувати іншими моделями**.\n\nSakana описує **7B Conductor model**, trained with reinforcement learning, який оркеструє пул frontier models — GPT-5, Gemini, Claude і open-source models. Він не пише код безпосередньо. Він вирішує: кого викликати, яке підзавдання дати, який контекст показати, як зібрати workflow. Для простих factual questions він може викликати одну модель. Для складних coding problems — створює planner-executor-verifier pipeline. <sup>[[14]](#src-sakana-conductor)</sup>\n\nРезультати сильні: у paper Conductor показує **83.93 на LiveCodeBench**, **93.3 на AIME25**, **87.5 на GPQA-Diamond** і середній **77.27**, перевищуючи окремі worker models у цьому setup. <sup>[[15]](#src-sakana-benchmark)</sup>\n\nЦе дуже важлива метафора для всієї AI-епохи.\n\nМайбутнє може належати не найбільшій моделі. А **найкращому координатору**.\n\n```text\nвелика модель:\n  розв'язує задачу сама\n\nconductor:\n  розбиває задачу\n  вибирає агентів\n  обмежує контекст\n  запускає перевірку\n  збирає фінальний результат\n```\n\nЦе схоже на команду. Найсильніший керівник не обов'язково сам найкращий дизайнер, програміст, аналітик і редактор. Його сила — **знати, кого коли підключити**, що кому доручити, яку інформацію дати, коли зупинити й як зібрати результат.\n\nAI починає навчатися не тільки відповідати. AI починає навчатися **менеджменту**.\n\n## Але не кожен workflow потребує агента\n\nТут важливо не впасти в протилежну дурість.\n\nЯкщо prompt engineering переоцінювали, то тепер є ризик переоцінити agents.\n\nMartin Fowler 14 травня опублікував думку James Pritchard: багато «agent use cases» насправді є просто **workflows** — відомими послідовностями кроків, де один або два кроки включають LLM. Якщо workflow відомий, часто не потрібна автономія. Потрібен function call. <sup>[[16]](#src-fowler-workflows)</sup>\n\nЦе болюче, але правильне. Не все треба перетворювати на агента.\n\nЯкщо процес стабільний — кодуй процес. Якщо кроки відомі — зроби pipeline. Якщо треба витягнути дані, класифікувати, переформатувати, перевірити шаблон — це часто **функція з LLM-викликом всередині**.\n\nАгент потрібен там, де є: невизначеність, пошук, branching, tool use, довгий контекст, проміжні рішення, потреба в human approval, змінна траєкторія.\n\n```text\nвідомий шлях → workflow\nневідомий шлях → agent\nвисокий ризик → human gate\nповторюваний патерн → automation\n```\n\nПроста матриця, але вона рятує від **over-agenting**.\n\n## Економіка агентів: підписки більше не бездонні\n\nЩе один неприємний, але важливий сигнал — **billing**.\n\nZed 14 травня пояснив, що Anthropic із 15 червня розділяє Claude subscription billing на два пули: first-party Claude tools і third-party agent / SDK usage. Для third-party agent usage через ACP, `claude -p` та інші інструменти вводиться **Agent SDK credit**: $20 для Pro, $100 для Max 5x, $200 для Max 20x. Після вичерпання credit — usage за API rates або зупинка requests. <sup>[[17]](#src-zed-billing)</sup>\n\nЦе не просто pricing drama. Це **кінець all-you-can-eat ілюзії** для heavy agent workflows.\n\nКоли людина пише 30 повідомлень у чаті, це одна економіка. Коли агент запускає десятки tool calls, читає репозиторій, робить subagent analysis, тримає long context і повторює тести — це **зовсім інша економіка**.\n\nAgentic work дорого коштує, бо це не *«відповідь»*. Це **compute-loop**.\n\n- Поганий контекст = більше токенів.\n- Поганий prompt = більше retries.\n- Погані tools = більше помилкових дій.\n- Погані evals = більше людського review.\n- Поганий runtime = більше обривів.\n- Погана пам'ять = кожен запуск із нуля.\n\nУсе це коштує. Не метафорично. Буквально.\n\n## Voice-to-artifact: наступна природна форма роботи\n\nНайцікавіше, що ця логіка вже починає виглядати дуже **природно** в реальній роботі.\n\nЛюдина говорить у мікрофон. Claude Code або Codex отримує задачу. Створює HTML, landing page, script, database migration, Telegram bot, research document. Завантажує на сервер. Людина дивиться результат. Голосом дає правки. AI змінює. Знову deploy. Знову feedback. Усе документується в `.md` файлах, project memory, agent instructions, changelog.\n\nЦе вже нормальний режим роботи для людей, які живуть у fast iteration.\n\n```text\nvoice\n  → agent\n  → artifact\n  → deploy\n  → inspect\n  → correction\n  → memory\n  → next version\n```\n\nМислення перестає бути відділеним від виробництва.\n\nРаніше між ідеєю і артефактом було багато тертя: сісти, сформулювати, написати ТЗ, передати розробнику, чекати, отримати, пояснити правки, знову чекати.\n\nТепер voice interface стискає цей цикл. **Ідея переходить у продукт майже напряму**.\n\nАле саме тому стає критичною структура. Якщо не формалізувати цей loop, він швидко перетвориться на хаос: різні сесії, різні агенти, втрачений контекст, дублікати, погано записані рішення, *«а чому ми це зробили?»*, *«де остання версія?»*, *«який prompt працював?»*.\n\nТому новий стек має мати **пам'ять**. Не романтичну. Технічну:\n\n```text\n/project.md      що це, ціль, користувачі, домен, деплой\n/decisions.md    ключові рішення, чому, що не робити\n/workflows.md    як запускати, деплоїти, перевіряти, відкочувати\n/agents.md       ролі, constraints, tools, escalation rules\n/evals.md        типові помилки, acceptance criteria, regressions\n```\n\nЦе не бюрократія. Це спосіб **не втрачати швидкість**.\n\n## Чому wasted iterations — головний ворог\n\nУся ця тема зводиться до одного: **зменшити кількість зайвих ітерацій**.\n\nНе просто *«отримати кращу відповідь»*. А отримати **менше циклів до правильного результату**.\n\nПоганий AI workflow виглядає так:\n\n```text\nprompt\n  → не те\n  → пояснення\n  → не те\n  → уточнення\n  → не те\n  → роздратування\n  → ручна правка\n```\n\nДобрий AI workflow виглядає так:\n\n```text\nspec\n  → context\n  → agent run\n  → artifact\n  → validation\n  → focused correction\n  → memory update\n  → reusable template\n```\n\nРізниця не в «розумності моделі». Різниця в тому, що другий цикл **навчається**. Після кожної помилки він стає кращим. Перший — просто витрачає нерви.\n\nСаме тому **artifact-first** підхід такий сильний. Не просити AI *«поясни, що ти зробив»*. Просити створити артефакт, який можна перевірити: diff, test result, deployed page, JSON, checklist, PR, changelog, screenshot, log, report.\n\n<aside class=\"pullquote\"><p><strong>Відповідь переконує. Артефакт перевіряється.</strong></p></aside>\n## Найгірші антипатерни 2026 року\n\nУ новій AI-реальності найчастіше ламають роботу не моделі, а погані патерни.\n\n**1. Гігантський prompt замість системи.** Коли всі правила, стиль, контекст, історія і constraints живуть в одному полотні тексту — система стає крихкою. *Краще:* короткий core prompt, контекст окремо, tools окремо, policies в hooks, пам'ять керована, evals явні.\n\n**2. Агент без меж.** Якщо агент може все, він рано чи пізно зробить щось зайве. *Краще:* read-only by default, write only with scope, dangerous actions require approval, high-risk zones blocked.\n\n**3. Вільний текст між агентами.** Без schema з'являються hallucinations, token bloat і audit hell. *Краще:* structured handoff, template schema, explicit fields, parent orchestrator validates.\n\n**4. Немає пам'яті рішень.** Кожна нова сесія починає з нуля. Людина знову пояснює те саме. *Краще:* `decisions.md`, `project.md`, known constraints, what not to do.\n\n**5. Немає eval loop.** Помилки виправляються вручну, але не стають тестами. *Краще:* failure → captured → classified → added to eval → prevents regression.\n\n## Нова професія: архітектор агентних циклів\n\nЗвідси народжується нова роль.\n\nНе prompt engineer у старому сенсі. А **agent workflow architect**.\n\nЛюдина, яка вміє:\n\n- розбивати процеси на етапи;\n- визначати, де потрібна модель, а де звичайний код;\n- проектувати context flow;\n- налаштовувати memory;\n- прописувати agent roles;\n- створювати structured handoffs;\n- будувати approval gates;\n- вводити evals;\n- контролювати costs;\n- робити workflows portable між vendors.\n\nЦе не одна професія в LinkedIn. Це **навичка**, яка проникне в роботу founder-а, CTO, product manager-а, operations lead-а, аналітика, редактора, розробника.\n\nУ 2024 році було цінно *«вміти промптити»*. У 2026 році цінно **вміти будувати цикли**.\n\n## Bottom line\n\n<mark style=\"background:#ffe600;color:#0a0a0a;padding:0.05em 0.15em;font-weight:600;\">Епоха магічного промпту закінчується не тому, що промпти стали непотрібними. Вона закінчується тому, що **робота стала довшою за один prompt**.</mark>\n\nAI тепер пише код, запускає тести, редагує файли, працює в devbox, чекає approve, пам'ятає рішення, читає пошту, підключає tools, створює PR, запускається по API, отримує hooks і потрапляє в governance.\n\nЦе вже не «генератор тексту». Це **нова машина виконання**.\n\nІ в цій машині головне не те, хто напише найкрасивіший prompt.\n\nГоловне — хто швидше **замикає цикл**:\n\n```text\nпобачити\n  → сформулювати\n  → запустити\n  → перевірити\n  → виправити\n  → запам'ятати\n  → повторити\n```\n\n[Так само як у Мадяровій війні](/blog/madyar-drone-war-ukraine-future-of-war/) перемагає не одна платформа, а швидкість сенсорного циклу — у сучасній AI-роботі перемагає не одна модель, а швидкість **агентного циклу**.\n\nПромпт був командою.\n\nЦикл стає **армією**.\n\n<aside class=\"sources\">\n\n### Джерела\n\n1. <span id=\"src-openai-memory\"></span>OpenAI — Memory Sources release for ChatGPT, 5 May 2026. <https://openai.com/index/>\n2. <span id=\"src-openai-codex-mobile\"></span>OpenAI — \"Work with Codex from anywhere\" mobile launch + Hooks GA, 14 May 2026. <https://openai.com/index/>\n3. <span id=\"src-datahub-context\"></span>DataHub — Context Engineering survey (82% IT leaders, 95% on importance), April 2026. <https://datahub.com/>\n4. <span id=\"src-langchain-state\"></span>LangChain — State of Agent Engineering report, 2026 edition. <https://blog.langchain.com/>\n5. <span id=\"src-anthropic-claude-code-limits\"></span>Anthropic — Claude Code rate-limit doubling + SpaceX 300 MW partnership, 6 May 2026. <https://www.anthropic.com/news/>\n6. <span id=\"src-langchain-deep\"></span>LangChain — Durable execution for production deep agents. <https://blog.langchain.com/>\n7. <span id=\"src-vb-controlplane\"></span>VentureBeat — Agent Control Plane analysis (Microsoft 38.6%, OpenAI 25.7%, Anthropic 5.7%), 15 May 2026. <https://venturebeat.com/ai/>\n8. <span id=\"src-vb-knowledge\"></span>VentureBeat — Pinecone Nexus compilation-stage knowledge layer benchmark (2.8M → 4K tokens), 4 May 2026. <https://venturebeat.com/ai/>\n9. <span id=\"src-github-a11y\"></span>GitHub Engineering — Accessibility Agent architecture, sub-agent pattern, 36% manual-only threshold, 15 May 2026. <https://github.blog/engineering/>\n10. <span id=\"src-langchain-improvement\"></span>LangChain — Agent improvement loop & context engineering patterns. <https://blog.langchain.com/>\n11. <span id=\"src-github-jetbrains\"></span>GitHub — Copilot CLI in JetBrains IDEs, Ask Question tool, `.agent.md` support, 13 May 2026. <https://github.blog/>\n12. <span id=\"src-github-restapi\"></span>GitHub — Agent tasks REST API public preview, 13 May 2026. <https://github.blog/>\n13. <span id=\"src-claude-runtime\"></span>Anthropic Claude Code documentation — Routines, `/usage`, `/ultrareview`, hooks, sandbox rules (April–May 2026). <https://docs.claude.com/>\n14. <span id=\"src-sakana-conductor\"></span>Sakana AI — Conductor paper: 7B model orchestrating frontier models via RL. <https://sakana.ai/>\n15. <span id=\"src-sakana-benchmark\"></span>Sakana AI — Conductor benchmark results (LiveCodeBench 83.93, AIME25 93.3, GPQA-D 87.5). <https://sakana.ai/>\n16. <span id=\"src-fowler-workflows\"></span>Martin Fowler & James Pritchard — \"Workflows vs agents\" distinction, 14 May 2026. <https://martinfowler.com/>\n17. <span id=\"src-zed-billing\"></span>Zed — Anthropic Agent SDK credit split ($20/$100/$200), effective 15 June 2026, 14 May 2026. <https://zed.dev/blog/>\n\n</aside>"
}