Human-in-the-Loop Architecture: коли людина підтверджує рішення агента

Ідея за 30 секунд

Human-in-the-Loop Architecture — це керована схема, де система залучає людину перед виконанням ризикової дії.

Агент може запропонувати action, але фінальне рішення для критичних кроків приймає людина: approve, reject або revise.

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

Коли потрібна: коли дії агента можуть змінити стан, витратити гроші, зачепити чутливі дані або створити юридичний ризик.

LLM не має самостійно виконувати критичні side effects (зміни стану). Вона лише пропонує дію, а система переводить її в контрольований процес погодження.

Проблема

Без Human-in-the-Loop система часто потрапляє в одну з крайностей:

• або агент діє занадто автономно;
• або команда вручну перевіряє майже все і втрачає швидкість.

Типові збої без чіткого HITL-шару:

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

У production це перетворюється на інциденти, повільні релізи або слабкий аудит.

Рішення

Додати Human-in-the-Loop Architecture як явну межу погодження (approval boundary) між рішенням агента і фактичним виконанням дії.

Цей шар визначає:

• які дії йдуть без погодження;
• які дії вимагають підтвердження людиною;
• як обробляти approve, reject, revise і timeout.

Аналогія: як подвійний підпис у фінансових операціях.

Система може підготувати платіж, але для великої суми потрібне підтвердження відповідальної людини.

Human-in-the-Loop працює так само: важливі кроки не виконуються автоматично.

Як працює Human-in-the-Loop Architecture

Human-in-the-Loop Architecture — це керований шар між Agent Runtime і виконанням дій, який переводить критичні кроки в режим погодження людиною.

Такий цикл дозволяє зберегти швидкість автоматизації і контроль над критичними діями.

У коді це виглядає так

class HumanInTheLoopArchitecture:
    def __init__(self, policy, approval_queue, tool_execution):
        self.policy = policy
        self.approval_queue = approval_queue
        self.tool_execution = tool_execution

    def execute_action(self, action, context):
        decision = self.policy.check(action=action, context=context)
        mode = decision.get("mode")

        if mode == "allow":
            return self.tool_execution.execute(action=action, context=context)

        if mode == "require_approval":
            ticket_id = self.approval_queue.create(
                action=action,
                context=context,
                reason_code=decision.get("reason_code", "approval_required"),
            )

            # Simplified synchronous example for illustration.
            review = self.approval_queue.wait(ticket_id=ticket_id, timeout_s=300)
            if review is None:
                return {"ok": False, "reason_code": "approval_timeout"}

            status = review.get("status")
            if status == "approved":
                approved_action = review.get("action_override", action)
                return self.tool_execution.execute(action=approved_action, context=context)

            if status == "revise":
                return {
                    "ok": False,
                    "reason_code": "approval_revision_required",
                    "feedback": review.get("feedback", ""),
                }

            return {"ok": False, "reason_code": "approval_rejected"}

        return {"ok": False, "reason_code": decision.get("reason_code", "policy_denied")}

У цьому прикладі wait(..., timeout_s=300) показаний для наочності.
У production HITL частіше працює асинхронно: система створює approval ticket, завершує поточний run зі статусом pending_approval, а потім відновлює процес після рішення людини.

Як це виглядає під час виконання

Запит: "Експортуй базу клієнтів у зовнішню CRM і надішли лист усім контактам"

Step 1
Agent Runtime: формує action -> export_customers + send_campaign_email
HITL Gate: classify -> require_approval (high_risk_data_export)

Step 2
Система створює approval ticket з контекстом і причиною
Human: revise -> дозволити лише сегмент "active_customers", без масової розсилки

Step 3
Tool Execution Layer: виконує тільки погоджену дію
Runtime: повертає результат + reason_code в трейс

Human-in-the-Loop не блокує автоматизацію повністю. Він додає контроль у точках реального ризику.

Коли підходить — і коли ні

Human-in-the-Loop Architecture корисна там, де ціна помилки висока і потрібна відповідальна людина в критичних кроках.

Підходить

Не підходить

У таких випадках часто достатньо policy-gates без ручного погодження:

decision = policy.check(action, context)
if decision["mode"] == "allow":
    execute(action)

Типові проблеми та відмови

Стабільний HITL-шар потребує не лише кнопки "Approve", а й чіткої операційної дисципліни.

Як поєднується з іншими патернами

Human-in-the-Loop Architecture працює як керований контрольний шар поверх базових механізмів виконання.

• Agent Runtime — Runtime веде цикл, а HITL вирішує, які кроки потребують людини.
• Tool Execution Layer — після погодження дія виконується через контрольований tool gateway.
• Policy Boundaries — policy rules визначають, коли саме вмикається require_approval.
• Hybrid Workflow Agent — HITL часто вбудовується у workflow commit-кроки для високого ризику.
• Orchestration Topologies — у multi-agent системах HITL застосовується до окремих гілок або фінального merge-кроку.

Інакше кажучи:

• Policy Boundaries визначають що ризикове
• Human-in-the-Loop Architecture визначає як саме людина підтверджує або блокує цю дію

Чим це відрізняється від Supervisor Agent

Supervisor Agent і HITL можна поєднувати: supervisor робить попередній фільтр, а людина погоджує лише найризиковіші кроки.

Коротко

FAQ

Q: Чи означає HITL, що кожну дію має підтверджувати людина?
A: Ні. Практичний підхід: тільки high-risk дії йдуть на погодження, решта виконується автоматично.

Q: Що краще для fail-safe: timeout = allow чи timeout = deny?
A: Для ризикових write-дій зазвичай використовують fail-closed: timeout => deny або безпечний fallback.

Q: Чи можна в HITL не лише схвалювати, а й змінювати дію?
A: Так. Режим revise дозволяє людині підтвердити дію з обмеженнями (сума, сегмент, scope).

Q: Коли краще обрати Supervisor Agent замість HITL?
A: Коли потрібен швидкий автоматизований контроль політик без ручного втручання на кожному ризиковому кроці.

Що далі

Людина в контурі зменшує ризик. Наступний крок — зрозуміти, як це поєднати з технічними межами системи:

• Policy Boundaries — які дії дозволяти, блокувати або відправляти на approval.
• Hybrid Workflow Agent — де працює deterministic workflow, а де — bounded agent-рішення.
• Orchestration Topologies — як розкласти рішення між кількома агентами.
• Production Stack — як зібрати це в керовану production-архітектуру.