Optimized workflow for a CPU-bound agent

[S4lem]

Context

I’m building a RootAgent that orchestrates two main components:

1. TriggerAgent – continuously processes camera frames in a loop.

   • Contains no LLM as it is a customAgent
   • Performs heavy, CPU-bound computations (image analysis).
   • When it detects an event, it captures a screenshot and signals another agent to start.
   • Runs continuously and should never stop or block the rest of the system.

2. SequentialAgent – contains about ten sub-agents.

   • Triggered by the TriggerAgent when an event occurs.
   • Once finished, it can be re-triggered by the TriggerAgent.
   • Consumes screenshot data and performs lightweight sequential tasks.

Both agents are children of a RootAgent, which manages orchestration and data flow between them.

---

Question

What is the recommended ADK-compliant design pattern for this kind of workflow?

Specifically:

• Should the TriggerAgent be offloaded to a separate thread using run_in_executor()
  or to a separate process/server as suggested in the Long-Run Tool section of the ADK docs?
• Is there an existing ADK pattern or helper for running a continuously streaming, CPU-bound agent
  alongside the main async orchestration loop?
• How should state (like trigger signals) be safely shared between the background worker and the ADK context (ctx.session.state)?

---

Goal

I want to keep the architecture responsive, modular, and fully compatible with ADK, if possible,
so that the trigger loop can continuously process input data without blocking
other asynchronous agents or workflows managed by the root agent.

[adk-bot]

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

TLDR: The recommended ADK-compliant pattern is to run your TriggerAgent as a separate, standalone process (a "sidecar" or daemon) that communicates with your RootAgent via an API call (e.g., HTTP request).

---

Hello! That's an excellent question about designing a robust, real-time agentic system. Running a continuous, CPU-bound task alongside an asynchronous framework like ADK requires careful architecture to avoid blocking and maintain responsiveness. Here’s a breakdown of the recommended pattern and answers to your specific questions.

Recommended Design: Sidecar Process with API Communication

The most scalable and non-blocking approach is to decouple your CPU-intensive TriggerAgent from the main ADK runtime entirely. Instead of running it in a thread, you should run it in a separate process.

1. TriggerAgent (Standalone Process):

   • This component runs in its own Python script, completely independent of the ADK agent server.
   • It contains the while True loop for camera frame processing.
   • When it detects an event, it acts as a client and sends an HTTP request (e.g., a POST to a specific endpoint) to the RootAgent. The request can carry the screenshot data and any other necessary information.

2. RootAgent (ADK Orchestrator with an API Endpoint):

   • Your RootAgent runs within the standard ADK runtime.
   • You would expose a simple web endpoint on the ADK server. When the server receives a request on this endpoint (e.g., /trigger), it forwards the request to your RootAgent.
   • Upon receiving the trigger, the RootAgent can update its state and invoke the SequentialAgent with the provided data.

Why Not Use run_in_executor()?

The ADK Runtime is built on asyncio to handle I/O-bound tasks concurrently. [1] While run_in_executor() is useful for offloading synchronous, finite tasks to a thread pool, it is not suitable for a continuous, infinite loop. A CPU-bound while True loop would permanently occupy a thread in the executor's pool, which can starve other tasks and interfere with the ADK runtime's ability to manage its operations, ultimately blocking your entire system.

How to Share State Safely

Directly sharing in-memory state like ctx.session.state between different processes is not safe or feasible. The recommended pattern avoids this entirely:

• State is owned by the RootAgent: The TriggerAgent doesn't need to know about ctx.session.state. Its only job is to send a signal.
• Communication via API: The trigger signal and data (like the screenshot) are passed as a payload in the HTTP request from the TriggerAgent to the RootAgent.
• State Update in the RootAgent: When the RootAgent receives the API call, it is responsible for updating the session state (ctx.session.state.update(...)). [2] This state is then naturally available to any sub-agents it orchestrates, like your SequentialAgent. [3]

This architecture ensures your system remains responsive and modular. The heavy lifting is isolated in one process, while the orchestration and logic remain cleanly inside the asynchronous ADK framework.

---

[1] https://google.github.io/adk-docs/runtime/
[2] https://google.github.io/adk-docs/context/
[3] https://google.github.io/adk-docs/agents/multi-agents/