DEV Community: ByteChef

One Workflow, Many Lanes: Completing ByteChef's Flow Controls

ByteChef — Fri, 14 Aug 2026 18:36:57 +0000

TL;DR: ByteChef's workflow editor now exposes the full set of flow controls: alongside the familiar Condition, Branch, and Loop, you can drop Parallel, Fork/Join, Each, Map, and Subflow onto the canvas. That means workflows that fan out over lists, run independent steps concurrently, and call other workflows as reusable building blocks - all visually, no custom code. This closes out issue #1057, one of the longest-running feature checklists in the ByteChef repository.

Some GitHub issues are essays. Issue #1057 is a checklist:

[x] condition

[x] loop

[x] each

[x] branch

[x] map

[x] parallel

[x] fork-join

[x] subflow

Each of those checkboxes is a flow control - what the workflow engine internally calls a task dispatcher. A regular component does work: it sends the email, queries the database, calls the API. A task dispatcher never does work itself. It decides which tasks run, when, how many times, and with what data - it directs traffic.

We wrote about the first half of that checklist in our guide to flow controls: Condition routes on true/false, Branch picks one of several paths based on an expression, and Loop repeats steps over a list. Those cover decisions and repetition.

This post is about the second half - the controls that cover concurrency and composition. They've been running behind a feature flag while we hardened them one checkbox at a time; with the list complete, the flag is going away and the full set is available to everyone.

Why Sequential Isn't Always Enough

Every workflow starts as a straight line: trigger, then step one, then step two. That's the right default - it's easy to reason about, and each step can use the output of the one before it.

But real processes aren't always lines:

Onboarding a customer means creating a CRM record, provisioning an account, and notifying the sales channel - three things that don't depend on each other, so why wait?
Enriching 200 leads one at a time takes 200× as long as enriching them all at once.
Five different workflows all end with the same "notify the team" sequence, and you're tired of rebuilding it five times.

The first two are concurrency problems. The third is a composition problem. Here's the control for each.

Parallel: Independent Steps, All at Once

Parallel is the simplest of the new controls: give it a collection of tasks, and it runs them all concurrently without waiting for any of them to finish first.

{
    "name": "parallel_1",
    "type": "parallel/v1",
    "parameters": {
        "tasks": [
            {
                "name": "createCrmRecord",
                "type": "pipedrive/v1/createOrganization",
                "parameters": { "...": "..." }
            },
            {
                "name": "notifySales",
                "type": "slack/v2/sendMessage",
                "parameters": { "...": "..." }
            }
        ]
    }
}

Use it when you have a fixed set of different steps that don't depend on each other. The three-things-at-customer-onboarding case is exactly this.

Fork/Join: Parallel Branches, Sequential Inside

Fork/Join is Parallel's bigger sibling. Instead of a flat set of tasks, you define branches - each branch is a sequence of tasks that runs in order, but the branches themselves run in parallel to each other, each as its own isolated sub-flow:

{
    "name": "forkJoin_1",
    "type": "fork-join/v1",
    "parameters": {
        "branches": [
            [
                { "name": "fetchInvoices", "type": "..." },
                { "name": "summarizeInvoices", "type": "..." }
            ],
            [
                { "name": "fetchTickets", "type": "..." },
                { "name": "summarizeTickets", "type": "..." }
            ]
        ]
    }
}

The rule of thumb: reach for Parallel when each concurrent piece is a single step, and for Fork/Join when each concurrent piece is itself a pipeline. The "join" part means the workflow waits for every branch to finish before moving on, so the step after a Fork/Join can safely use results from all branches.

Each and Map: Fan Out Over a List

Loop already iterates over a list - but sequentially, one item at a time, in order. Each and Map iterate over a list in parallel: every item gets its own execution of the inner task at the same time.

The difference between the two is what you get back.

Each is for side effects. It runs the task for every item and returns nothing. Order of completion isn't guaranteed - and for firing off 200 notification emails, it doesn't need to be:

{
    "name": "each_1",
    "type": "each/v1",
    "parameters": {
        "items": "=leads",
        "iteratee": {
            "name": "sendFollowUp",
            "type": "gmail/v1/sendEmail",
            "parameters": { "to": "=each_1.item.email" }
        }
    }
}

Map is for transformations. It also runs in parallel, but it collects each item's result and returns them as a list - in an order that matches the source list, no matter which items finished first:

{
    "name": "map_1",
    "type": "map/v1",
    "parameters": {
        "items": "=range(1, 10)",
        "iteratee": [
            {
                "name": "enrich",
                "type": "...",
                "parameters": { "input": "=map_1.item" }
            }
        ]
    }
}

Inside the iteration, the current element is available as a data pill on the dispatcher itself - each_1.item, map_1.item - so inner steps can reference it like any other output.

