SnapLogic Technical Blog

7 MIN READ

Introducing the Agent Snap

tfan

Employee

3 days ago

As we’ve gone through 3 quarters of “The year of Agents“, we have a clear understanding of what an “Agent” is and how it runs. In this article, we will be introducing the next generation “Snaplogic Agent”: to bring the same capability with a fraction of the time to create an agent.

Flashback: What’s an Agent?

“Agents are autonomous LLM-based processes that can interact with external systems to carry out a high-level goal.”

Agents are LLM-based systems that can perform actions based on the user’s request and the scenario, determined by the LLM of the Agent system. A minimal agent consists of 1. an LLM component, and 2. tools that the Agent can use. Think of the Agent as a Robot with a brain (LLM) + robotic arms (Tools). Based on the request, the brain can “decide” to do something, and then the arm will carry out the action decided by the brain. Then, depending on the scenario, the brain can determine if more action is needed, or end if the request is complete.

The process of an agent

We previously introduced the “Agent Driver and Agent Worker“ pipeline pattern, which clearly defines every single operation that would occur in an Agent process. The process of the pattern can be described as follows

Agent Driver

Define the instruction of the Agent. (System prompt)
Format the user’s request into a conversation. (Messages array)
Define tools to make available to the Agent.
Send all information above into a “loop“, run the Agent worker until the process is complete.

Agent Worker

Call the LLM with the instructions, conversation, and tool definitions
LLM decides…
1. If it is able to complete the request, end the conversation and go to step 7.
2. If tool calls are required, go to step 3.
Call the tools.
Format the tool result.
Add the tool results to the conversation
Back to step 1.
Request is complete, the agent responds.

The rationale

From the Agent Driver and the Agent Worker pipeline, here’s an observation:

The driver pipeline handles all of the “configuration“ of the Agent.
The worker pipeline handles the “operation“ of the Agent.

Now, imagine this:

If we can package the “Agent operation” into a single module, so that we can create Agents just by providing instructions, and tools. Wouldn’t this be great?

This is exactly what Agent Snap does. The Agent Snap combines the PipeLoop Snap and the Agent Worker pipeline, so all of the agent operations happen in a single Snap.

Information and prerequisites

Now, before dreaming about having your own company of agents, since building agents is now so simple, there is some information to know about and conditions to be met before this can happen.

1. Agent Snaps are model-specific

Model Specific Agent Snaps

The Agent Snap is a combination of the “loop” and the Agent Worker, therefore, the LLM provider to be used for an Agent Snap is also fixed. This design allows users to stick to their favorite combination of customized model parameters.

2. Function(Tool) definitions must be linked to a pipeline to carry out the execution

Before: Agent Worker with PipeExec Snaps

Now: A tool pipeline for a function definition

Previously, in an Agent Worker pipeline, the Tool Calling Snap is connected to Pipeline Execute Snaps to carry out tool calls, but this is no longer the case with the Agent Snap. Instead, a function definition should include the path of the pipeline to carry out the execution if this tool is called. This way, we can ensure every tool call can be performed successfully. If the user does not provide a tool pipeline with the function definition, the Agent Snap will not proceed.

3. Expected Input and Output of a tool pipeline

When a tool call is requested by an LLM, the LLM will provide the name of the tool to call and the corresponding parameters to call. The Agent Snap will unwrap the parameters and send them directly to the tool pipeline.

Here’s an example: I have a tool get_weather, which takes city: string as a parameter. The LLM decides to call the tool get_weather with the following payload:

{ "name": "get_weather", "parameters": { "city": "New York City" }, "sl_tool_metadata": { ... } }

For this to work, my tool pipeline must be able to accept the input document :

{"city": "New York City"}

On a side note, the sl_tool_metadata object will also be available to the tool pipeline as the input for APIM and OpenAPI tools.

Now, assume my tool pipeline has successfully retrieved the weather of New York City, It’s time for the Agent Snap to collect the result of this tool call. The Agent Snap will collect everything from the output document of the tool pipeline as the tool call result*. So that the LLM can determine the next steps properly.

