arizuko › concepts › workflows

workflows

An arizuko agent chats well and fails at anything multi-step. It improvises every turn from the scrollback, never writes a plan down, forgets to read its own skills, and starts each session cold. A workflow is the fix — not a new engine, just one rule: keep the conversation free, but make the opening strict.

Why multi-step jobs thrash

Watch a travel-concierge agent plan a week-long trip over chat and the pattern is always the same:

• The plan lives in the transcript. There’s no single file holding the itinerary, so every turn re-derives it from scrollback. The same stop gets added, questioned, removed, and re-added across an hour. There’s nothing to converge on.
• Nothing forces an opening. The agent could run its triage step, but it’s a soft nudge the model skips at will. A plain “hello” can sit unanswered while the agent jumps straight into free-association.
• Context isn’t loaded at decision time. The agent claims “I don’t have the history” mid-session even though the context is right there — because nothing makes it load memory and facts/ before acting.
• It doesn’t consult its own skills. A rule already written in a skill gets re-taught live, four times, because nothing makes the agent read its skills at the start of the job.

None of these are capability gaps — the memory, the skills, the plan file are all available. What’s missing is a gate that runs a fixed opening before the agent is allowed to free-associate.

Free chat, strict opening

The discipline lives at the edges of a session, not in the middle. Think of a waiter who knows you and chats happily — but every time you sit down he still runs the same script: greet, recall your table, take the order, read it back, then act.

Inside a session, conversation is the default. The strictness is only at the seams — sitting down, and starting a new thread.

The plan-of-record

The one durable artifact that fixes the thrash is a plain file. Any multi-step job gets one ~/plans/<topic>.md, written first and edited in place. The opening reads it; the work updates it; “done” means the plan file is updated, not a chat closer. It’s a markdown file the agent owns — no schema, no database row, diffable like everything else (agent-as-data).

Write the opening in CLAUDE.md

What the opening says is yours to author. Each group has a CLAUDE.md — its operating manual — and a ## Session opening section there is the contract. Keep it short and concrete:

## Session opening

Before replying to anything multi-step:
1. Load context — read MEMORY.md, the relevant facts/, and the diary.
2. Open the plan — read ~/plans/<topic>.md, or create it if missing.
3. Scan skills/ for one that fits the job, and apply its rules.
4. Confirm the goal and name the deliverable, then act.

"Done" means the plan file is updated — not a message that says done.

Two more things make the opening worth running: keep the persona coherent (one identity, a focused facts/ — an agent carrying three personas has nothing clean to load), and treat the plan file as the source of truth for the whole job.

Not a new primitive

A workflow isn’t a seventh part of the system. It’s Turn + State and the session lifecycle recombined: the session boundary already starts each run fresh; the discipline just makes that boundary run a fixed opening and keep a plan file. No state machine, no DAG runtime — the backbone is the session lifecycle arizuko already runs, and the intelligence is the agent.