So the lead-enrichment case from earlier: 200 leads, enriched concurrently, results back in the original order, ready for the next step. That's Map.

One honest footnote on the checklist: the infinite loop variant (loop until a break condition, with no list at all) is the one box still open on #1057. Loop already supports a Loop Break statement; the fully unbounded mode is still on the list.

Subflow: Workflows Calling Workflows

The controls above change how tasks run. Subflow changes what counts as a task: it starts another workflow as a child job of the current one, passes it inputs, and hands the child's output back as the step's output.

{
    "name": "subflow_1",
    "type": "subflow/v1",
    "parameters": {
        "workflowUuid": "notify-the-team",
        "inputs": {
            "channel": "#ops",
            "summary": "=map_1"
        }
    }
}

That's the composition problem solved: build "notify the team" once, with its own inputs, and call it from all five workflows. When it changes, it changes everywhere. Subflows show up in execution history as their own jobs, and the editor knows how to navigate into them so you can follow the chain.

Which One Do I Reach For?

You want to…	Use
Repeat steps over a list, one at a time, in order	Loop
Run a task for every item at once, no results needed	Each
Transform every item at once and keep the results, in order	Map
Run a fixed set of independent single steps concurrently	Parallel
Run several multi-step pipelines concurrently, then continue	Fork/Join
Reuse another workflow as a step	Subflow
Take one of two paths based on true/false	Condition
Take one of many paths based on a value	Branch

