Skip to main content

What we’re building

We will build a workflow that takes a name and returns a greeting. It has three steps: a trigger that receives the name, a mapper that builds the greeting, and a terminal that ends the path. It is small on purpose. A CI pipeline and a team of AI agents use the same loop, and we will meet both in the next tutorials. The workflow we build: an API trigger receives a name, a mapper builds a greeting, and a console terminal shows Hello, Ada. The workflow we build: an API trigger receives a name, a mapper builds a greeting, and a console terminal shows Hello, Ada. Figure 1: Notice that the message moves left to right, and that each box does one job.
We have not installed Yukta yet? Follow Install Yukta first and leave the server running. If your server needs an API key (a Docker server does), add -H "X-API-Key: <your key>" to every curl below.
1

Check the server is up

We confirm the server answers before we send it anything.
You should see:
Stuck? Connection refused means the server is not running. Start it with yukta in another terminal, or see Install Yukta.
2

Save the workflow

A session is a folder of workflows. We save ours in a session called demo. Create a file named session.json:
session.json
Each box in the picture is a node, with a type that says what it does. Each arrow is an edge. The mapper’s mapping builds a new message from the old one: payload.name is the name we will send in, and the text in single quotes is a literal. Now send it to the server:
You should see:
Stuck? A 400 names the field it did not accept, for example workflows.greet.nodes[1]. Compare that node with the file above.
3

Start a run

A run is one execution of a workflow. We start one and hand it a name:
The server answers 202 Accepted at once and keeps running the workflow in the background. You should see an execution id, which is your ticket number for this run:
Keep it in a variable, using your own id:
4

Read the status of every step

We ask the server how the run went:
You should see the run SUCCESS and one entry per node, each with its own status (shortened here):
Stuck? 404 right after the start can mean the run is not registered yet. Wait a second and ask again. A status of RUNNING means it is still going: ask again.
5

Read the result

The terminal node is where a run ends. What reaches it is the run’s result:
You should see the greeting in the first event (shortened):
The log shows what each node saw and sent on. The nodes log in no fixed order, so read it by node name:
The stream closes by itself when the run has ended.
6

Run it again with another name

The workflow is saved, so we do not repeat step 2. We start a second run:
You should see a new execution id:
Then read its status with the id you got. The client prints a small table:
Stuck? yukta-cli talks to http://localhost:9858 unless you set YUKTA_SERVER_URL. With an API key, set YUKTA_TOKEN as well.
7

See the same run in the web UI

Open http://localhost:9858/ and pick the demo session. Each run shows the graph with the status of every node.
Sessions are kept in memory. If you stop the server, apply session.json again after you start it.

What you just did

We wrote a workflow down once, as JSON. We sent it to the server, which ran every step for us, and we read the status of each step and the result. A person, a script or an AI assistant can start the same definition and gets the same steps in the same order. On a longer run you can also pause, stop or retry it while it runs.

Where to go next

Mix rules and AI

Next tutorial: put a rule and an AI step in one workflow, with a fallback that works offline.

Let an assistant build it

Connect Claude Code and let it build and run a workflow for you.

How Yukta works

Why a workflow is a graph of nodes, edges and messages.

Define a workflow

Write your own workflow JSON for a real job.