*Note: with one exception, if the output of a “tool pipeline“ contains the field “messages“ or "contents", it will be treated as the conversational history of the “child agent”, which will be filtered and will not be included.

Build an Agent with Agent Snap

We’ve understood the idea, we’ve gone through the prerequisites, and it’s time to build an Agent.

Agent pipeline with Agent Snap

In this example, we have an Agent with 2 tools: a weather tool and a calendar tool. We first start with a prompt generator to format the user input. Then define the tools the Agent can access.

Let’s look into one of the tool definitions.

In this example tool, we can see the name of the tool, the description of the tool, the parameters, and the path of the tool pipeline to carry out this task. This satisfies the requirement of a tool to be used by an Agent Snap.

After we have the tools set, let’s look at the Agent Snap, using the Amazon Bedrock Converse API Agent Snap as an example.

The configuration of an Agent Snap is similar to its corresponding Tool calling Snap, except for some extra fields, such as a button to visualize the agent flow, and a section to configure the operation of the Agent, such as iteration limit and number of threads for tool pipeline executions.

The Agent Snap handles the whole executional process, and terminates when 1. The request is complete (no more tool calls are required) or 2. An error occurred.

Voila! You have created an agent.

After the Agent pipeline completes a round of execution, the user can use the “Visualize Agent Flow“ button in the Agent Snap to see the tools that are called by the LLM.

The Agent Visualizer UI

Tips and Tricks for the Agent Snap

Let’s take a look at the features built into the Agent Snap.

Reuse pipelines

Most agentic tool calls are processes that can be reused. To minimize execution load, we can use the “Reuse tool pipeline“ feature. This feature allows tool pipeline instances to be reused, so that the Agent will not need to spawn a pipeline every time a tool is called.

To use this feature, the tool pipeline to be reused must be “Ultra compatible“; otherwise, the pipeline execution would hang, and the Agent Snap would eventually timeout.

Tool call monitoring

Agents can be long-running; it’s not rare to have an Agent run multiple iterations. To see what’s happening in the process, Agent Snap has built in monitoring during validation. The user will be able to see the iteration index, the tool that is currently being called, and the parameters that are used for the tool call in the pipeline statistics status bar.

Selecting the “Monitor tool call“ option includes the parameter in the status update, which is an opt-in feature. If the user does not wish to expose the information to SnapLogic, the user should disable this.

Warnings

Agent configuration is a delicate process; a mistake can potentially lead to errors. The Agent Snap has a bunch of built-in warning capabilities, so the user can be better aware of what could go wrong.

1. Agent process completed before all tool calls completed

Iteration limit reached warning

In the Agent Snap, there is an Iteration limit setting, which limits the number of iterations the Agent can run. If the user provided a smaller limit, which caused the Agent to stop while the LLM is still awaiting tool calls, this warning would pop up to signal the user that the execution is incomplete.

2. Tool pipeline path is not defined

Tool pipeline path missing warning

A function (tool) definition to be used by the Agent Snap should include a tool pipeline path, so the Agent Snap can link to the actual pipeline that carries out the execution. If the pipeline path is not included in the function definition, this warning will pop up to signal the user that the Agent will not proceed.

3. Duplicate tool naming

Duplicate name warning

As we try to add more and more tools to the Agent Snap, two tools likely share the same name. The Agent Snap has the ability to rename the tools being sent to the LLM, and then still link to the correct pipeline. There will also be a warning available in the pipeline statistics to alert the user about a change in the behavior.

Release Timeframes

The Agent Snap is the foundation of the next-generation SnapLogic Agent. We will be releasing 4 Agent Snaps in the November release:

Amazon Bedrock Converse API Agent
OpenAI Chat Completions Agent
Azure OpenAI Chat Completions Agent
Google Gemini API Agent

To better use the Agent Snaps, we will be introducing new capabilities to some of our Function Generators as well. Here is the list of Function Generator Snaps that will be modified soon: