Agent lifecycle hooks: mutability is too narrow to own the agent workflow, not just gate individual actions #29034

I've been building on the agent-lifecycle-hooks experiment and want to share feedback from real use, in the hope it shapes the contract. The good news: the hook model is the right shape for us. We run a fleet of "coder agents" that collaborate (a builder FORGE, a reviewer SENTINEL, etc.). Hooks give us a single place to enforce policy and audit every agent, and the fail-closed design is exactly what we want. That part is great.

My feedback is about what the consumer can and cannot do. Right now the contract is: only user_prompt_submit and pre_tool_use are mutable, and everything else (post_tool_use, pre_compact, post_compact, stop) is observe-only. For pure action gating that's fine. But it's not enough to own the workflow itself which is the bigger reason hooks are useful.

Concrete example for our usecase(openflows): FORGE finishes "planning", hands off to SENTINEL

We want the control plane to know "FORGE finished its plan, now SENTINEL reviews it." In an ideal hook design, the consumer could observe what actually happened (FORGE wrote PLAN.md, ended its turn) and deterministically advance the workflow. Instead, today:

1. We must rely on the model remembering to run a state command (openflows-harness status set planning) to signal the transition. That's the most fragile link in the whole system: it depends on the model's memory, not on observed behaviour.

2. We can't act on the phase boundary where it's actually observable. stop and post_tool_use are observe-only, so we can't record "the plan artifact now exists" or gate a premature "I'm done."

3. There's no structured, consumer-readable lifecycle/workspace state. The consumer can't persist "planning is done" into a place the orchestrator trusts; we end up inventing our own side channel (Redis) and hoping the agent uses it.

So today the design is "enforce that the agent must remember the ceremony," rather than "derive the transition from behaviour the hooks already see."

What I'd like to see which would help alot

1. Make stop mutable (or at least advisory). We want to refuse a premature "I'm done" our FORGE must not claim done without a PR/artifact. A gateable stop would let the consumer reject that.

2. Make the phase boundary observable and actionable. Allow the consumer to derive and persist state from post_tool_use (e.g. "a Write/Edit produced PLAN.md") and feed it back, rather than requiring the model to report it.

3. Expose a small structured, consumer-writable lifecycle/workspace state in meta or a companion API. A key/value the consumer can set and the orchestrator can read would replace the "tell the model to notify us" pattern entirely.

Why it matters

In short: the current contract is great at saying no to a bad tool call, but it can't yet drive a workflow forward from observed behaviour. If you widen what a consumer can see and act on for stop and the tool-result events, plus a small consumer-writable state hooks stop being a guardrail and become a real orchestration primitive. That's what makes them compelling for multi-agent setups.

Thanks for building this. Happy to provide more detail or test with you.