An agentic workflow example you can copy shows three things: the row that starts the run, the prompt the row fires, and the lines the run hands back. Kortix is the open-source AI Operating System, and daily-digest is a real row from kortix.yaml, beside the agents and the sandbox images.
# the branch is named after the session$ git branch --show-current9f4c2b7e-1d83-4a6f-b0c2-5e71a9d4c188$ git commit -am "add the q3 revenue report"$ kortix cr→ change request opened toward mainA run's edits and commits live on the session's branch, and kortix cr opens the change request toward main.
Every card is a row from kortix.yaml, with the agent it runs as and the session each fire lands in.
The kortix agent starts clean at 09:00 on weekdays, and the prompt on the row asks it to summarize yesterday's commits and open a change request against main.
The summary reaches main as a change request a person merges.
On the first of the month at 06:30 Berlin time, reuse re-prompts the most recent healthy session this trigger created, so the sweep picks up a thread that already carries last month's context.
The exceptions sit on the session branch, so the month closes on a reviewed diff.
The support agent gets a new machine and an empty context every Friday in UTC, which turns the handoff into a written record for two people who overlap for ten minutes on a good Friday.
A triggered session is visible to the whole project, not private to whoever configured the trigger.
pinned names one exact session by id and re-prompts it, so the planner agent picks the roadmap thread back up at 08:00 New York time with the context already in it.
A fire that goes quiet stops itself after 5 minutes idle, and its branch keeps the work.
Pattern catalogues name reflection, tool use and planner-executor loops, and they are good at that. What they leave out is the part that decides whether a workflow holds up in a building with other people in it. An example you can copy carries three visible parts: the row that starts the run, the prompt that row fires, and the lines the run hands back when it is done. The definition covers the loop itself; each of the four runs keeps to those three parts.
A row, a prompt and the lines a session prints are small enough to read in one screen, and specific enough to argue with. If one of the three is missing, the example is a mood board.
The daily-digest row is the whole example, as it sits in kortix.yaml:
triggers:
- slug: daily-digest
type: cron
agent: kortix
cron: "0 0 9 * * 1-5"
timezone: America/Los_Angeles
session_mode: fresh
prompt: |
Summarize yesterday's commits. Open a change request against main.Nine lines, each field with a job. The slug is the name typed at the command line. type: cron is one of the two trigger types. agent: kortix names the agent the fire starts. The cron expression carries six fields and the timezone is an IANA name. session_mode: fresh says this fire gets a clean session rather than an earlier one. The block under prompt: carries the work: what to read, what to write, and where the result goes.
In Kortix, triggers live in kortix.yaml next to your agents and sandbox images. The cron expression, the timezone, the agent slug and the prompt sit within a few lines of each other. A reader can copy the shape without opening a dashboard.
That proximity is the difference between an example and a screenshot. Text in git can be diffed, forked and reviewed. It also survives the person who set it up. The row is still there after they change teams, and the comment above it still says what it was for.
A triggered session does not run in a chat window. It does not run on the laptop of whoever configured the trigger. A Linux machine boots from the sandbox image your project declares, and the project repo is cloned into /workspace before the agent reads its prompt. A run never inherits another run's half-finished install, because the machine that held it is gone.
One isolated sandbox per session. Each session has its own isolated machine and branch. A run that installs the wrong dependency or deletes a directory costs nothing outside its own machine. The session's branch holds every edit, commit and stray file it produces, and the machine takes the rest with it when the run ends.
The part a catalogue cannot show is where the work goes. Session work reaches main through a change request. Merge is default-deny for agents, so a run that only answers, or stops on a question, leaves nothing to merge.
A finished session prints three things: the branch, named after the session; the one commit that survives the machine; and kortix cr reporting the change request it opened. A transcript asks the reader to trust the run. A branch asks them to read it. The change request carries the changed lines against a base, with a place for a comment, which is what a colleague's work already looks like.
A trigger has exactly two types: cron and webhook. Cron takes a 6-field expression, second through weekday, in any IANA timezone, or a single run_at timestamp for something that should happen once and then stay quiet. Webhook fires when an external service POSTs to the trigger URL. Every webhook trigger names a project secret that signs it. A trigger without one is rejected at validation, which removes the unauthenticated endpoint someone would otherwise forget to close. Three commands add a trigger, ship the config and start a run by hand:
$ kortix triggers add daily-digest --type cron \
--cron "0 0 9 * * 1-5" \
--timezone America/Los_Angeles \
--prompt "Summarize yesterday. Open a CR."
$ kortix ship
→ kortix.yaml pushed. daily-digest is scheduled.
$ kortix triggers ls
$ kortix triggers fire daily-digest
→ session startedkortix triggers fire exists so nobody waits until Monday morning to find out whether the prompt renders. Firing it by hand starts the same session the clock would have started, on the same kind of machine.
The one field worth thinking about before copying a row is session_mode. A trigger has four session modes: fresh, reuse, pinned, keyed, and the default is fresh. A digest and a shift handoff want a clean slate, so both use fresh. A monthly sweep wants the thread it already owns, which is reuse. A roadmap review wants one exact session named by id, which is pinned. A per-customer conversation wants keyed: the payload renders a key, and the fire lands on the most recent healthy session stamped with it. A fire that cannot reach its pinned session falls to keyed, then to reuse, then to a fresh session, so a fire never disappears.
Copied rows go wrong in small, predictable places. The slug, the cron, the timezone, the agent name and the prompt are the fields that carry the work, and each one has a failure that shows up in the first week.
The slug is the name you type at the command line, so it should say what the run does. The cron expression and the timezone travel together: 0 0 9 * * 1-5 fires at 09:00 in whatever zone the row names, and a row copied from a colleague abroad keeps their clock until you change it. The agent name has to exist under agents: in the same file, because the fire starts that agent and no other. The prompt is the field where a small edit pays for itself, since it becomes the session's first message.
session_mode is the field people leave alone, and the one worth a second look when the copy changes job. A digest copied into an invoice sweep should change mode along with the prompt.
Cost is the last question and the row answers it: a triggered session stops itself after 5 minutes idle, so an automation at 03:00 does not bill until the office opens. An automation also gets no privileges a person would not get, which keeps what a copied row can reach short.
The shortest path is to copy one row, change the slug and the cron, and leave the rest. Build your own walks a weekday digest from that first row to the merged change request. It covers the session mode and the prompt template. Run it on Kortix Cloud, in your VPC, or on your own on-prem network. Self-host is free.
A weekday digest, a monthly invoice sweep, a Friday on-call handoff and a Monday roadmap review. Each is a trigger row in kortix.yaml, and the work each one commits reaches main as a change request a person reads.
A cron job runs commands written in advance. An agentic workflow can start on the same clock, then hands the goal to an agent that chooses the steps, so a day the script never anticipated still has a way forward.
Yes. A trigger starts the session with nobody at the keyboard. The work reaches main through a change request, and merge is default-deny for agents unless an admin granted the merge capability.
With a cron schedule in an IANA timezone, or a signed webhook an external service POSTs to. Both are rows in kortix.yaml, and kortix triggers fire <slug> starts one by hand.
One kortix.yaml holds the agent, the trigger and the prompt, and what the run commits waits for a person to merge.