In lowercase, a "loop" in these docs is a pattern you build with — task.loop, a cron schedule, a webhook, the four shapes in building agentic workflows. This page is one level up: it's about the Agentic Workflow, a first-class object Destaris is built around, and the lifecycle that ties it to a Workflow.

If loop engineering is the pattern, an Agentic Workflow is the thing that uses the pattern — a goal-driven brain that plans, tries, and adapts, and eventually builds the very workflow those patterns describe.

This object was called a Loop until recently, and the name now belongs to something else. A Loop is the object where you design the graph and write the success condition, and a small brain only judges each pass and corrects it. An Agentic Workflow — this page — is the one where the brain designs the graph. If you built the steps yourself, you want Loops.

None of this is meant to run somewhere you can't see it. Every step an Agentic Workflow takes — planning, building, adjusting — lands on the same canvas as the workflow it produces, so you're never handing real work to something you can't inspect.

The core idea: two states of one thing

An Agentic Workflow and a Workflow aren't two separate features. They're the same thing, seen at two points in its life:

| | Agentic Workflow — figuring it out | Workflow — figured out | | --- | --- | --- | | Driver | A brain plans and adapts | No brain; a fixed graph | | Determinism | Evolves run to run | The same every run | | Cost | Tokens, per run | Close to $0, per run | | Artifact | The workflow it's building | Reviewable, versioned YAML | | Right for | The process is still being worked out | The process has stabilised |

build ──▶ [ AGENTIC WORKFLOW: figuring it out ] ──migrate──▶ [ WORKFLOW: figured out ]
                 ▲                                                  │
                 └──────────────────── reactivate ◀─────────────────┘

Build. A brain takes a goal and assembles a workflow — reusing what already exists where it can, inventing where it can't — running it and adapting as it learns.
Migrate (Agentic Workflow → Workflow). Once an Agentic Workflow has produced the same result, the same way, for enough runs in a row, the brain has stopped earning its keep. The workflow it built graduates to a standalone Workflow: the brain retires, and the cost of a run drops toward $0.
Reactivate (Workflow → Agentic Workflow). When the work changes, breaks, or you want to evolve it, a settled Workflow re-opens as an Agentic Workflow. A brain reattaches, and what it learned last time comes back with it.

This is deterministic-first applied as a lifecycle, not just a rule for a single step: the brain is scaffolding you remove once the structure stands. The agent is agentic in how it builds; what it leaves behind is a plain, readable, migrate-able workflow — the same kind of workflow described throughout the rest of these docs.

Anatomy of an Agentic Workflow

An Agentic Workflow is three parts, kept deliberately separate.

The brain

A dedicated, ephemeral agent — spun up only at decision moments (to plan, re-plan, or judge progress) and spun back down in between. It never holds an entire run in its context; each invocation is a bounded decision: keep going, patch the workflow, resume from a step, restart, ask a human, or call it done. That's what keeps it cheap and focused, rather than a single long-running process narrating every action.

The memory

A structured store the brain reads and writes, so it has situational awareness without every sub-agent inheriting the whole history. Every entry carries a scope:

| Scope | Answers | Read by | | --- | --- | --- | | run | Where am I, right now, in this run? | The brain, mid-run | | loop | What have I learned across every run of this Agentic Workflow? | The brain, at the start of a new run | | workspace | What has any Agentic Workflow in this workspace learned? | Any Agentic Workflow that opts in |

Memory is a superset; no single agent gets all of it. Each sub-agent gets a small, curated slice of the goal-relevant context instead — fresh, cheap, and exactly as much as the task needs. Assembling that slice is a job the Agentic Workflow does on purpose, not an afterthought.

The workflow it builds

What the brain actually assembles and runs: sub-agents for the steps that need judgment, sub-workflows for the steps that don't. It reuses an existing workflow before it invents a new one — the same "don't repeat yourself" instinct you'd apply by hand, applied automatically.

How an Agentic Workflow runs

The cycle is plan → act → evaluate → adapt — the evaluate step is what makes it a loop rather than a script:

Plan. The brain records what it intends to do next.
Act. It reuses an existing workflow where one fits, or builds a new one where none does.
Evaluate. After a step, the brain checks progress against the goal.
Adapt. On a bad step, it re-plans and decides how to recover.

An Agentic Workflow can never run unbounded — an iteration cap and a hard engine ceiling are always the backstop, the same stop rules that already apply to a task.loop today, just enforced one level up.

The human gate

Real work has sign-offs — a design that needs approval, a decision only a person should make. This is the direction Agentic Workflows are being designed around, not a shipped capability yet: an Agentic Workflow reaches a checkpoint, records what it's waiting on, and spins the brain down to zero tokens rather than polling or blocking. A signal — a comment, an approval, an edit — wakes it, and it resumes from exactly that point instead of starting over.

Waiting this way is also where local brain, cloud spine is meant to matter most: a local Agentic Workflow can only wait by staying open and checking back in on an interval; a cloud-backed Agentic Workflow is designed to wait for you the same way the rest of the spine works — coordinating, never executing — so a gate that's open for days doesn't need your laptop open too.

Composition: one goal per Agentic Workflow

An Agentic Workflow has one goal. A bigger job is met by composing Agentic Workflows — one invoking another, sharing memory — rather than stuffing several goals into one. This keeps each Agentic Workflow legible on its own, and it's the same instinct behind keeping workflows small and composable: a growing library of solved, reusable pieces that Agentic Workflows (and other workflows) can call on, rather than one thing trying to do everything.

Why this doesn't abandon deterministic-first

The easy version of "AI that figures things out" is a black box you have to trust. Destaris' bet is the opposite: the brain's work is externalised as a workflow you can watch it build, read once it's built, and re-run for close to nothing after. The end state of a good Agentic Workflow is a boring, free Workflow — intelligence spent exactly while it's earning its keep, never after.

Loops — the third process object: your graph, your definition of "done", and a brain that only judges and corrects. Not this one, despite the name it used to have.
Building agentic workflows — the trigger/verifier/stop-rule patterns (cron, hook, heartbeat, goal loops) an Agentic Workflow's brain composes into a workflow.
Deterministic-first
AI opt-in per step
Local brain, cloud spine
Visual ↔ YAML