Courses / Build a Multi-Agent System with MCPProLesson 6 of 64:29

Long-running AI agents should wait, not run

Long-running AI agents should wait, not run. When an agent needs a human approval that may take a weekend, it should stop, store its memory and context, and resume when an event arrives. It is the same async pattern you already use to send an email through Pub/Sub, applied to agents.

Long-running AI agents should wait, not runPro lesson4:29

What you will learn: - Tell a long-running agent apart from an always-on agent - Pause an agent for a human approval - Store state and resume the agent when the event arrives - Reuse the async pattern you already know from Pub/Sub

#aiagents #eventdriven #humanintheloop

Chapters

0:00Separate long-running from always on
1:10Know what an always-on agent is
1:30Pause for a human approval
2:34Stop the agent and wait for the event
3:09Reuse the async pattern you know
4:08Design for resume, not idle

Transcript

Separate long-running from always on

So a long running agent is not exactly this is also one of the use cases in terms of long running agent. Oftentimes people misunderstand long-running agent as always it is running. For example, coding agents where you create a software factory, and that software factory will take the ticket, it do the planning, and it will you know create the PR based on your old skills and all those things. Most of the companies are now automating, especially with Cursor and Claude Code, they are going towards these agentics swarms and software factory, and there are many enterprises who is heavily investing on those. You you might have read a lot about it. Now, these are more into the coding agent side where long-running process like overnight, you just open and you run it in your clock you know sandbox and it will span 10 different concurrent cloud and it will create the output in a long running. So that is one challenge.

Know what an always-on agent is

Another thing is always on agent. So most of the time, long-running agent is not something you define you desire you you create in your agentic AI. Oftentimes, I I would say from my experience of consulting with companies, most of the time it is always on agent.

Pause for a human approval

When a human is included in the loop, like Dana goes and approve it. it won't happen overnight or it won't happen in one hour or something where this agent is waiting for response. This will often be stored in a you know durable memory that okay, it is waiting for Dana. Not the same agent loop is going to capture that same output. So, regardless of you stop that process at that time and you resume that process after two days. When in this example, that is not the case, Dana can't go and book after two days. This is more urgent case, but still, like in a scenario where Saturday, Sunday, holiday, and on Monday the human came in and they are resolving that approval process. Then the agent you can't say, like, oh, I will keep my agent idle and it will be consuming resources. It is not the case.

Stop the agent and wait for the event

The agent will stop at that point, and even another agent which is invoking once the event is done, it needs to be more event-driven. Like, okay, this event have arrived. Now your agent will listen to that event, and then it will process what are all the memory I have, what are all the context I have, these are the context which is stored. This is why it has been halted, this is why the human in the loop is invoked, and now I can proceed to the next step. This is how you need to dis you know design your agent.

Reuse the async pattern you know

So, a event-driven loop is not something we have done this many many times with asynchronous process. For example, when you are sending an email, you are not going to send an email in an API endpoint. You will just say, Hey Pub/Sub, I am publishing this event, and you need to send a transactional email to so-and-so person, and there are four people for this transactional email. You you send it the same approach here. A maybe not PubSub or whatever design you are designing, you need to have a robust way to you know invoke or even if the process is halted in the middle, you can able to resume, and you can able to have deterministic result later as well. So that is very very important when you are designing your agentic system, how the how that system is fault tolerant in terms of resumable and always on kind of architecture.

Design for resume, not idle

So oftentimes when you hear about long running, don't think it will always be available that one agent is handling it. You need to think about it is not just one agent, it is just a process, and that process can be reinvocable and you will be able to proceed further on it.

This lesson comes with Pro, $149 a year: Get Pro. This lesson is cut from the free Lightning session Build a Multi-Agent System with MCP. The Live Labs build the same system with you, free, on Thursdays: see the Live Labs.

That was the last lesson. Pro members watch every Lightning session cut the same way: Get Pro. Not sure what to learn next? Take the 2-minute assessment.