dangzitou commented on issue #1067:
URL: https://github.com/apache/flink-agents/issues/1067#issuecomment-6309960495
Now that DecisionModel resources have landed (#1243 / #1264), I'd like to
add one angle for the eventual Discussion: treat the **approver as pluggable**,
with a decision model as the first tier and a human as the fallback.
**Use case.** In cross-border e-commerce, for example, an agent proposes
actions such as raising an ad bid or pausing a listing. Most proposals are
routine and could be cleared automatically; only ambiguous or high-impact ones
need a person. Sending every proposal to a human makes approval the bottleneck,
and every one of them would take the hard suspend/resume path described above.
**What already works today, with no new runtime semantics:**
1. The proposing Action emits a `DecisionRequestEvent` with a
`PredicateQuestion` (e.g. "Is this change within policy?") and
application-supplied criteria.
2. The `DecisionResponseEvent` handler applies application-owned thresholds:
- `probability_true >= T_approve` → continue to the next step (e.g. emit
the event that triggers the tool call)
- `probability_true <= T_reject` → reject and emit an output
- in between, a `RefusalAnswer`, or a failed response → escalate to a
human
Because the call goes through the built-in Decision Action, its outcome is
recorded via durable execution when an Action State Store is configured, so
recovery replays the verdict instead of asking the model again.
**What this could mean for the #1067 design:**
- Only the escalation branch needs durable suspension. The questions raised
above (in-flight keys buffering the approval signal, watermark progression, an
explicit persisted approval state machine) still need answers, but they would
apply to a much smaller share of records, which may make a narrower first
version acceptable.
- If the pending-approval state records *who* resolved it (a decision model
with its probabilities, or a human with an identity), the audit trail stays
uniform across both paths.
- Thresholds and the escalation policy should stay in application code,
consistent with the DecisionModel design, where the business Action "chooses
thresholds, and decides what to do with the answers".
Happy to help write this up as a documented pattern or example, and to join
the Discussion once it's opened.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
