AI Engineer World's Fair 2025
Breaking the Chain: Agent Continuations for Resumable AI Workflows
Read the talk
Breaking the Chain: Agent Continuations for Resumable AI Workflows
An agent should be able to stop for approval without keeping its execution loop alive. Recursive continuations preserve the state needed to resume both the agent and its sub-agents.
From a talk by Greg Benson
Before you start: Familiarity with Python functions, JSON, and LLM tool calling will help you follow the continuation interface and nested-agent example.
What happens when a working agent has to wait?
Your agent works well. Now you want to put it into production: can it stop for a human decision, and can a long-running task survive a failure without losing everything it has done? These are the opening questions behind Agent Continuations, the mechanism Greg Benson introduces as a University of San Francisco computer science professor and SnapLogic chief scientist. The approach captures agent state so execution can resume later, supporting both human intervention and snapshots for recovery.
The work comes from SnapLogic’s Agent Creator research group. Consider an agent about to transfer a large amount of money or delete an account. It needs to hand the decision to a human before performing the consequential action. Separately, a long-running agent needs checkpoints so a failure does not force it to restart from the beginning. Moving those agents from a developer’s desktop into a distributed environment adds another requirement: execution must be able to outlive the particular process hosting it.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
The loop that must survive interruption
An agent alternates between model inference and tool execution. It sends the LLM a request describing available tools; the model may return tool-call requests; the agent executes those calls, collects their results, and sends the results back to the model. That cycle continues until the task is complete. A tool can itself be an agent, so even an apparently simple request can involve several interacting loops.
Three situations make uninterrupted execution an awkward assumption:
- Human approval: A tool may require permission to access an environment or to perform a consequential action within it.
- Rate limiting: Benson points to coding assistants encountering heavily used new models. The workflow needs a way to handle an API that cannot accept more work immediately.
- Long-running work: Extensive research across internal and external systems increases exposure to network or hardware failures. Preserving progress becomes more valuable as the work accumulates.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
A paused sub-agent can hold up an entire hierarchy
A main agent or orchestrator may call several sub-agents, each of which can call further sub-agents. Approval and recovery must therefore account for more than the innermost tool. If a deeply nested operation pauses, the system must preserve the parent agents’ progress and the calls through which they are waiting for that operation to return.
Benson calls the hosting problem agent loop persistence. The loop is code running on a physical machine, whether on a desktop or in the cloud. It connects an interface—a command line, a web application, or a channel such as Slack—to the model, tools, and sub-agents.
Benson describes continuously running loops during human approval waits as common among the frameworks his team examined. That characterization should not be read as a requirement of agent frameworks generally. The design target here is precise: shut down every affected loop after suspension, then reconstruct execution when the human responds. A Slack approval should not require keeping the original agent process alive for the duration of the wait.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
The messages array already holds much of the state
The inspiration comes from programming-language continuations: capture execution at a particular point, retain what is needed to continue, and resume later. Supporting that operation in a general programming language can require sophisticated runtime machinery. Agent continuations apply the idea to a narrower execution model built around LLM calls, tool calls, and calls into sub-agents.
When the agent suspends, it returns saved state to the application layer. The application can obtain approval or persist the state for later resumption. Here, suspension means stopping at supported execution boundaries, such as before an approval-gated tool; it does not mean preempting arbitrary instructions inside an executing tool or an in-flight model request.
The useful observation is that an agent already maintains a messages array. This is a history of interactions that is supplied back to the LLM for its next inference. The system therefore already performs much of the bookkeeping a continuation needs: previous requests, tool interactions, and results are retained as conversation state. The messages array is close to sufficient, but it does not by itself identify all the control state needed to resume a suspended operation.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
A request can return work that is not finished
The Agent Continuations prototype starts with a familiar Python interface. Decorators identify Python functions as tools, and the agent receives a list of those tools at construction. It can also receive instructions or a system prompt. An application submits a user request, and the agent performs its model-and-tool loop before returning a response.
Continuation support changes two pieces of that setup: designate a tool as requiring approval, and construct a ContinuationAgent. The important change is in the result contract.
| Result | Meaning | Application action |
|---|---|---|
| Completed response | The agent finished its task | Present or consume the result |
| Continuation object | Execution suspended | Inspect the suspension metadata |
A returned object is therefore not necessarily the final answer. Its metadata tells the application why execution stopped and what intervention is required.
For the approval path, the application records the human’s decision as true or false. Benson follows the positive branch: update the continuation with approval, then pass that same object back through request. The agent recognizes the continuation and resumes immediately before the pending tool call. Approval changes permission to execute; the resumed agent still has to perform the tool call and continue toward its final response.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Capture recursive state, expose a simple approval surface
Forward execution remains ordinary agent processing until a suspension condition occurs. The framework then creates a continuation containing the messages array and additional resumption metadata. As that object returns to the top-level agent, the framework extracts the information the application needs to understand the suspension and supply any required approvals. The application does not have to navigate the whole nested execution structure to find the decision it must present.
After the application updates the object, the framework reconstructs the agent state and continues execution. The saved continuation replaces the need to keep the suspended loops running. Once capture is complete, the loops can shut down because the object contains the information needed to restore them.
The single-level representation separates interaction history from the pending operation and the application’s decision:
| Field | Role |
|---|---|
messages | Normal interaction history |
resume_request | Identifies the operation at which to resume |
processed | Carries processed information, including approval decisions |
approval_info | Exposes approval information to the application |
The top-level approval surface makes updating the object convenient without discarding the underlying execution structure.
For nested agents, a resume_request can contain a sub-agent continuation with its own messages, resume_request, and processed information. The representation is recursive: each level preserves its local history and the child operation it must resume. This is how the format accommodates arbitrary layers of sub-agent nesting rather than treating the entire workflow as one flat conversation.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
An HR agent pauses inside account authorization
The worked example has two agent levels. The top-level HR agent has an email tool and an account-agent tool. The account sub-agent handles account creation and privilege assignment through its own create-account and authorize-account tools. Authorization requires approval. Each agent has its own system prompt and tool configuration.
A new-account request enters through the HR agent and eventually reaches the account sub-agent’s authorization tool. The suspension travels back through the same hierarchy:
- The account agent reaches the pending authorization and detects that approval is required.
- It captures a continuation before authorization executes.
- As that continuation propagates upward, the parent level expands it with the state needed to resume the HR agent.
- The application receives the full continuation and inspects the approval information.
Once the application has supplied the decision, it sends the continuation back to the HR agent. The framework restores both the parent and the account sub-agent to the suspended point. The application’s job is to resolve the approval; reconstructing the nested execution is the framework’s job.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Resume from an edited response file
The demonstration makes the process boundary concrete. Benson supplies the initial prompt as JSON, runs the agent, and writes its response to a file. The point of this arrangement is that the request and its later continuation are decoupled: the saved object must carry the state needed by the later invocation. A small Python file boundary around an already configured agent expresses that handoff:
python
import json
from pathlib import Path
def request_from_file(agent, input_path: Path, output_path: Path):
request = json.loads(input_path.read_text(encoding="utf-8"))
response = agent.request(request)
output_path.write_text(
json.dumps(response, indent=2),
encoding="utf-8",
)
return response
The same function can accept the initial JSON request or the saved continuation because both enter through request.
Inspecting the saved response reveals the top-level continuation and messages, followed by the sub-agent’s messages and system prompt. At the bottom is the application-facing approval information. Benson edits that approval manually, saves the file, and submits the edited response back to the agent. In an application, a review interface would collect the decision and make this update. The resumed invocation reconstructs state with the pending tool now approved.
The resulting output reports successful account creation and a granted security level. The displayed JSON names Alice, shows security level 0, includes a welcome-email confirmation, and ends with end_reason set to completed. These are the workflow’s reported results after resumption.
The completed result also illustrates a useful property of the representation: it contains a normal messages array, with no continuation structure remaining. The continuation is introduced when execution suspends; it is not a permanent wrapper around every finished response.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Beyond human approval
Benson describes the Python prototype as built on the OpenAI Python API with no other dependencies, and makes the implementation available on GitHub. He also reports an implemented version with more general suspension triggers: elapsed time, a number of turns, and asynchronous requests to suspend. Those triggers broaden the reasons to stop while retaining the same capture-and-resume model.
The proposed direction is to bring the mechanism into existing frameworks, such as Strands or Pydantic AI, rather than necessarily grow the prototype into another complete agent framework. These are prospective integrations in the talk, not announced integrations.
Benson explicitly acknowledges that other frameworks already manage state. In his team’s investigation, the missing piece was either human approval or support for arbitrary depths of sub-agent nesting. His novelty claim concerns combining those capabilities: approval can occur inside a nested agent, while the continuation preserves the surrounding execution needed to return there.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
The same mechanism in a visual agent builder
The work also exists above the Python layer. SnapLogic’s Agent Creator provides visual agent construction and a way to visualize agent execution. The team prototyped continuations there as well, applying the mechanism both in Python and within the higher-level SnapLogic platform.
Benson closes by pointing readers to the public prototype and to Agent Creator for visual agent building. The concrete capability connecting those implementations is saved, resumable execution: an application can receive the state of a suspended agent hierarchy, obtain the human decision, and return that state so the workflow can continue.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Resources
From the talk
Python prototype with installation instructions, approval-gated tools, suspension predicates, and account and HR agent examples.
Further reading
- How recursive continuations are reconstructedDocumentation
Implementation walkthrough covering nested continuation objects, flattened approval metadata, and parent/sub-agent resumption.
A 2024 explanation of checkpoint-backed approval pauses and resumption, including interrupted-node replay behavior.
Updates since the talk
Current examples of human input, tool interrupts, and persisted multi-agent interruption.
Current guidance for approval-required tools and resuming deferred work using message history and tool results.
Read the complete timestamped transcript
- 0:00
So you've built some agents, and they're working. Actually, they may be working really well, doing amazing things. And now you want to put these agents into a production setting.
- 0:10
What are the other things you have to worry about? For example, do your agents need some form of human approval during their processing steps? Will your agents be running for long periods of time in the presence of failure?
- 0:21
How do you address these issues? Today, we're going to be learning about a new mechanism that addresses both these issues, and I'm really excited to talk about it. So let's get started. [upbeat music]
- 0:36
Hi, I'm Greg Benson. I'm a professor of computer science at the University of San Francisco, and I'm chief scientist at SnapLogic. And today, I'm excited to talk about a new mechanism that we've developed at SnapLogic called Agent Continuations.
- 0:50
Agent Continuations allow you to capture the full state of complex agents that can be used both to do arbitrary human-in-the-loop processing and also be the basis for reliable agent continuation through taking snapshots.
- 1:07
This work came out of the Agent Curator research group at SnapLogic. First, let's talk about the general challenges that we face with agents today. First of all, there's a lot of concern about where the human sits relative to agent processing.
- 1:22
That is, for people to get comfortable with agent automation, key aspects of agent execution require some amount of human oversight. And so there's been lots of work and lots of techniques for including human-in-the-loop.
- 1:40
I'm not going to go over all of those, but essentially, the agent will get to a point where there's a designated tool or task that might be a high-value, high-risk task, like transferring a lot of money or deleting an account.
- 1:57
And we need a way to ensure that when the agent gets to that point, that in some manner it gets to the human, the human can provide the final determ-determination or decision.
- 2:10
Another problem with agents is that many of them will be long-running. Um, there's lots of steps in agentic processing, and the longer that any process runs, the greater chance that there may be a failure.
- 2:24
And we'd like some way to not lose all the work that an agent has done and be able to potentially, uh, checkpoint our agent state to be able to resume from a point that is not the beginning.
- 2:39
And finally, uh, increasingly, agents are going to be operating in a distributed environment and not just on your desktop, for example. And so what are the considerations for running agents in a scalable distributed environment?
- 2:53
Let's talk about basic agent execution just so we can level set for the rest of the talk today.
- 3:01
An agent is essentially a loop that involves calls to an LLM that specify potential tools for that LLM to use, and if the LLM determines that it needs to use those tools, it will come back to the agent loop, which will then call the tools on behalf of the LLM request and collect the tool results and send
- 3:20
them back to the LLM. And it does this in a progressive loop, LLM, tool call, LLM, tool call, and so on. Now, it's also possible that a tool can be an agent itself, and that's illustrated in the picture here.
- 3:37
We have a sub-agent. So this is the basic agent processing setup, pretty standard across agent frameworks today. Clearly, there's a lot more going on. There's a lot of interaction, and this gives us a detailed view of the interactions I just mentioned.
- 3:50
The mo-main point of this is to, to indicate that even simple agents have quite a bit of interaction with the LLM and with the tools. So what are some of the agent execution scenarios that we're concerned with addressing?
- 4:07
I've mentioned tool calls that require human approval. This is a common idiom; that is, uh, a tool call is an access to something in the environment, something that may require, uh, human approval for the access itself, or it may be an action in the environment, like, like a deleting account, transferring money, um, doing something of consequence.
- 4:30
And in those situations, it's desirable to allow the human an opportunity to approve that request. Another situation that can happen, it happens to me all the time with coding assistants, is the landscape of LLMs and the LLM APIs is changing rapidly, and their use is, is dynamic.
- 4:54
And often new models come out, they get used heavily, and you might encounter rate limiting. And there's other reasons you might encounter rate limiting. Uh, but
- 5:06
there are different ways to handle this situation, and we should seek mechanisms in the presence of this. And finally, I mentioned long-running agents, uh, especially agents that have to do very complicated tasks or extensive research to, to multiple systems, either external to your organization or internal to your organization.
- 5:28
Um, the longer that the agent runs, the more susceptible it is to some potential failure, either some sort of network failure or hardware failure. Um, and as these sophisticated agents run longer, we would like a way to not lose all of the work that the agent has done.
- 5:48
So, so we want to also tolerate failures in the presence of long-running agents.
- 5:57
Another thing I want to elaborate on is
- 6:01
The fact that increasingly agents are becoming more sophisticated in the sense that not only will you have, say, a single level agent that has its access to an LLM and its tool calls, but you may have an agent configuration in which you have a main agent or an orchestrator agent, and then several sub-agents.
- 6:23
In fact, those sub-agents could have their own sub-agents. This is... This pattern is, is becoming quite common. So then the question is, in the presence of these more sophisticated multi-level agents, how are we going to deal with those two primary, uh, primary tasks that I mentioned earlier, human approval and state saving in the presence of failure?
- 6:47
The last concept I want to talk about is what I'm calling agent loop persistence. And this is the idea of if you have an agent running, there is this loop.
- 6:57
That code that actually is doing the loop has to run somewhere. It has to be on a physical machine running. It might be in the cloud, it might be in your desktop.
- 7:06
It, it could be in, in many locations. That agent loop is going to be interacting with the user in some manner. Maybe you're doing it from the command line, maybe you have a web app, um, maybe it's interacting through some sort of third-party communication channel like Slack.
- 7:22
Most of the frameworks today to support things like human-in-the-loop require that that agent loop be running continuously, even if it's waiting for something, like waiting for a human response from Slack, it requires, they require this, this agent loop to, to persist.
- 7:45
And this is something that we wanted to address in our agent continuations work. That is, we wanted to develop a mechanism that would re- would allow us to fully shut down the agent loop, or multiple agent loops in some cases, and then restart them at a later point, say, when the human has provided their approval.
- 8:08
So what are agent continuations? So first off, agent continuations are inspired from the programming language theory concept of continuations. This is a long-standing concept in programming languages in which you can, at any point in time during program execution, you can say, "Hey, I want to stop the program execution at this
- 8:33
particular point," and sort of bundle that up so that I could resume or continue the execution from that point going forward at some later time. In effect, what that lets you do is it lets you take a snapshot of the program's execution so far so that later it could be continued.
- 8:57
Um, it's a powerful me- mechanism that doesn't exist in, in all programming languages, um, because it requires fairly sophisticated runtime support.
- 9:08
But this mechanism, this language continuations mechanism, was the inspiration for what we're calling agent continuations, in which we want to do the same thing. We want to be able to say at some point during agent ex-execution, which again might be through multiple tool calls, multiple LLM calls, and maybe even calls to sub-agents and their tool calls and
- 9:31
LLM calls. At any point in time, we want to be able to say, "Let me pause what the agent is doing. Let me be able to save that state, and then return it back, say, to the application layer so it can, for example, process a human approval, or perhaps persist the state of the agent at that moment
- 9:52
in time to be resumed later." So now let's go into the details of agent continuations. First, let's make some observations about why this may even be possible. The way we work with LLMs and agents today is we maintain the messages array.
- 10:09
The messages array is really almost a log of all the interactions that you've had with the agent or with the LLMs. The... And if you, if you look at it, right, it records a history which is actually replayed back to the LLM to make its next inference.
- 10:29
And so in a sense, uh, agent interactions with LLMs are already doing a lot of the bookkeeping to keep track of everything that's been done so far so that that past history can be sent back to the LLM for the next action, say, for the next tool call response or the next decision that the
- 10:54
LLM has made. So one of our, one of the key insights is that we're building on top of this or this messages array, which already is saving quite a bit of the state of the agent.
- 11:07
Now, it's not quite enough, but it's pretty close. Before we get into the details of how agent continuations are implemented, let's look at how you use the prototype framework.
- 11:22
First, I'm gonna show you how to use the framework like other agent frameworks, that is without continuation support, and this should look pretty familiar.
- 11:34
We have tools, and we use a decorator
- 11:38
to indicate that these Python functions are tools. Uh, and then when we go to create the agent, right, we just send the tool list to the agent so the agent knows to use those tools in processing a user request.
- 11:54
Now, one thing I'm not showing you here for brevity is you can also include instructions or a system prompt to the agent. Now, once you've instantiated your agent, then you can make a request and give a user prompt And the agent will go off and do its LLM request and its tool calling, and eventually come back with
- 12:13
a response. Let's look at our continuation extension to this standard approach. There's only a couple of differences. So now let's look at using the framework with continuation support.
- 12:30
And you'll notice there's only a couple of differences. Let me point those out.
- 12:35
First off, now with continuations, we can designate a tool as needing approval. So here we've said that this tool will need approval. In addition, instead of creating an agent from the agent class, we're gonna use the continuation agent class.
- 12:57
And other than that, it's pretty identical to the standard agent usage. Now, in terms of execution, it's a little bit different. The response
- 13:08
may be the complete response of the agent if the agent was able to complete its task. But if the agent for some reason needs to suspend,
- 13:19
then the response will be a continuation object.
- 13:23
This continuagent, uh, continuation object has metadata that can be inspected so that you can understand the reason for suspension. In this example here, we're assuming that because we know we built the agent with the tool call that needed approval, that that continuation object is going to need a human approval response, which could be
- 13:48
true or false, depending on what the human ultimately decides. But let's say in this case that we decide to approve this tool call request. So we update the continuation object appropriately with the positive human approval, and then you can send the continuation back to the agent using the same request method.
- 14:11
And the agent will know, because this is a continuation object, that it needs to resume from the place that it suspended in the first place. That is, in this case, just before the tool call so that we can get the human approval.
- 14:30
Then the agent can continue to completion and get the final response. So let's go into a little more detail about the implementation.
- 14:43
So with continuations, the forward processing of the agent remains the same. You're gonna do LLM calls. The LLMs are going to come back with a tool call request. We'll pull, form the tool call request as long as they don't necessarily need as human approval.
- 15:04
Uh, but if the human approval o- isn't needed, it's standard agent processing.
- 15:10
If we get to a point where we determine that we need to suspend, like for human approval, or if we've reached some other suspension condition, that's when we create the continuation object.
- 15:21
The continuation object embeds the standard messages array with some additional metadata. That metadata provides the continuation enough information of how to resume when we want to send the continuation back to the agent.
- 15:37
Ultimately, this continuation object will be sent back to the top level agent, which we do some final
- 15:46
processing of to make the application layer, to make it easier for the application layer to understand why the continuation was suspended, and also to allow it to provide human approval updates if required.
- 16:04
So essentially what we do is we take this fairly potentially complicated nested continuation object and extract the core information that the application layer needs to act on to make it easy for that application layer to make those approvals.
- 16:23
Then once the application layer has updated the continuation object, we send it back to the agent. The agent knows that it's a continuation and has the logic in order to reconstruct the agent back to its state so that we can continue the execution.
- 16:44
Now, one really important point of all this is that
- 16:49
once you've suspended the agent and you've created the continuation object, you actually don't need to keep any of the agent loops running in your system. That is, they can be shut down because we've captured enough information to restart everything back to where it was, and this is a really powerful aspect of agent continuation.
- 17:14
So going into a little bit of the detail just to get a sense of what this continuation object actually looks like. I've sh- I'm showing two versions. First is a single level continuation.
- 17:29
Uh, you can see that we've wrapped it. We have the top level continuation, the messages array, which is the normal messages array, and the two other pieces of metadata are this resume request, which indicates exactly which tool call, for example, we need to resume at.
- 17:49
And also processed is going to be populated with whether we approved or, say, disapproved in the case of human approval. And I mentioned that before the continuation is returned is that we extract to the top level of this object the metadata that allows the application layer to easily update the continuation, um, pr- So that it can
- 18:14
proceed after we send it back to the agent. On the right, a slightly more complicated continuation object in which we have an agent that calls a sub-agent, and the main point here is that our format is recursive, and it can handle arbitrary layers of nesting.
- 18:32
And you can see that here in the fact that we have a resume request that now has its own continuations object with its own messages, and that's the messages of the sub-agent, and its own resume request and processed.
- 18:46
So let's look at a full example. Here we have a multi-level HR agent. And so the top-level agent has an email tool, and it has access to a sub-agent, the account agent tool, which is responsible for creating an account and setting account privileges.
- 19:07
I have a abbreviated system prompt up here, and we construct our continuation agent for the HR agent here. Now let's take a look at the account agent for a moment.
- 19:19
It's its own agent with its own tools, create account, and authorize account. In this case here, authorize account needs approval. But you can see it uses the same basic setup.
- 19:31
Uh, we give it its system prompt up here and its tools. And this sub-agent is going to be used by the top-level HR agent.
- 19:43
Here I have an example prompt to create a new account, and that prompt will be sent to the agent to be processed. Now, in this example here, it's set up, right, such that eventually the account agent sub-agent will need human approval for the authorize account tool, which will cause the agent to suspend,
- 20:08
create a continuation, return that back to the application lay-layer for processing. Here is an illustrated diagram of the steps that I mentioned. In this diagram, we have the application layer that's interacting with the user.
- 20:24
We have our HR agent and its tool call send mail, and then it's using the account agent as a tool, and that account agent has its create account tool and its authorize account tool.
- 20:41
Now, in the scenario I just described, we'll get down to the point where
- 20:47
we know we need approval for authorize account. So that's the point at which we need to suspend and start creating or building up our continuation object. And that's what happens here.
- 21:03
So the approval propagates a continuation object, object that gets expanded at each level as it's propagating back to the application layer until finally we have the full continuation object for the application to inspect and then act on.
- 21:20
Now, once the application layer has done that, then that continuation object can be sent back into the HR agent, and the framework will know that we need to restore the agent state and the sub-agent state back to where it was when we needed the approval in the first place,
- 21:40
and that will be handled all by the framework. So let's do a quick demo.
- 21:46
So let's look at our prompt. So we have the prompt here as a JSON, and
- 21:56
I'm going to run this prompt here. So I'm just giving that prompt as the first prompt to the agent starting off, and I'm going to send this out to
- 22:16
a response file. And the whole point of this is to show that these things are fully decoupled and that these objects contain all of the state that we need.
- 22:25
So let's look at the response object, and this has the things that you could imagine. There's the continuation, there's the top-level messages, and if you go down, right, here is the sub-agent messages with its system prompt.
- 22:44
And finally, if we go down to the bottom of this object, this is that top level approval object that the application layer can then present to the user and then update.
- 22:57
So here I'm just doing it manually. Obviously, you would do this in application code. So I'm gonna save that, and now what I'm gonna do is I'm gonna send that edited response back to the agent.
- 23:11
And the point of this is that now the agent will reconstruct its state, but with the information that the tool has been approved so that the agent can continue processing.
- 23:26
And there you go. If you look here, right, we-- agent has indicated that the account has been successfully created, uh, and that a security level has been granted, and that we now have the end reason of completed.
- 23:45
The other thing I'll note in this output here is that
- 23:50
everything above now is normal, a normal messages array. That is, uh, there's no sign of continuation in the final result object.
- 24:03
The continuation is just introduced when we need to suspend. Okay. So let me go over just a few details, um-
- 24:13
Our prototype is built up on top of the OpenAI Python API. There's no other dependencies. We have the prototype implementation. Here's the link that you can go to on GitHub, and it should be in the channel notes as well.
- 24:26
Where do we want to take this? We've already implemented a version with more general agent suspension that is beyond just human approval, is that setting up arbitrary suspension points like after a certain amount of time, a certain number of turns, even asynchronous requests for suspension.
- 24:45
And what we're looking at is not just, not necessarily developing, uh, this prototype into a full separate agent framework, um, because there's lots of good frameworks out there, but rather looking at ways to extend existing frameworks, something like Strands or Pydantic AI.
- 25:02
Now, I should also mention that, um, we're not the first framework to consider state management. Some of the other frameworks do have forms of state management. However, uh,
- 25:16
in our investigation of the state management, they either sort of lack the human approval element or the, um, the sophistication of having arbitrary depths of nesting into sub-agents.
- 25:33
And so we think our approach is novel in the sense that it combines both those, both a human approval mechanism and also this arbitrary nesting, uh, of complex agent.
- 25:48
This work came out of the Agent Creator team at SnapLogic. Agent Creator is SnapLogic's visual agent building interface and platform. Not only did we build it out in Python, but we built it out in Agent Creator itself, and you can see here that we allow our users to create sophisticated agents using a more visual approach, and you
- 26:11
can also visualize in the platform agent execution. We prototyped continuations in the SnapLogic Agent Creator environment as well. Uh, so we, we did it both at the Python layer, and we also did it at our higher level, uh, layer in, in the SnapLogic platform.
- 26:33
In conclusion, Agent Continuations are a new mechanism for managing agent state and human-in-the-loop processing. We have a prototype implementation that you can access on GitHub from the link on this page.
- 26:49
And if you want to learn more about building agents visually with SnapLogic Agent Creator, go to agentcreator.com. [upbeat music]