Flow-Native Agents Are Here: Build Agentic Workflows Directly in Breyta Flows

By Vegard Steen • Published 2026-04-28

Breyta introduces flow-native agents, allowing you to build, inspect, and manage AI agents directly within your existing workflows without external runtimes or glue code. This release enhances Breyta flows with dedicated agent steps, packaged tools, and improved data handling for robust and reliable agentic automations.

Breyta workflow automation

Build agentic workflows directly in Breyta flows

We have been working toward a simple idea: AI agents should not have to live outside your workflow platform.

Most agent setups today sit in a strange middle ground. They can reason, write, review, classify, or investigate, but they often need a separate runtime, a pile of custom glue code, local files, special credentials, and a lot of trust that the hidden process did the right thing.

That is powerful, but it can be hard to operate.

With this release, Breyta flows get a new flow-native agent model. You can now use an :agent step directly inside a normal Breyta flow, give it approved tools, pass it structured resources, and persist its output through the same run, table, file, and resource system you already use.

The goal is not to make agents magical. The goal is to make them usable, inspectable, and safe enough to build real workflows around.

Why this matters

Agents are most useful when they can do more than generate text.

A good agentic workflow often needs to:

  • inspect structured context
  • read files or tables
  • call approved APIs
  • compare evidence against a rubric
  • make a recommendation
  • write a result somewhere durable
  • hand work to a human or another automation step

Before this release, that usually meant choosing between two patterns.

You could run work over SSH in an existing environment. That is useful when the agent needs a specific machine, private network, or installed toolchain, but it couples the workflow to that environment.

Or you could dispatch a job to a separate worker. That works well for specialized long-running systems, but now you have two things to deploy, monitor, authenticate, and keep compatible.

Flow-native agents add a third option: keep the agent inside the flow.

The orchestration, LLM calls, tool calls, outputs, resources, retries, and run history all stay in Breyta. The agent becomes one step in a larger workflow instead of a side process that the flow has to chase.

The new :agent step

The :agent step gives flow authors a first-class way to run an objective-driven LLM agent.

You can give the agent:

  • an objective
  • instructions
  • structured inputs
  • provider settings
  • resource handles
  • a controlled list of tools

The important part is the tool boundary. An agent should not need broad ambient access to everything. It should get a bounded set of capabilities that were reviewed as part of the flow definition.

For example, a support triage agent might get tools for reading a ticket, fetching account context, and writing a follow-up task. A compliance review agent might get document retrieval, checklist, and escalation tools. A source-aware review agent might get file search and read-only repository inspection.

The flow author controls the surface area.

Packaged steps as safer tools

This release also adds top-level packaged :steps.

A packaged step wraps a lower-level operation, such as HTTP, files, table, function, or provider-specific behavior, behind a smaller named contract.

That makes flows easier to read and safer to extend.

Instead of exposing a raw HTTP request to an agent, you can define a packaged step like :risk/fetch-score or :triage/upsert-task. The credentials, endpoint, request shape, and normalization logic stay inside the reviewed flow definition. The agent only sees the tool it is allowed to use.

This pattern is useful even without agents. Packaged steps make large flows easier to compose because repeated operations can live in one named place instead of being copied throughout the orchestration.

Providers now have a canonical home

Flows can now declare common providers in a top-level :providers section.

That gives LLM and file/source provider requirements a consistent place in the definition. It also helps validation, CLI pull/push round trips, configuration screens, and connection reuse all agree on what the flow needs.

For example, a flow can declare an OpenAI-compatible provider, bind it to a workspace connection through :requires, and then use that provider from an :agent step.

This makes provider setup more explicit and reduces the amount of hidden convention in agent-heavy flows.

Agents can call agents

Some workflows need specialization.

A reviewer may need a researcher. A coordinator may need a classifier. A planning agent may need a domain-specific investigator before it can recommend what happens next.

Flows can now define reusable named agents and expose those agents as tools to another agent. That keeps the pattern inside the same run lifecycle: delegation, output, and evidence still belong to the flow.

This is especially useful when you want one agent to own the final decision while another agent gathers evidence or handles a narrower subtask.

Tables become handoff layers

Breyta tables now fit naturally into agentic workflows.

An agent can inspect incoming records, classify them, and write follow-up work into a table. That table can then drive a human review view, a scheduled flow, a notification, or another specialized agent.

The table row becomes the contract between stages: priority, owner, reason, proposed action, status, and resource links.

That is a lot easier to operate than burying state inside a prompt or a local file.

Source-aware workflows with :files

The new :files surface gives flows a safer way to work with source trees and changesets.

Flows can now resolve a provider-backed source, list files, read bounded slices, search contents, initialize changesets, make controlled edits, inspect diffs, publish changes, and open or reuse pull requests.

This makes review and remediation flows much more practical.

A flow can import a repository, pass file handles to an agent, ask for a bounded review, persist the findings, and, when appropriate, create a changeset for human review. The model is intentionally reviewable. Code changes should still move through a pull request, not disappear into an opaque agent run.

Durable file sessions

File work also needs to survive real runtime conditions: retries, restarts, and scaled deployments.

This release adds durable file sessions behind the authored :files step. The implementation now uses stable handles, leases, heartbeats, explicit expiry, recoverable metadata, and capture back into Breyta resources.

Flow authors do not need to manage those internals. They get a stable resource and session model that keeps file work inspectable across the run lifecycle.

Better validation and CLI round trips

Large authored flows need to be reliable as source artifacts.

This release tightens validation for the new surfaces and improves canonical pull, push, and validation behavior across the API and CLI. Flow definitions using providers, packaged steps, agents, files, templates, and local includes should round-trip cleanly through the normal Breyta CLI workflow.

The CLI also supports local #flow/include expansion, so authors can keep large templates, functions, instructions, schemas, and configuration payloads in separate files while still pushing a normal flow definition.

That matters for serious flows. Once a flow becomes more than a small demo, readability becomes part of reliability.

What this unlocks

The first strong use cases are review, classification, enrichment, triage, planning, investigation, and bounded remediation.

Some examples:

  • Review a set of documents against a policy and persist findings.
  • Triage support tickets and write structured follow-up tasks.
  • Enrich accounts using approved CRM, search, and scoring tools.
  • Analyze a repository and produce a source-backed review report.
  • Read one finding from a table, make a bounded file change, and open a pull request.
  • Build a reusable domain agent by combining packaged HTTP, table, and file tools.

This is not about handing an agent unlimited control. It is about giving it the right tools, the right context, and a durable place to put its work.

The bottom line

Agents are becoming a normal part of operational software. But for them to be useful in real workflows, they need the same things every other workflow step needs: clear inputs, bounded permissions, durable outputs, retries, observability, and a review path.

That is what flow-native agents bring to Breyta.

You can now build agentic workflows directly inside the flow definition, compose them with packaged tools, connect them to tables and files, and keep the entire process inside the normal Breyta run lifecycle.

No separate agent service required. No hidden local state. Just flows with better reasoning primitives.