Two quick heuristics cover most decisions: per-item vs. fixed set (Each/Map/Loop iterate over data; Parallel/Fork-Join run a structure you defined), and results vs. side effects (Map collects, Each doesn't).

Why a Feature Flag, and Why It's Leaving

The workflow engine has been able to dispatch all of these for a while - the engine side of a task dispatcher is comparatively contained. The long tail was the editor. Every flow control is a nested structure on the canvas: it owns child tasks, those children need placeholders, drag-and-drop targets, correct auto-layout, and data pills that respect iteration scope. Getting Condition right taught us how much surface area each control adds, so we didn't ship the rest as one big drop.

Instead, the remaining controls went in behind a feature flag (ff-1057, named after the issue), which let us enable them incrementally, polish the rough edges. With every control now holding up in real workflows, the flag is being removed and the complete set becomes the default for every ByteChef instance - cloud and self-hosted.

If your workflows have been running in a single lane, give the new controls a try - the fastest way to feel the difference is to take an existing Loop over an independent list of items and swap it for a Map.

Stop the Workflow, Ask a Human: Human-in-the-Loop Approvals in ByteChef

ByteChef — Thu, 13 Aug 2026 15:20:34 +0000

TL;DR: ByteChef's Approval component pauses a running workflow until a person approves or rejects, optionally filling in a form whose answers flow straight into the next steps. Delivery is pluggable: Slack (with inline Approve/Discard buttons), Gmail, Outlook, Discord, Telegram, WhatsApp, and more - or ByteChef's new in-app Approval Tasks inbox. The approver clicks a signed link and needs no ByteChef account, and the workflow waits up to 60 days without holding a thread - human-in-the-loop (HITL), with no infrastructure of your own.

You build a workflow, and it runs beautifully - right up to the step you don't actually want it to run on its own. Issue the refund? Create the customer account? Book the leave?

Some steps shouldn't happen without a human's yes. What you want is simple to say: the workflow pauses, the right person gets pinged where they already work, they approve - maybe fill in a couple of fields - and the workflow picks up exactly where it stopped, with their answer in hand.

That pattern has a name - human-in-the-loop (HITL) - and in ByteChef it's the Approval component.

If you've read our use-case tutorials, you've already met it without an introduction. The KYC compliance workflow gates onboarding on a compliance officer's review. The Liferay onboarding workflow waits for a manager to fill in account details. PTO Elf holds leave requests for sign-off.

In each of those, approval was a supporting actor: "add an approval task here" and the tutorial moved on. This post is the missing introduction - what you configure, what your approver sees, and what the platform quietly does for you in between.

Adding an Approval Step

In the workflow editor, Approval is one component with one action: Request Approval. The minimal setup is no setup at all - leave everything blank and your approver simply gets Approve and Reject buttons.

Usually, you'll give it a form title, a description, and a list of form inputs. The form builder supports thirteen field types: text, textarea, number, email, password, checkbox, radio, select, date and datetime pickers, file upload, hidden fields, and raw custom HTML for anything else.

Each field carries the knobs you'd expect from a form builder: a label and description, a placeholder, a default value, and a required flag. Radio and select fields take label/value options, and a select can allow multiple choices with a minimum and maximum selection count.

Your Approver's Answers Become Data Pills

Here's the part that makes forms genuinely useful downstream: the approval step's output schema is generated from the fields you configure.

Add an accountName text field and a creditLimit number field, and the step's output is {approved: boolean, accountName: string, creditLimit: number}. Every one of those shows up as a data pill for the steps that follow.

That's how the Liferay tutorial creates an account "from the information received from the onboarding approval task" - the approver's answers are just the step's output, referenced like any other: ${approval_1.accountName}.

How the Approver Finds Out

A paused workflow is useless if nobody knows it's waiting. That's what approval channels are for - delivery mechanisms you attach to the approval step, right under the node's Channels port.

Most channels deliver the approval link to people outside ByteChef - a manager who has never opened the app and never will. Pick where your approvers already live: Slack, Gmail, Outlook 365, plain Email (SMTP), Discord, Telegram, WhatsApp, Twilio (SMS), Mattermost, Rocket.Chat, Infobip, or the embeddable Chat widget. Each uses its own connection.

The Slack channel has my favorite detail. If your approval has no form fields, there's no reason to send anyone to a web page, so it doesn't. Approvers get Approve and Discard buttons right in the Slack message, and the approval resolves without leaving the chat. If there is a form, the message carries a single "Open Approval Form" button instead.

One channel is different: Approval Task. Instead of sending the link out, it creates a task inside ByteChef, on the new Approval Tasks page - an approval inbox for teams that live in the app.

Each task has a status (open, in progress, completed), a priority, an assignee, and a due date, and the page supports filtering, search, and sorting. If your approvers are ByteChef users, their pending approvals queue up in one place instead of scattering across inboxes.

One small courtesy across all channels: they're skipped when the step runs inside the workflow editor's test mode, so testing a workflow doesn't spam your approvers.

And because channels are plug-ins (cluster elements) rather than baked-in integrations, the delivery list can grow without touching the Approval component itself.

What the Approver Experiences

Your approver clicks a link and lands on a form page: title, description, fields, and environment badge. No login, no account, no "first, install ByteChef" - which is the point, because the person approving is often exactly the person who'd never log in.

That works because the link itself is the credential. The token in the URL wraps the approval's identity in an HMAC signature, so it can't be guessed or forged - the same trust model as any webhook callback. Possessing the link is the authorization.

A link is good for exactly one decision. Once the approval is submitted - or the 60-day window passes - the link answers 410 Gone, so a stale email can't resurrect a settled question.

Meanwhile, the Workflow Waits

While your approver takes their time, what is the workflow doing? Nothing - and that's the engineering trick worth knowing about.

The approval action doesn't block a thread, poll a flag, or sleep. It registers a suspension with the engine and returns; the engine parks the execution, persists everything, and releases the worker. The workflow can stay parked for up to 60 days; the server can restart, redeploy, or scale to zero in the meantime. Nothing waits in memory.

When the approver submits, the engine re-enters the action through a second entry point with the submitted data, and the workflow resumes exactly where it stopped - the form answers flattened into the output schema those data pills promised.

Long-time users might remember the old ways of doing this: a dedicated wait-for-approval flow control and a Create Approval Links action that handed out bare approve/reject URLs. Both are now deprecated, because a flow control can pause but it can't be a component - with a form builder, a typed output, delivery channels, and one more trick below.

Coming Next: The Same Step, Inside an AI Agent

Human-in-the-loop matters most where the human is easiest to lose: AI agents. An autonomous agent is exactly as trustworthy as its worst tool call, and "pause and ask a person" is the simplest guardrail there is.

The suspend-and-resume machinery above is exactly what an agent needs, so we're working on exposing Approval as a tool you can hand to a ByteChef AI agent: the agent decides it needs sign-off, composes the form, calls the tool, and the whole agent conversation parks until a human answers. From the model's perspective, it asked a tool a question and the tool answered - it just took a day and a half.

It's not in today's build - we'd rather ship it solid than early - but it's close, and it lands in one of the next releases.

When You'd Reach for It

The use-case posts each show one pattern, and they generalize:

Gate: Nothing proceeds without a yes/no compliance review before account creation (KYC) or manager sign-off before booking PTO. No form fields needed; Slack buttons suffice.
Gate with input: the approver doesn't just consent; they contribute - the Liferay onboarding manager supplies the account name and description the next step uses to create the account.
Threshold escalation: the workflow handles the routine cases on its own and branches into an approval only for the consequential ones - refunds over a limit, contract changes, anything you'd want a human to see before it happens.

If you want to see approval in a full workflow, the KYC compliance and Liferay onboarding posts both build one end-to-end, and now you know what's happening under the pause.

See What Your Workflow Was Thinking: Surfacing Component Logs in ByteChef

ByteChef — Fri, 07 Aug 2026 19:55:03 +0000

TL;DR: ByteChef's Logger component could always write log messages - but they vanished into the server console, where workflow builders could never see them. We fixed that by capturing log calls at the layer every component passes through, storing them per execution, and exposing them in a new Logs tab in both the workflow builder and the execution history. Every component's logs - not just Logger's - now show up next to the step's Input and Output, with level badges, JSON pretty-printing, and expandable stack traces.

Every automation platform eventually gets this ticket. Ours was issue #2896, and it was refreshingly short:

As a Workflow Developer, I want to see logs from the Logger component in the workflow builder and workflow executions, so that I can see details of how my workflows are executing.

ByteChef has had a Logger component for a long time. You drop it between two steps, give it a message - usually with a few data pills in it - and pick a level: Debug, Info, Warn, or Error. That's the whole component.

The problem: the message went to the server log and nowhere else. If you self-hosted ByteChef and had shell access, you could tail the server log and find it. If you were a workflow builder working in the UI - the person the Logger component exists for - it went into a void. The component technically worked and was practically useless.

Deciding Where to Capture

The obvious fix would have been to special-case the Logger component: make it return its message as step output, or write to some Logger-specific store. We went a different way, and it's the decision the whole feature hangs on.

Every component action in ByteChef receives an execution context, and that context's logging method is the sanctioned way for any component to log - the HTTP client logs request failures, Script components log from user code, AI components log token usage warnings. All of those messages were equally invisible.

So instead of touching the Logger component at all, we instrumented the logging implementation inside the component context - the single funnel that every log call in every component already passes through. Each message still goes to the server log like before, but now it also becomes a structured entry: timestamp, level, component name, operation, the step it came from, the message, and - when there is one - the exception type, message, and stack trace.

Because the capture point sits below every component, the feature ships for all 180+ components at once. The Logger component didn't change by a single line. It just became visible.

Storing Logs: One File per Execution

Logs are append-heavy, read-rarely data with an obvious partition key: the job - a single workflow execution. That ruled out a database table. We didn't want every workflow run inserting rows into PostgreSQL for data that's mostly never queried.

Instead, each job gets one file in ByteChef's existing file-storage abstraction, which means logs land wherever your deployment already puts files - the filesystem, a database blob, or S3-compatible storage. The format is JSON Lines: one JSON object per line, so appending an entry is just serialize-and-append.

Two properties of the writer matter more than they look.

First, writes are asynchronous. Logging must never slow down the workflow itself - a component that logs five times shouldn't pay five rounds of storage I/O on the execution path. Java 25's virtual threads make that fire-and-forget pattern nearly free.

Second, the read path is guarded by the same permission model as everything else that touches executions. Logs frequently contain payload data - that's the point of logging them - so they inherit the exact visibility rules of the execution they belong to. If you can't see the run, you can't see its logs.

Two Environments, Two Pipelines

There's a wrinkle: ByteChef has two kinds of "execution". There are production runs of deployed workflows, and there are test runs you trigger with the Test button while building a workflow in the editor. Test runs are ephemeral - their logs shouldn't accumulate in long-term storage next to production history.

So the feature is split down the middle. Production runs write to the long-term log area and are served to the execution history view. Editor runs write to a separate area with their own cleanup, served by a parallel query. The context factory decides which writer a component gets based on which environment it's running in, and the client picks the matching query. Same UI, same log format, different lifecycle.

The Read API

The read API is GraphQL, matching where the rest of ByteChef's newer client-server surface has been heading. It supports pagination and filtering from day one: minimum level, component name, a specific step, a time range, and free-text search.

The per-step filter is what powers the most-used view: click a node in the execution panel, and you see only that step's logs. Look at the job as a whole, and you see everything, with a small component-name chip on each row so you can tell who said what.

The Logs Tab

On the client, the execution detail panel - the one with Input and Output tabs you get when you click a step - gains a third tab: Logs.

That's a real run above - and it's worth noting whose log you're looking at. The workflow has a Logger component in it, sitting right there in the graph on the right. But the entry on screen came from the OpenAI step, which logged its outgoing request without anyone asking it to. That's the capture-one-layer-down decision paying off in a screenshot: the component that made the ticket necessary isn't even the one being shown.

Each row shows a timestamp, a colored level badge (blue INFO, purple DEBUG, yellow WARN, red ERROR), and the message. Two small touches make it feel finished rather than bolted on:

JSON detection. People constantly log entire objects - dumping a payload into a log line is a very common debugging move. If a message parses as JSON, the tab renders it with the same collapsible tree viewer we use for step outputs, instead of an unreadable one-liner.

Expandable errors. When an entry carries exception details, the row becomes clickable and expands into the exception type, message, and full stack trace - so a failed step's story is readable in place, without asking an operator to grep the server log for you.

And because the editor pipeline exists, the same tab appears in the workflow builder's test output panel. Run a workflow with the Test button, click a step, open Logs - the feedback loop that issue #2896 asked for, closed.

One Layer Down

The lesson we're taking from this one: when a ticket says "make the Logger component's output visible", the right fix might be one layer down. By instrumenting the context instead of the component, a request about one component became execution-level observability for every component in the platform - including the ones we haven't built yet.

Building Intelligent Automation with ByteChef and AI Agents

ByteChef — Tue, 16 Jun 2026 17:46:21 +0000

TL;DR: ByteChef's AI Agent is a visual, no-code building block for agentic workflows, powered by Spring AI under the hood. It's composed of five cluster elements: a Model, RAG, Memory, Tools, and Guardrails. And you don't build blind — the editor's Agent Playbook lets you test the agent live as you configure it. Together, they give you everything needed to build production-grade AI agents without writing your own AI infrastructure.

Artificial intelligence is supported for every programming language nowadays. With the right tools, every developer can embed intelligent behavior directly into their workflows and automations. ByteChef's AI Agent component makes this possible by integrating deeply with Spring AI, the leading Java framework for building AI-powered applications. Exposing it through a visual, no-code/low-code interface.

In this post, we'll walk through how ByteChef's AI Agent is structured, what each of its cluster elements does, and how Spring AI powers it all under the hood.

What Is the AI Agent Component?

The AI Agent is ByteChef's core building block for agentic workflows. Rather than making a single call to a language model, an AI Agent can: reason, retrieve context, remember past interactions, call external tools, and even delegate to other agents. It is capable of handling complex, multi-step tasks.

The AI Agent is composed of a set of cluster elements: configurable sub-components that each handle a specific aspect of agentic behavior. These are:

Model - the language model powering the agent
RAG - retrieval-augmented generation for grounding responses in your data
Memory - persistence of conversation history across turns
Tools - actions the agent can do
Guardrails - filters for safe and appropriate responses

Let's explore each one.

Model

The model is the brain of the AI Agent. It defines which LLM receives prompts, thinks and generates responses. Spring AI provides a unified ChatModel abstraction that normalizes communication across many different LLM providers, so ByteChef can support a wide range of models without changing the underlying agent logic.

ByteChef currently supports the following models, all integrated through Spring AI:

Amazon Bedrock Converse - access to AWS-hosted models including Anthropic Claude, Meta Llama, and more via a unified AWS API
Anthropic - Claude models, known for their strong instruction-following and reasoning
Azure OpenAI - OpenAI models deployed on Microsoft Azure infrastructure
DeepSeek - high-performance models with strong coding and reasoning capabilities
Vertex Gemini - Google's Gemini models via Google Cloud's Vertex AI platform
Groq - ultra-fast inference for open-source models
Mistral AI - efficient, open-weight European models
NVIDIA - models served via NVIDIA's NIM inference platform
Ollama - open-source models locally with no cloud dependency
Perplexity - models with built-in web search and citation capabilities
OpenAI - OpenAI models deployed by OpenAI

In addition to these Spring AI-backed providers, ByteChef also supports OpenRouter, a gateway that aggregates hundreds of models from dozens of providers under a single API. This means that even if your preferred model isn't in the list above, there's a very good chance you can still connect to it through OpenRouter. This makes ByteChef's AI Agent one of the most model-versatile automation platforms available.

RAG (Retrieval-Augmented Generation)

Language models are powerful, but they only know what they were trained on. If you want your agent to answer questions about your internal documents, product catalog, support tickets, or any proprietary data, you need Retrieval-Augmented Generation (RAG).

RAG works by searching a knowledge source for documents relevant to the user's query, then injecting that context into the prompt before the model generates a response. Spring AI provides a rich, modular RAG architecture that ByteChef exposes directly in the AI Agent.

Vector Store Providers

To perform semantic search, documents are embedded into high-dimensional vectors and stored in a vector database. ByteChef supports the following vector stores:

Couchbase
MariaDB
Milvus
Neo4j
Oracle
PostgreSQL (pgvector)
Pinecone

Knowledge Base

Don't want to set up your own vector database? ByteChef also offers a built-in Knowledge Base — an internal, managed knowledge store where you can upload documents (PDFs, text files, and more) directly. ByteChef handles the chunking, embedding, and storage automatically, so you can start building RAG-powered agents without configuring any external infrastructure.

RAG Strategies

Spring AI supports two RAG approaches:

QuestionAnswerAdvisor is Spring AI's out-of-the-box RAG implementation. When a query comes in, it performs a similarity search against the vector store, retrieves the most relevant documents, and appends them to the prompt as context before the model responds. It supports configurable similarity thresholds, top-K result limits, and dynamic filter expressions so you can scope searches to specific subsets of your data.

Modular RAG is based on Spring AI's RetrievalAugmentationAdvisor and inspired by the research paper "Modular RAG: Transforming RAG Systems into LEGO-like Reconfigurable Frameworks." Instead of a fixed pipeline, it lets you assemble a RAG flow from individual building blocks, each responsible for one well-defined step. ByteChef exposes the following modules:

Query Transformers - applied before retrieval to reshape the user's query into something that retrieves better results:
- Compression - condenses a long conversation history and a follow-up question into a single standalone query, so the retriever receives focused input rather than a wall of chat context.
- Rewrite - rewrites verbose, ambiguous, or poorly structured queries into a cleaner form that maps more accurately to the content in your knowledge source.
- Translation - translates the query into the language of your documents, enabling cross-lingual retrieval without requiring your data to be multilingual.
Multi Query Expander - uses a language model to expand the original query into multiple semantically diverse variations, each capturing a different angle or phrasing of the user's intent. Documents are retrieved for all variations in parallel, increasing the chances of surfacing relevant results that a single query might miss. Any model available in ByteChef can be used to power the expansion.
Document Retriever - the step where documents are actually fetched from a vector store using semantic similarity search. You can select any of the vector stores ByteChef supports (Couchbase, MariaDB, Milvus, Neo4j, Oracle, PostgreSQL, or Pinecone), or point it at the built-in Knowledge Base.
Document Joiner - when multiple queries or multiple data sources are involved, this module merges all retrieved document sets into a single, deduplicated collection. Duplicate documents are resolved by keeping the first occurrence; relevance scores are preserved as-is from the retriever.
Contextual Query Augmenter - enriches the user's query with contextual information extracted from the retrieved documents before it is sent to the model. This helps the model produce more grounded, contextually aware responses. Together, these modules let you design a RAG pipeline tailored to your data and use case — from a simple single-retriever setup to a multi-source, multi-query flow with query rewriting and context augmentation — without writing any retrieval infrastructure yourself. ---

Memory

A single question-and-answer interaction is useful, but many real-world use cases require the agent to maintain context across a conversation. Remembering what was said earlier, tracking user preferences, or picking up where a previous session left off are what Memory provides.

Spring AI's ChatMemory abstraction handles storing and retrieving conversation history. ByteChef exposes multiple memory backend options:

External memory providers - for durable, production-grade memory that persists across sessions and scales with your application:

Cassandra
Cosmos DB
MongoDB
Neo4j
Redis
MySQL
Oracle
PostgreSQL

Additionally, all vector stores supported for RAG (Couchbase, MariaDB, Milvus, Neo4j, Oracle, PostgreSQL, Pinecone) can also serve as memory backends, enabling semantic retrieval of past conversation turns rather than just chronological lookups.

InMemory Chat Memory is a lightweight option that stores conversation history in a simple HashMap in application memory. It requires no external setup and works great for development, testing, or short-lived sessions — but the history is wiped when the chat session ends.

Chat Memory (ByteChef's internal store) is the managed alternative to external providers. Like the Knowledge Base for RAG, it lets you persist conversation history without configuring a separate database. ByteChef handles the storage backend for you.

Tools

One of the defining features of an AI agent is its ability to act. Tools let the AI Agent go beyond generating text and actually interact with external systems: querying databases, sending emails, creating records, calling APIs, and more.

ByteChef's tool support is one of its most powerful differentiators, and it comes in several forms:

Component Actions - ByteChef integrates with over 200 applications and services through its component library (think Slack, GitHub, Salesforce, Google Sheets, HubSpot, and many more). Any action within any component can be exposed to the AI Agent as a tool. When configuring a tool, you choose which properties the AI should determine dynamically based on context, and which ones are fixed constants — so you stay in full control of what the agent can and cannot change.

MCP Tool - ByteChef supports the Model Context Protocol (MCP), an emerging open standard for exposing tools to AI models. The MCP Tool cluster element lets the agent connect to any compatible MCP server and use its tools, opening up the ecosystem beyond ByteChef's built-in integrations.

Skills Tool - ByteChef supports the concept of Skills: reusable, self-contained packages of instructions and files that you build once and reuse across agents. The Skills Tool cluster element lets the agent invoke any Skill available in your ByteChef workspace. (More on creating and managing Skills later in this post.)

AI Agent as a Tool - the most powerful option of all: an AI Agent can use another AI Agent as a tool. It's important enough that it gets its own section below.

Guardrails

Guardrails are ByteChef's own layer of control on top of the Spring AI-powered capabilities. While the other cluster elements are about making the agent smarter and more capable, Guardrails are about keeping it appropriate and safe.

Guardrails can be configured to inspect both incoming requests and outgoing responses. Common use cases include:

Content filtering - blocking or censoring sensitive, inappropriate, or offensive words and phrases
Topic restrictions - preventing the agent from discussing subjects outside its intended scope
Compliance controls - ensuring responses don't contain regulated or legally sensitive information

Unlike the other cluster elements, Guardrails are a ByteChef-native feature, not part of Spring AI. They sit as a wrapper around the agent interaction, giving you a transparent enforcement layer regardless of which model, RAG strategy, or memory backend you've chosen.

Skills: Build Once, Reuse Across Agents

The Tools section introduced the Skills Tool, which lets an agent call a Skill. But where do Skills come from? ByteChef includes a dedicated Skills area for building and maintaining them, so a capability you define once becomes available to every agent in your workspace.

A Skill is a self-contained, reusable package of instructions and supporting files — essentially a .skill archive built around a primary SKILL.md (the instructions, with optional frontmatter metadata) plus any extra files it needs. Each Skill has a name and a description, and once it lives in your workspace, any number of agents can invoke it through the Skills Tool. Build the capability once; reuse it everywhere.

There are three ways to create one:

Write instructions - give the Skill a name and description, then write what it should do in plain text. ByteChef packages it for you.
Upload a .skill file - drag in a pre-built Skill archive, handy for moving a Skill between workspaces or sharing it with teammates.
Create with AI - describe what you want ("a skill that summarizes my Gmail every morning") and let Copilot draft the Skill's structure and content for you.

Once created, a Skill opens in a built-in editor: a file tree on the left, and a dual-mode view that toggles between a source editor (Monaco, with syntax highlighting for Markdown, Python, JavaScript, YAML, JSON, and more) and a Markdown preview for .md files. You can edit any file in the Skill, save your changes, download the Skill as a .skill archive to share, or delete it.

Because Skills are decoupled from any single agent, they become a shared library of capabilities for your whole workspace: capture a procedure or a piece of know-how once, then wire it into as many agents as you like through the Skills Tool.

AI Agents as Tools: Multi-Agent Systems

Perhaps the most powerful tool an AI Agent can use is another AI Agent. Because the AI Agent is itself a cluster-element building block, you can configure a second agent — complete with its own model, RAG, memory, tools, and guardrails — as a tool for the current agent to call.

This is the foundation for building agentic patterns such as orchestrator/subagent hierarchies, where a supervisor agent breaks a complex request into parts and delegates each one to a specialized sub-agent — a research agent, a drafting agent, a data-lookup agent — each tuned for its own job. The supervisor decides which sub-agent to call and when, then combines their results into a final answer.

Because the composition is recursive — agents calling agents, which can in turn call their own sub-agents — there's no artificial ceiling on how sophisticated the system can get. That recursive composability is what makes ByteChef's AI Agent a genuine platform for multi-agent systems, not just a runtime for a single agent.

Putting It All Together

The power of ByteChef's AI Agent comes from how these cluster elements combine. A production-grade agent might use:

OpenAI GPT-4o as the model for strong reasoning
Modular RAG with a Pinecone vector store to ground answers in internal documentation
PostgreSQL memory to remember past conversations per user
Component actions to create CRM records, send notifications, or update spreadsheets
Guardrails to ensure every response is appropriate for the audience

And because ByteChef is built on Spring AI, you benefit from a well-maintained, actively developed foundation that keeps pace with the rapidly evolving AI ecosystem, new models, new vector stores, and new capabilities get integrated continuously.

Whether you're building a customer support agent, an internal knowledge assistant, a data processing pipeline, or a complex multi-agent system, ByteChef's AI Agent gives you the building blocks to do it without needing to write your own AI infrastructure from scratch.

Test Your Agent as You Build It

Assembling an agent is only half the job — you also need to know it behaves the way you expect before it ever touches a real workflow. ByteChef bakes this in. The AI Agent editor is a split view: your configuration sits on the left, and an interactive testing panel — the Agent Playbook — sits on the right. You build and test side by side, without ever switching screens.

Click Test Agent and the panel turns into a live chat. Send sample messages that imitate the kind of input real users will send, and watch the agent respond in real time — responses stream in token by token, exactly as they will in production. A couple of suggested prompts, like "What can you help me with?" and "What tools do you have access to?", give you a quick way to get started.

What makes the Agent Playbook more than a chat box is its transparency into the agent's reasoning. Whenever the agent decides to call a tool, an expandable card appears inline in the conversation, showing:

which tool was invoked,
the agent's reasoning for choosing it,
a confidence score, when the agent provides one,
the exact input parameters the agent passed, and
the output the tool returned.

This means you're not just seeing the final answer — you're seeing how the agent got there. If it picks the wrong tool, invents an argument, or skips a step, you'll catch it right away instead of discovering it in production.

Crucially, testing runs against your in-progress configuration. There's no save-and-deploy cycle: tweak the system prompt, swap the model, add or remove a tool or a guardrail, then hit Reset conversation and try again. The loop between changing the agent and seeing the effect is measured in seconds. And because the panel lives inside the workflow context, you can feed it workflow variables (data pills, via $) to mirror the data the agent will actually receive at runtime.

Ready to try building with the AI Agent in ByteChef for yourself?

Welcome to ByteChef

ByteChef — Thu, 23 Apr 2026 16:12:12 +0000

ByteChef is an open-source, AI-native data orchestration platform created for teams that want to treat automation as infrastructure and not just a collection of app connections.

It removes common operational pains such as high costs, inefficiency, human error and growth limitations.

With ByteChef you can automate repetitive tasks that waste time and introduce mistakes and also orchestrate complex, multi-step business processes that would otherwise slow growth and reduce operational reliability.

Stepping Outside the Comfort Zone

Being in the familiar space is comfortable, but growth begins the moment you step into the unknown. New ways of working can feel very intimidating at first, especially when it comes to improving how your systems, data and processes connect and operate together.

There is no perfect starting point, you experiment, adapt, and gradually discover better ways of working. Over time, what once felt complex becomes intuitive and you begin to see the real value of using the right tools effectively.

Properly orchestrating your data and apps, removes burdens from your daily operations.

ByteChef is built on a simple idea, that people shouldn’t spend their time repeating the same steps every day.

That energy is far more valuable when focused on thinking, creating and solving meaningful problems.

As an open-source platform, ByteChef gives teams the freedom to experiment, innovate, and build solutions that truly match the way they work.

Instead of adapting your processes to fit rigid tools, you can design workflows around your real operational needs, without vendor lock-in.

You can build, test and validate workflows step by step before deploying them, with full transparency and control.

Visual Workflows that Simply Make Sense

To simplify workflow creation and help you visualize how data moves between tasks, ByteChef provides a free-form workflow editor with intuitive drag-and-drop functionalities.

This allows you to quickly adapt and update each step as your processes evolve. Every step is laid out on the canvas, connections are clear and you always know what’s happening and why.

Purpose‑built flow controls such as condition, branch, loop, parallel, and many more, allow you to precisely manage how data moves through each workflow and apply custom logic wherever needed.

Whether you need to split logic based on conditions, process lists of items one by one, run tasks at the same time, or repeat steps until a condition is met, the visual tools turn complex ideas into simple logic.

All of this is possible without writing a single line of code, but if you prefer a more technical approach, ByteChef also supports code-based workflows through a built-in code editor and custom script component.

This clarity makes workflows easier to build, review and maintain.

Data is at the heart of every workflow and that's where the dynamic values shine. They allow you to securely reuse data across different apps and workflow steps without manual copying, pasting or reformatting.

In ByteChef, every component produces structured output data and those outputs automatically become dynamic values that can be used in any step that follows.

This creates a continuous, traceable data flow where information moves logically from one task to another.

You always know what data you’re working with, where it comes from, and where it goes next. This removes one of the biggest sources of uncertainty in automation: invisible data handling.

AI Powered by the Models You Choose

ByteChef allows you to integrate Large Language Models directly into your workflows, making it easy to add intelligence wherever it is needed.

Instead of being locked into a single provider, you can connect to a wide range of leading AI model services and use them as part of your automation logic. This gives you the flexibility to choose models based on performance, cost efficiency and internal compliance requirements.

Because LLMs operate as workflow components, their outputs become data that can be reused in later steps just like any other dynamic value.

ByteChef continues to expand its AI capabilities with upcoming enhancements such as an in-app AI Copilot for natural language workflow building, advanced AI Agents for autonomous task execution and extended integration frameworks that connect AI systems more deeply with business tools.

Our goal is to make AI practical, controllable and seamlessly embedded into real operational processes.

Built for Control and Trust

Powerful workflows require more than flexibility, they require governance, security and full operational control.

ByteChef allows you to automate with confidence while meeting internal security standards and compliance requirements. Every workflow can be observed, tested and managed with transparency across its entire life cycle.

You can deploy ByteChef on your own infrastructure for full data sovereignty or run it in the cloud, depending on your operational and regulatory needs.

For sensitive operations, approval steps can be added directly into workflows, allowing human oversight where it matters most. Detailed audit logs track workflow activity and system actions, providing traceability and accountability for enterprise environments.

Focus on What Matters, Automate the Rest

ByteChef is designed for messy, real-world use cases, complex tasks that need better solution, so it enables teams to design automation as operational infrastructure rather than temporary shortcuts.

Time is lost on repetitive tasks, jumping between apps, manual handovers and keeping systems in sync. These small inefficiencies build up creating friction, avoidable errors, rising operational costs and unnecessary complexity that slows growth.

With more than 180 integrations, ByteChef connects the tools your team already relies on and turns disconnected processes into coordinated workflows.

If you’re curious to see how we can help your team reclaim time:

Visit ByteChef
Explore the platform
Start automating :)

It's that simple!

Focus on the work that truly matters, and let ByteChef handle the rest.