[FEATURE] Add `steer_after_model` support to `LLMSteeringHandler`

[morganwillisaws]

Problem Statement

The current LLMSteeringHandler only implements steer_before_tool. There's no generic LLM-based implementation for steer_after_model, which means anyone who wants to evaluate model output (instruction adherence, voice/tone enforcement, output format validation, etc.) has to write a custom SteeringHandler subclass from scratch.

Proposed Solution

Extend LLMSteeringHandler to support both steer_before_tool and steer_after_model, with users opting in to each by providing the corresponding prompt mapper.

New classes in mappers.py:

• LLMModelPromptMapper — protocol for model output evaluation prompts
• DefaultModelPromptMapper — default implementation using Agent SOP format

Updated LLMSteeringHandler:

• Accepts an optional model_prompt_mapper parameter
• If provided, steer_after_model creates a fresh steering agent, passes it the agent's system prompt + model output, and gets a structured proceed/guide decision
• If not provided, steer_after_model returns Proceed (no-op, backward compatible)

Key design decisions:

• The DefaultModelPromptMapper automatically pulls the agent's system prompt via getattr(agent, "system_prompt", None) and includes it in the evaluation. This makes it a generic "did you follow your instructions?" check without the user needing to duplicate instructions.
• Separate _LLMModelSteering structured output model that only allows proceed/guide (no interrupt, since the model has already responded).
• Dedicated _MODEL_STEERING_PROMPT_TEMPLATE in Agent SOP format, parallel to the existing tool template but tailored for output evaluation.
• Fresh steering agent created per evaluation to avoid conversation history bleed.

Use Case

This is a common need. Any agent running a long conversation or multi-step workflow will drift from its system prompt over time. The model's attention to original instructions degrades as context grows. This affects:

• Writing agents that need to maintain a consistent voice
• Coding agents that must follow formatting or architecture rules
• Data pipeline agents restricted to certain operations
• Customer service agents with tone and escalation policies
• Any agent with a system prompt that contains explicit constraints

Alternatives Solutions

No response

Additional Context

No response

[mkmeral]

How would you apply the steering back to model? Currently before tool steering essentially cancels tool and returns steering response instead.

Would you do the same for all tools, or would you just remove tool uses?

---

I'd like to take a step and back and discuss the issue. Are we targeting the cases where tool calls are not made but the agent is directly responding to the user? So at a high level, are we interested in after model response, or after agent invocation (when final response is generated)?

[morganwillisaws]

We are discussing adding functionality to address use case where tools are potentially not involved.

The key difference from tool steering: tool steering cancels the tool and returns the steering response instead of the tool result.

Model steering discards the response and retries the model call with guidance injected into the conversation. The model gets another chance to generate a compliant response. There's no "cancel" equivalent because there's nothing to cance. The model already responded, we just throw it away and try again.

I'm suggesting it hooks into AfterModelCallEvent so the output it evaluated after the model responds (not final) and the steering agent has a chance to guide it back to following the instructions set in the prompt.

@Unshure is reviewing a fork where I implemented something as a POC for this idea. https://github.com/morganwillisaws/sdk-python