Why we chose plain English over workflow builders

Every procedure platform starts the same way. You open a canvas, drag a trigger onto it, connect it to an action, add a condition, branch into two paths, add more actions, realize you need a loop, restructure the whole thing, and end up with a diagram that looks like a subway map. Then your refund policy changes and you have to untangle the diagram to figure out which branch handles the edge case. We took a different approach. DeepMerge procedures are written in plain English. ## What an procedure looks like ``` When a payment fails, retrieve the payment details from Stripe. Classify the decline code: soft declines (insufficient funds, processing errors) are eligible for retry. Hard declines (expired card, stolen card) are not. For soft declines: retry the payment. If it fails again after 3 days, send a recovery email. For hard declines: send an email immediately. If the customer is VIP (6+ months tenure or $500+ lifetime spend), create a support ticket for personal outreach. ``` No boxes, no arrows, no conditional nodes. The AI agent reads these instructions and executes them — calling Stripe, checking customer data, making decisions, sending emails, creating tickets. ## Why this works better **Conditions are natural.** "If the customer is VIP (6+ months tenure or $500+ lifetime spend)" is one sentence. In a visual builder, that's a condition node with two sub-conditions joined by OR, each pulling from a different data source. **Changes are edits.** When your refund threshold changes from $50 to $75, you change a number in a sentence. In a visual builder, you hunt for the right condition node, open its config, update the field, save, test. **Edge cases are paragraphs.** Real operations have exceptions. VIP customers get different treatment. Repeat returners get flagged. Each exception adds a branch in a visual builder — and branches multiply. In plain English, you add a paragraph. **Anyone can read it.** Your ops manager can read the procedure and understand exactly what will happen. No flowchart decoding. No clicking into nodes. The instructions are the documentation. **The AI handles ambiguity.** "If the customer seems like a high-risk returner" is a judgment call that a visual builder can't represent. A condition node needs a binary rule. The AI agent weighs multiple signals — return frequency, order value, account age — and makes a nuanced decision. ## The tradeoff Visual builders show you the execution path before it runs. You can trace the diagram and predict exactly what will happen. That predictability is valuable for compliance-heavy processes. Plain English procedures are less visually traceable. The execution log shows exactly what happened after the fact — every tool call, every decision — but you don't get a pre-execution flowchart. We compensate with the safety classifier (every action checked before execution), the approval system (human review for high-stakes decisions), and the full execution log. But if your process requires a visual diagram for regulatory approval, a traditional workflow builder may be the right tool for that specific process. For everything else — the 90% of operations work that's about making good decisions quickly across multiple systems — plain English is faster to write, easier to maintain, and handles complexity that diagrams can't represent.