Workflow automation platform that generates and debugs automations from plain language
Build a miniature workflow-automation platform inside 3B — a single-page app where someone describes an automation in plain language, an AI designs it as an ordered list of steps, and they can run it and watch every step's status, input, output, and logs. The point is to close the gap between "I have an idea for an automation" and "something is running," and to make debugging a matter of reading what each step actually received rather than guessing. Triggers are all HTTP routes under a shared path prefix (e.g. /squared), all authenticated to the space: A webpage route serving the builder UI — one React page with a prompt box, the generated step list, and a run-history panel that polls for live status every couple of seconds. An API route that takes a plain-language prompt and calls Claude via the Anthropic connector — or whichever model provider you prefer — with a schema-constrained system prompt, returning a linear workflow of steps. Support a few step types: code, AI, and HTTP request. An API route for listing and fetching saved workflows, and one for creating/updating/deleting them. An API route that starts a run, feeding an execution step that actually runs the workflow. An API route for run history and single-run detail. Persist workflows and runs as JSON in a named volume. Writers mount it exclusively; the read-only list endpoints mount it :ro. The execution engine should run steps in order, threading a context forward so later steps can reference the run input and earlier steps' outputs through simple {{...}} templating. Give each step a timeout and one automatic retry with backoff, and record per-step input, output, logs, attempt count, and timing so the UI can show exactly where a run broke. Code steps get the run input on stdin. Because the run route accepts a space API key as well as a browser session, a generated workflow can also be triggered by machine. Keep credentials out of code entirely — the model provider's key is injected by the connector proxy. Seed a small demo workflow on first load (something like: clean up some input text, then summarize it with the model) so the page is never empty. Add a test step that exercises templating, code execution, retry behavior, forward data passing between steps, and asserts that no real API key ever appears in step code. Tools used: React, TypeScript, Anthropic, 3B
What this prompt builds
A meta-automation platform built inside 3B that generates workflows from natural language descriptions and executes them with full transparency. Users describe an automation, Claude designs a schema-constrained workflow of code/AI/HTTP steps, and the system runs it while recording every step's input, output, logs, and timing. The execution engine uses templating to thread context between steps, handles retries automatically, and exposes both a UI and an API for triggering runs.
The problem
Building automations still requires someone who knows the platform — deciding what the steps are, wiring them together, placing credentials, and then debugging by guessing what data flowed where when something breaks. People who want automations but aren't builders wait in a queue for someone else's time. Builders spend that time on scaffolding they've written dozens of times before, then tracing data through steps that don't show their work. This workflow closes the gap: you describe an automation in plain language, Claude returns a working schema-constrained workflow of code/AI/HTTP steps, and you run it immediately. The execution engine threads context forward between steps with templating, gives each step a timeout and automatic retry, and records every step's input, output, logs, and attempt count to a volume. Because every execution stores what each step received and emitted, debugging becomes reading instead of guessing — the question "which step broke and on what data" is answered on the page.
Solution and impact
Non-builders get a first draft they can run and iterate on themselves without waiting for a builder's time. Builders skip the scaffolding and spend their time on the parts that are actually specific to the problem. The run-history panel polls every two seconds so you watch execution happen rather than reading a log afterwards, and because anything runnable in the UI is also runnable by machine via POST /squared/run with a space API key, generated workflows can be triggered from outside without being rebuilt. Credentials never appear in code — the Anthropic connector's key is injected by the proxy — and the execution model (containers per step, stdin/stdout data flow, volumes, connector auth injection) is reimplemented using the same primitives it demonstrates.