Approval Packets в 2026: что именно показывать человеку перед risky action

Короткая версия

Хороший approval packet в 2026 обычно содержит:

1. Proposed action
2. Affected entity
3. Key evidence
4. Risk flags
5. Editable payload
6. Trace link for drill-down

Что особенно важно

• один packet = одно потенциальное commit-решение;
• отделять summary от deep trace;
• показывать diff, если агент меняет существующий state;
• давать человеку право не только approve/reject, но и edit/escalate.

Что важнее показать в approval packet: полный chain-of-thought или compact evidence summary?

1. Approval packet нужен для decision quality, а не для аудита

У review-оператора обычно две реальные задачи:

• понять, что именно сейчас произойдёт;
• понять, достаточно ли оснований это разрешить.

Этого нельзя достичь ни одним approve checkbox, ни выгрузкой полного trace в UI. Approval packet должен специально сжимать агентную траекторию до decision object.

2. Какие поля почти всегда нужны

Proposed action

Что конкретно произойдёт:

• refund;
• email send;
• CRM update;
• browser submit;
• file delete;
• publish.

Affected entity

Над чем совершается действие:

• order id;
• customer id;
• document id;
• repo/branch;
• ticket id.

Key evidence

Минимум фактов, на которые опирается агент:

• billing lookup;
• policy reference;
• retrieved snippet;
• tool confirmation;
• prior human note.

Risk flags

Почему этот кейс вообще попал на review:

• money movement;
• external communication;
• low confidence;
• policy exception;
• stale source;
• repeated tool failure.

Editable payload

Человек должен иметь возможность:

• поправить сумму;
• переписать текст письма;
• изменить recipient;
• скорректировать comment;
• снять risky field.

3. Packet должен быть привязан к конкретному commit point

Самая полезная граница: один packet должен соответствовать одному конкретному действию или одному атомарному набору действий.

Плохо:

• один packet на всю длинную траекторию;
• один packet на набор unrelated side effects.

Лучше:

• отдельный packet на refund;
• отдельный packet на email send;
• отдельный packet на final browser submit.

Это делает решение:

• понятнее;
• идемпотентнее;
• легче audit-ить.

4. Summary и drill-down должны быть разведены

Хороший UI обычно строится в два слоя:

• summary card для быстрого решения;
• trace link / expand для сложных случаев.

Это важно, потому что 80-90% кейсов должны решаться по компактной карточке, а не через forensic analysis. Deep trace нужен только там, где summary вызвал сомнение.

5. Diff-view часто полезнее обычного текста

Особенно если агент:

• меняет CRM fields;
• правит документ;
• обновляет код;
• переписывает policy answer;
• меняет existing draft.

В таких случаях packet выигрывает от:

• before/after diff;
• highlighted changed fields;
• removed/added items;
• changed recipients or destinations.

Человек обычно лучше понимает изменение через diff, чем через prose summary.

6. Что особенно часто ломают команды

Approval without reason

Оператор видит действие, но не понимает, почему агент пришёл к нему.

Trace dump as UI

Весь raw reasoning и tool logs вываливаются в review card.

No edit path

Человек может только approve или reject, хотя часто нужен корректирующий middle ground.

No stable packet ID

Нельзя однозначно связать human decision с конкретным pending action.

Missing policy/version context

Непонятно, по какой именно policy или data snapshot агент строил решение.

7. Какие метрики полезны

Минимальный approval-packet dashboard обычно включает:

• median review time;
• edit-before-approve rate;
• reject rate by packet type;
• reopen / re-review rate;
• post-approval incident rate;
• percent of reviews requiring deep trace open.

Последняя метрика особенно полезна: если почти все packets требуют drill-down, summary layer спроектирован плохо.

Пример approval packet

{
  "packet_id": "ap_4921",
  "workflow_id": "wf_2041",
  "step_id": "refund_commit_1",
  "action": "issue_refund",
  "entity": {
    "type": "order",
    "id": "ord_1821"
  },
  "payload": {
    "amount": 129.0,
    "currency": "USD",
    "reason": "duplicate_charge"
  },
  "risk_flags": ["money_movement", "policy_exception"],
  "evidence": [
    "billing lookup confirms duplicate transaction",
    "policy v7 allows refund for duplicate charge"
  ],
  "trace_url": "https://observability.example/traces/tr_9001"
}

Практический checklist

1. Одно решение на один packet
2. Proposed action выражен явно
3. Есть evidence и risk flags
4. Payload можно редактировать
5. Есть trace link, но не trace dump
6. Packet имеет стабильный id

Практический совет: самый сильный approval packet тот, который позволяет хорошему оператору принять решение за 10-20 секунд без ощущения, что он вручную исполняет весь workflow заново.