Agentic loops are extraordinary. You describe a goal, hand over some tools, and the model figures out the rest. It calls APIs, transforms data, delegates to subagents, and converges on an answer. For open-ended problems, this is exactly what you want.
But not every problem is open-ended.
Some processes are completely deterministic. Step A always runs first. Step B always uses A’s output. Step C always posts the result to a webhook. The steps don’t change. The order doesn’t change. The only variable is the data flowing through. And yet, if you implement this as an agentic loop, you’re burning tokens asking the LLM to figure out the same sequence every single time, hoping it doesn’t skip a step, reorder them, or hallucinate a tool call that doesn’t exist.
We hit this wall while building a content pipeline for a client.
The Problem with Pure Agency
The pipeline was straightforward: search the web for a topic, summarize the results, then POST the summary to a Slack webhook. Three steps. Always the same three steps. Always in the same order.
We built it as an agent. The agent had three tools: web search, summarization, and HTTP request. We gave it a system prompt describing the exact pipeline. And it worked. Most of the time.
Sometimes the agent decided to skip the search and summarize from its own knowledge. Sometimes it called the webhook before summarizing. Once, it invented a fourth tool that didn’t exist and reported a tool execution error. The non-determinism wasn’t a bug in the agent. It was a feature. The agent was reasoning about what to do next, and occasionally its reasoning diverged from the intended path.
We tried harder system prompts. We tried few-shot examples. We tried lower temperatures. Each fix helped marginally but introduced new failure modes. The fundamental issue remained: we were using a reasoning engine to execute a process that required no reasoning.
The insight was simple. Some processes are deterministic by nature. Step A always feeds step B, step B always feeds step C. For these, you don’t need an agent to decide what happens next. You need a pipeline that executes steps in a guaranteed order, with data flowing between them automatically.
But we also didn’t want to lose the ability to use LLM intelligence where it’s genuinely needed. The search step doesn’t need an LLM. The webhook step doesn’t need an LLM. But the summarization step absolutely does.
We needed a way to say: do exactly this, in exactly this order, and use AI only where human judgment is actually required.
What We Built
SAGE Workflows are code-defined directed acyclic graphs (DAGs) that execute inside SAGE. Each workflow is a static blueprint: a list of typed steps with explicit dependencies, an input schema, and a trigger that determines how and when the workflow starts.
The execution engine resolves the dependency graph, determines which steps can run in parallel, interpolates data between steps using a template syntax, and dispatches each step to its type-specific executor. The result is deterministic: the same workflow definition, given the same input, will always execute the same steps in the same order.
This is not a visual builder. Workflows are defined in TypeScript, which means they’re type-safe, version-controlled, code-reviewed, and testable. They live alongside the rest of your application code, not in a separate dashboard.
The critical design decision: workflows complement the agentic loop, they don’t replace it. An agent step within a workflow invokes the full SAGE agentic loop, with tool access, streaming, context management, and everything else, inside a single step of a deterministic pipeline. You get reliable orchestration with LLM intelligence injected exactly where you need it.
Eight Step Types
Workflows support eight step types, each purpose-built for a different kind of operation.
Tool steps execute any registered SAGE tool. The same tools your agent uses in conversation are available in workflows. A tool step runs the tool with interpolated arguments and captures the result for downstream steps.
Agent steps are what make SAGE Workflows fundamentally different from every other workflow engine. An agent step runs the full SAGE agentic loop inside a single workflow step. You specify a system prompt, a message (which can interpolate data from previous steps), optional tool filters, and model overrides. The agent reasons, calls tools, handles multi-turn interactions, and returns a result. All within the bounds of a deterministic pipeline. This means you can build workflows where 90% of the steps are predictable (fetch data, transform, POST to API) and 10% require genuine intelligence (analyze this document, draft a response, classify this input).
HTTP steps call external APIs. You define the URL, method, headers, and body, all of which support interpolation. The step handles JSON parsing automatically and throws on non-OK responses, which triggers the error handling system.
Transform steps perform pure data transformation between steps. They evaluate a JavaScript expression with access to the full workflow scope (all previous step outputs and the original input). Use these for reshaping data, filtering arrays, computing derived values, anything that doesn’t need external calls.
Conditional steps branch the DAG based on an expression. They evaluate a condition and return which branch to take (then or else), along with the target step ID. The engine skips steps in the non-taken branch. This gives workflows if/else logic without adding non-determinism. The branching is explicit and auditable.
Delay steps pause execution for a specified duration. Useful for rate limiting, cooldown periods between API calls, or waiting for an external process to complete.
Parallel steps coordinate concurrent execution of multiple step IDs. While the engine already runs independent steps in parallel automatically (any steps whose dependencies are all satisfied), parallel steps make this explicit for readability and allow you to define fan-out patterns.
Sub-workflow steps execute another workflow by ID. This enables composition: you can build complex workflows from smaller, reusable workflow definitions. The sub-workflow receives its own input (interpolated from the parent) and its output becomes available to subsequent steps in the parent.
Data Flow: The Interpolation Engine
Data flows between steps through an interpolation engine that resolves template expressions at runtime.
The syntax uses double-brace expressions. You can reference the workflow input, read from any completed step’s output, or traverse nested paths including array indices. If you need the third search result’s title, you write the path and the engine resolves it.
The engine is type-aware. A standalone expression preserves the original type. If the output is an array, the interpolated value is an array, not a stringified version. Expressions embedded inside a larger string stringify and concatenate automatically. This distinction matters because it means you can pass structured data between steps without serialization overhead.
Interpolation works recursively through objects and arrays, so you can interpolate inside complex nested structures. A webhook body, for example, can reference the summarizer’s output content, the original input topic, and a computed result count from a search step, all resolved automatically before the HTTP request fires.
Consider the content pipeline from earlier. You define the workflow with three steps: a tool step that searches the web using the input topic, an agent step that summarizes the search results, and an HTTP step that posts the summary to a webhook URL from the input. That’s the entire pipeline. No routing logic. No prompt engineering to convince the agent to follow a sequence. The search always runs first, the agent always summarizes the search output, and the webhook always fires with the summary. The only LLM call is in the summarization step, where genuine language understanding is needed.
Triggers
Workflows need to start somehow. SAGE supports four trigger types.
Manual triggers are the default. You execute the workflow from your application code: an API route, a cron job, a button click handler. This is the most flexible option because the calling code controls when and why the workflow runs.
Schedule triggers use cron expressions. The trigger manager checks schedules every 60 seconds and executes matching workflows automatically. This handles recurring tasks like daily reports, periodic data syncs, or scheduled content generation.
Webhook triggers generate an HTTP handler you can mount on any route. An incoming POST request becomes the workflow input, and the response includes the execution ID and output. This is useful for integrating with external services that push data via webhooks: payment processors, CI systems, form submissions.
Event triggers subscribe to an internal event bus. When your application emits a named event, any workflow listening for that event fires automatically. This is the most loosely coupled option, ideal for reacting to system events without creating direct dependencies.
Error Handling and Reliability
Production workflows need to handle failures gracefully. SAGE provides three error strategies, configurable per step.
Fail is the default. If a step fails (after retries), the workflow fails immediately. Failed steps record their error, and the workflow’s output includes the error message for debugging.
Continue marks the failed step as skipped and keeps executing. Downstream steps that depend on the skipped step also get skipped, but independent steps continue normally. This is useful when a step is best-effort. You want the webhook notification even if the enrichment step fails.
Fallback redirects execution to a designated fallback step. This lets you define recovery logic: if the primary API times out, use a cached result instead.
Retries use exponential backoff with configurable max attempts, reusing SAGE’s existing retry utility. Each step tracks its retry count, and retry events are emitted to the stream for observability.
The engine also supports cancellation via AbortController and timeouts at both the workflow and individual step level. Between each step execution, the engine checks whether the abort signal has been triggered, enabling graceful shutdown without orphaned processes.
How This Compares
The workflow space is crowded. Here’s where SAGE Workflows fit.
Compared to N8N: N8N is a standalone visual workflow platform with 400+ integrations, a drag-and-drop builder, and its own runtime. SAGE Workflows are an embedded library that runs inside your existing application. There’s no separate service to deploy, no visual editor to maintain, and no additional infrastructure. You trade the visual builder for type safety, version control, and zero deployment overhead. If you need a standalone workflow platform, N8N is excellent. If you need deterministic pipelines inside an existing AI agent application, that’s what SAGE Workflows are built for.
Compared to LangGraph or CrewAI: These frameworks focus on multi-agent orchestration, coordinating multiple AI agents with different roles. SAGE Workflows focus on deterministic pipelines that use agents only where needed. The agent step is one of eight step types, not the foundation. This means most of your workflow is predictable, fast, and cheap (no LLM calls), with intelligence injected surgically into the steps that require it.
The unique position: LLM-native agent steps inside a deterministic DAG, defined in TypeScript, running natively inside SAGE. No YAML. No JSON configs. No separate runtime. Code-first, type-safe, composable.
The AI industry has a tendency to apply LLMs to everything. But intelligence has a cost: latency, tokens, and unpredictability. Not every problem needs an autonomous agent reasoning about what to do next. Some problems need a reliable pipeline that does exactly what you told it to, every time, with AI brought in only for the steps that genuinely benefit from it.
Workflows are SAGE’s answer to that balance. Deterministic where it matters. Intelligent where it counts. And defined in code, where it belongs.