How the self-service pipeline runner works
Plenty of production pipelines are powerful and completely inaccessible to the person who needs them, because running one means asking an engineer. This wraps a real pipeline in an access-controlled web app so a non-technical operator can run it themselves, in plain language, with guardrails.
A look under the hood: how a plain-language front end drives a proven back-end worker, where it asks for approval, and the human checkpoint that keeps a non-technical operator from breaking anything live.
The short version
A production pipeline usually needs an engineer to run it. This puts that pipeline behind a simple, access-controlled web app so a non-technical operator can run it themselves. They open a page, say what they want in plain language ("process the new batch"), and the app finds the right source files in cloud storage, sanity-checks them, shows a summary, and launches the heavy work on the existing back-end worker. Progress streams live, and the operator only gets interrupted when a real decision needs their judgment, one click to approve.
That's the idea: the engineer builds the pipeline once, and the client operates it forever without needing the engineer again. The rest of this page is how it stays safe when a non-technical person is driving.
Plain-language in front, the real pipeline behind
The operator drives it two ways: a chat where they describe what they want, or manual step-by-step forms for the cases that need precision. Either way the app doesn't re-implement the pipeline, it's a thin control layer over the existing production worker that does the actual compute. The deterministic engine stays the source of truth; the app just gathers the inputs, launches runs, and reports back.
This split matters. The hard, correctness-critical work (the compute, the exact output format) lives in the proven worker and is never rewritten by the agent. The app's job is only to make that worker runnable by someone who isn't an engineer.
Gated where it counts, automatic where it's safe
Most reads and routine steps run automatically so the operator isn't clicking through busywork. The few actions that are outward-facing or expensive, launching a heavy run, changing storage permissions, are held for an explicit one-click approval. The operator sees a summary of exactly what's about to happen before it happens.
The system is built to be visibly working and never silently stuck: a live status indicator, long runs that continue server-side and notify when done, and a full audit log of every action. Nobody is left wondering whether it's running or hung.
A human checkpoint before anything goes live
The final output is produced as a file the operator reviews and imports themselves, not pushed live automatically. That single design choice means the worst case is a file caught at review, never a broken live product. The agent can work freely because the human import step is the safety net.
Access is controlled by an identity-aware proxy in front of the app, and every session and record is scoped to the verified user, so one operator can never see another's work. State is backed up on a schedule with a documented restore path.
This is a control layer, not the pipeline itself. It makes an existing production pipeline safely runnable by a non-technical person, with gated approvals for the risky steps and a human review before any output goes live. It's a pattern that fits any pipeline a client needs to run often but shouldn't need an engineer for.