Escalate from after_agent_callback

[sigott]

I have a loop agent that is a sub_agent to the root_agent. The loop agent has an after_agent_callback. The callback keeps track of a few things and updates the state after each loop iteration. Is there a way to also escalate (end the loop) from within the callback? I know this can be done by adding another agent in the loop but that just seems a bit clunky?

It would be nice if I could modify the agent's last event from within the after_agent_callback and add/modify the event's EventActions.

[adk-bot]

Response from ADK Answering Agent (experimental, answer may be inaccurate)

TLDR: Directly escalating from an after_agent_callback is not a supported feature. The recommended and standard ADK pattern is to use a simple, dedicated "checker" agent within the loop that yields an Event with escalate=True to terminate the loop.

---

Hi @sigott,

That's a great question about controlling the flow of a LoopAgent. While using callbacks to react to an agent's execution is powerful, they are not designed to control the workflow's escalation.

The termination of a LoopAgent is determined by two conditions: reaching max_iterations or when one of its sub-agents yields an Event with escalate=True set in its EventActions. [1, 2] This is the intended mechanism for controlling the loop's lifecycle.

The after_agent_callback provides a CallbackContext which is primarily used for observing an agent's output and modifying the shared state. It does not provide a handle to modify the EventActions of the event that was just produced. In contrast, when you are implementing a custom tool, the ToolContext does provide a tool_context.actions attribute, which allows a tool to signal an escalation. [3]

Recommended Solution

You mentioned that adding another agent to the loop feels a bit "clunky." However, this is the idiomatic approach in ADK, and the agent for this task can be very lightweight and simple. It doesn't need to be a complex LLM-based agent. You can create a simple BaseAgent that encapsulates the termination logic you're currently handling in your callback.

Here is a conceptual example:

from adk.agents import BaseAgent, AgentContext
from adk.events import Event, EventActions

class LoopTerminationAgent(BaseAgent):
    """An agent that checks a condition and escalates to terminate the loop."""
    async def _run_async_impl(self, context: "AgentContext"):
        # Retrieve the necessary data from state to make a decision
        # This is the same logic you would have in your callback
        should_terminate = your_condition_check(context.state)

        if should_terminate:
            # Yield an event with escalate=True to stop the parent LoopAgent
            print("Condition met. Terminating loop.")
            yield Event(actions=EventActions(escalate=True))
        else:
            # Otherwise, do nothing and let the loop continue
            yield Event(content="Condition not met. Continuing loop.")

# Then, add this agent to your LoopAgent's list of agents
loop_agent = LoopAgent(
    agents=[
        your_main_sub_agent,
        LoopTerminationAgent()  # This agent will run at the end of each loop iteration
    ],
    max_iterations=20
)

This approach keeps the control flow logic cleanly encapsulated within an agent, which aligns with ADK's design principles. It's a clear and maintainable way to manage the loop's execution based on dynamic conditions in the state.

[1] https://google.github.io/adk-docs/agents/multi-agents/
[2] https://google.github.io/adk-docs/agents/workflow-agents/loop-agents/
[3] https://google.github.io/adk-docs/tools-custom/