Kira doesn't write prompts. She writes flows, and here's why that matters

The first version of Kira was a chat interface. You typed, she responded. We shipped it to three customers and watched them use it for a week. Then we rebuilt it.

What we learned from the chat version

When you give someone a blank chat box and tell them to describe their document workflow, they describe the happy path. They tell you what the flow is supposed to do, not what it actually does when the documents are messy. The canvas — the visual workflow graph — surfaced the edge cases in a way that a conversation never did.

Why flows instead of prompts

Prompts are stateless. Every time you type a prompt, Kira has to reconstruct her understanding of your workflow from scratch. Canvases are stateful. Kira can look at your current canvas, understand what's there, identify what's missing, and propose a specific edit — not a description of an edit, but the actual node change, with a preview.

That preview is the key. When Kira proposes a canvas edit, you see the canvas with and without her change side by side. You approve it, reject it, or ask her to reshape it. There's no ambiguity about what she's proposing, and there's no implementation lag between approval and execution.

The design constraint

We made a deliberate choice early on: Kira proposes, humans decide. She never applies a canvas edit without showing you the preview and waiting for approval. This feels slower than an autonomous agent. In practice, it's faster — because the approval loop is ten seconds and the rollback is one click, so people are willing to try things they would never try if the edit required a ticket.