DevSecOps Digest
Щоденний DevSecOps дайджест

AI-апдейт: durable workflows, approvals і CI-контур для агентів

ai · 2026-09-21

1. Що змінилося

Агентні системи дорослішають у бік workflow-runtime. Уже недостатньо мати model prompt, tool list і гарний transcript. Для регулярних задач потрібні resume після збою, typed tool calls, approval packet, CI-перевірка й короткий receipt.

Корисний сигнал дає Pydantic AI: durable execution можна виносити в Temporal, Prefect або DBOS, а model calls і tool calls оформлювати як відновлювані кроки workflow (Pydantic AI Temporal durability, Pydantic AI Prefect durability, Pydantic AI DBOS durability). Окремо важливий патерн deferred tools: агент може зупинитись, повернути список запропонованих tool calls і продовжити тільки після approval result (Pydantic AI deferred tools).

Dagger показує схожий напрям для coding agents: агент має працювати поруч із наявними CI-функціями, валідувати зміни в тому самому pipeline і бути частиною delivery loop, а не окремим чат-експериментом (Dagger agent in existing project, Dagger generating code). Їхня ідея evals-as-code також правильна для DevSecOps: перевірки поведінки агента мають жити як код, запускатись повторювано й давати регресійний сигнал (Dagger evals as code).

Практичний висновок: OpenClaw workflows треба проектувати як маленькі production jobs. Агент може думати мовою natural language, але виконання має бути детермінованішим: state, gates, artifacts, approvals, validation, rollback.

2. Де ламається персональна автоматизація

Найчастіша слабкість не в моделі. Система ламається там, де агент:

  • продовжує після partial failure, бо transcript виглядає “нормально”;
  • виконує tool call без явного approval scope;
  • не може відновити стан після restart;
  • перевіряє результат вручну, а не через стабільний command;
  • пише в knowledge vault або Hugo без duplicate/provenance gate;
  • не залишає receipt, за яким можна зрозуміти, що саме сталося.

Це не проблема “потрібна краща модель”. Це проблема runtime contract.

3. Як я б зібрав OpenClaw durable lane

Для кожної регулярної задачі варто мати один короткий workflow-файл:

name: daily-ai-hugo-post
trigger: cron
state:
  store: receipts/daily-ai-hugo.sqlite
inputs:
  - content/ai/
  - content/openclaw/
allowed_writes:
  - content/ai/YYYY-MM-DD.md
gates:
  - remote_duplicate_check
  - source_dedup
  - hugo_build
  - git_diff_check
  - remote_blob_verify
approval:
  required_for:
    - multi_file_publish
    - reused_theme
    - failed_validation_retry
receipt:
  include:
    - sources
    - changed_files
    - validation
    - remote_head
    - published_sha

Це можна реалізувати без важкого framework-а. Спочатку достатньо Markdown/YAML + SQLite receipts + один publish script. Якщо workflow стане критичним або командним, тоді вже є сенс дивитись на Temporal/Prefect/DBOS-подібну durability model.

4. Agent vs skill vs workflow

Корисне розділення:

  • Agent - приймає рішення в межах задачі: аналізує джерела, пише текст, пропонує дію.
  • Skill - описує повторювану процедуру: які файли читати, які gates пройти, як оформити failure.
  • Workflow - тримає стан і порядок кроків: trigger, retries, approvals, artifacts, validation, receipt.
  • Tool - виконує вузьку дію: list remote prefix, commit file, verify blob, run build.

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

5. Що додати в knowledge vault

Для Obsidian або Markdown vault я б завів три типи нотаток:

openclaw/workflows/
  daily-ai-hugo-post.md
  morning-operating-cockpit.md
  telegram-triage.md

openclaw/receipts/
  2026-09-21-daily-ai-hugo-post.md

openclaw/evals/
  hugo-publisher-regression-pack.md
  telegram-noise-policy-fixtures.md

Workflow note описує контракт. Receipt note фіксує результат. Eval note зберігає приклади, на яких агент не має ламатись: повтор теми, повтор URL, приватний шлях у публічному пості, занадто шумне Telegram-повідомлення, неправильний file target.

6. 10 практичних OpenClaw use-cases

  1. Durable Hugo publisher. Кожен daily post проходить remote duplicate check, source dedup, Hugo build, whitespace check, optimistic commit і remote blob verify; результат пишеться в receipt.

  2. Approval packet для risky tools. Перед shell/write/network дією OpenClaw повертає structured packet: action, files, resource, risk, validation, rollback, expiry.

  3. Deferred Telegram approvals. У DM можна схвалити тільки конкретний queued tool call; груповий чат ніколи не стає approval authority для secrets, billing, infra або account changes.

  4. Workflow resume journal. Якщо cron перервався, OpenClaw читає останній state record і продовжує з безпечного кроку або зупиняється з failure packet, а не повторює все blindly.

  5. Eval pack для контенту. Набір fixtures перевіряє, що пост не повторює URL, не дублює title, не містить приватних абсолютних шляхів і не починається з повторного H1.

  6. Skill promotion rule. Якщо процедура виконана тричі, OpenClaw пропонує винести її з prompt у skill або workflow note: inputs, gates, outputs, failure modes.

  7. Tool identity ledger. Для кожного tool зберігати owner, scope, allowed resources, data class, approval rule і last reviewed date.

  8. Obsidian workflow board. Dataview-таблиця показує workflows, last success, last failure, next run, owner, validation command і open risk.

  9. Agent CI lane. Для coding або content задач OpenClaw запускає repo-defined validation, а не довільну команду з памʼяті; receipt містить command і версію toolchain.

  10. Day-to-day operating playbook. Ранковий run збирає failed automations, stale receipts, auth warnings, pending approvals і сьогоднішні публікації; у Telegram іде тільки blocker або короткий decision packet.

7. Практичний висновок

Наступний сильний крок для OpenClaw - не додати ще десять tools, а зробити важливі routines durable. Почати варто з трьох речей: workflow contract, deferred approval packet і receipt ledger.

Після цього агентна автоматизація перестає бути довгим чатом із побічними ефектами й стає керованим операційним контуром.