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.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.Check the server is up
We confirm the server answers before we send it anything.You should see:
Stuck?Connection refusedmeans the server is not running. Start it withyuktain another terminal, or see Install Yukta.
Save the workflow
A session is a folder of workflows. We save ours in a session called Each box in the picture is a node, with a You should see:
demo. Create a file named session.json:session.json
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:Stuck? A400names the field it did not accept, for exampleworkflows.greet.nodes[1]. Compare that node with the file above.
Start a run
A run is one execution of a workflow. We start one and hand it a name:The server answers Keep it in a variable, using your own id:
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: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?404right after the start can mean the run is not registered yet. Wait a second and ask again. A status ofRUNNINGmeans it is still going: ask again.
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.
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-clitalks tohttp://localhost:9858unless you setYUKTA_SERVER_URL. With an API key, setYUKTA_TOKENas well.
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.