google / google/adk-docs

Document Best Practice for Long Running Invocation

Open
#265 2 comments 0 reactions 1 assignee Claimed by @hangfei View on GitHub
agents deploy question running_agents
Dominant language
Shell
Stars
1.5k
Forks
1.3k
Avg merge
7d 1h
Merged PRs (30d)
34

Description

In some production scenarios, I may have an agent that could take like 2 hours to run if it does something especially complex.

I'm curious what the best practice is for handling this, especially given that the adk is a fast api app under the hood, which I don't really associate with long running asynchronous jobs.

AFAIK, there is no job queue or anything like that which would allow an agent to pick up where it left off after working for 1h if my adk instance went down or got rolled to a new deployment or whatever.

I would like to understand the best way to solve this problem with this framework.

For example...

Should I split agents into tasks that only take 30m to run, invoke them always with the run sse endpoint so they are connected to a streaming client that keeps the app alive for long running invocation, and then use something like prefect/airflow/temporal to orchestrate running the different steps, since they support persistent queues with retry etc

An alternative is to just stream the agent results and assume fast API app wont respond to any sigterm that would kill the client. That feels nowhere near robust enough to me for a production app doing fancy stuff.

Contributor guide

Open the contributing guide

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.