Policy disclosure - let the Observed Agent learn its constraints before it acts

[President]

(An untested idea, raising it for discussion)

Today the Observed Agent learns policy only after a DENY, so it might keep retrying variations that can't pass.
Before the first step it gets only methods_evaluated from ServerHello.

Suggest: an optional method where the Observed Agent asks the Guardian for the constraints that apply, and decides if/how to put them into the LLM's context.

The answer can be free text. Not the exact limits or thresholds - just enough for the LLM to know the boundaries exist and not hit the wall in retries.

Does this conflict with "the agent MUST NOT have knowledge of hooks"? I'd say no - the LLM learns the rules, not how or whether they are enforced. And the Guardian decides how much to disclose.

[rocklambros]

The problem statement here is right, and the retry loop is the symptom that makes it visible: the agent learns an action failed, guesses at what would succeed, and keeps trying variations until it exhausts itself or trips the same rule again.

Raising a push variant alongside the pull one you describe, because the two differ on a security property rather than only on ergonomics.

Pull, as proposed here. The Observed Agent asks the Guardian for the constraints that apply, and decides what to put in the LLM's context. It answers before the first step, which is the part the decision path cannot do.

Push. A decision optionally carries guidance, so the answer arrives attached to the thing that prompted the question. No extra round trip, and the guidance is scoped to the action that was actually refused rather than to the session in general.

They compose. Pull sets the boundaries before the agent acts, push corrects when it walks into one. The reason to specify them together is that both create the same trust-boundary crossing, and it is worth getting the constraint right once.

Why this has to be constrained rather than just added. Either way, text carrying the Guardian's authority enters the agent's context, and the agent acts on it precisely because it trusts the source. If the Guardian's agent layer composes that text after reading attacker-influenced content, an injection enters the agent's context wearing the Guardian's credibility. That is a worse outcome than the retry loop we are trying to fix.

So the shape that seems defensible:

• Deterministic-layer guidance MAY be injected verbatim.
• Agent-layer guidance MUST be template-constrained, with the agent layer selecting a template keyed on reason_codes rather than writing free text. This is the same select-don't-write discipline the spec already applies to dispositions, extended to the payload.
• No guidance from the agent layer when metadata.evaluator is absent, since there is then nothing asserting which layer produced it.

Content rules, most of which you already named:

• No rule names, policy identifiers, detection logic, or thresholds. This matches the constraint already on deny reason codes, and it is your "not the exact limits or thresholds" point.
• No echo of the content that triggered the decision, because echoing it reintroduces it.
• Phrased as factual statements about the environment rather than imperatives. Command-shaped text tends to trip a model's own injection defenses, so guidance that reads like an instruction gets ignored by exactly the models that are hardest to steer.

Guidance is never load-bearing for enforcement. A malformed or oversized payload is dropped and audited, and never changes the disposition. If an action must not proceed, the disposition is deny and the guidance is only the explanation. That keeps this out of the enforcement path entirely, which is what makes it safe to add.

On your question about whether this conflicts with the agent not having knowledge of hooks: agreed that it does not, and the push form sidesteps it further. The agent never learns that a hook exists or fired. It receives a statement about its environment attached to a refusal it was already going to see.

Two dependencies worth naming now, because both are cheaper to design in than to retrofit.

A revision iteration counter, so a steer loop on agentResponse terminates and the Guardian can hard-deny on a final pass. Without one, "here is why that failed" plus a model that keeps trying is a loop with no upper bound.

Whether deny-side guidance belongs on hooks that are not currently decision-eligible. That question is now #146, which found that "Not decision-eligible" means two different things in the spec today and that subagentStop carries a different label in its schema than in hooks.md. Guidance on a hook whose eligibility is ambiguous inherits the ambiguity.