You ran a workflow with two steps. Each step did something a normal Python function would do — an HTTP call and an LLM call — but neither one ran in the way a normal function does.

Five concepts make the difference. They will show up on every other page in these docs, so read them once now and the rest fits together.

Workflow

A workflow is a function decorated with @workflow that orchestrates a sequence of steps. The body looks like ordinary async code: variables, branches, loops, exception handlers. AGNT5 treats the body as a recipe to be executed reliably, not a one-shot Python call.

When you triggered research, AGNT5 created a run — a single execution of the workflow with a unique ID. Re-running the same workflow with the same input produces a new run with a new ID; runs are not deduplicated.

Step

The work inside ctx.step(fetch_article, url=url) is a step — a unit of work the workflow delegates. A step is the place where side effects happen: HTTP calls, file I/O, LLM calls, database writes. Workflow code itself stays deterministic so AGNT5 can replay it; the unpredictable parts live inside steps.

The two steps you saw — fetch_article and summarize — are functions decorated with @function. The workflow calls them through ctx.step, which captures the input and the return value to the journal.

Checkpoint

When a step returns, AGNT5 writes the input and output to a journal. That record is a checkpoint. The next call to ctx.step does not run if a checkpoint already exists for that step in this run — it returns the recorded output instead.

This is what makes workflows resumable. If your worker crashed after fetch_article succeeded but before summarize ran, the retry would skip the HTTP call (cached) and run summarize against the cached article body. No duplicate fetches, no double LLM bills, no manual recovery code.

Trace

A run produces a trace: the ordered list of every step, with inputs, outputs, errors, timings, and (for LLM steps) prompts, responses, and token counts.

The trace is not a sidecar log. It is the system of record. agnt5 inspect runs describe and agnt5 inspect trace -r read directly from it. The eval loop reads from it too — any run can be replayed against new prompts or models because its inputs are still on disk.

Worker

A worker is the runtime process that hosts your registered components for AGNT5 to dispatch work to. agnt5 dev opens a session bound to a worker; agnt5 deploy runs workers on managed environments. The shape is identical — only the host of the session changes.

Multiple workers can serve the same project. If one disconnects mid-step, another picks up the run from the last checkpoint. Nothing about the runtime — the coordinator, journal, trace store — depends on the worker’s host.

Putting it together

The five concepts compose:

Run = a worker executing a workflow against an input,
      whose step outputs are checkpointed,
      and whose full history is the trace.

Every claim AGNT5 makes about durability, observability, and evaluation comes from this picture. Durability is the journal. Observability is the trace. Evaluation is replaying the trace with edits.

Next steps

• Where to go next — pick a direction based on what you want to build.
• CLI Reference — every command and flag.