Inspiration
I ship small iOS apps, and every launch needs the same marketing work: a landing page, framed App Store screenshots, store copy, legal pages. Codex handles it well, but as a conversation. The plan is improvised inside the chat, so when the chat ends, the process is gone. My next app meant having the same hour-long conversation again. So i had to think about any way to stop rebuilding the process inside every conversation, and store it as a graph instead looked much more efficient.
What it does
Gitmoot Pipelines lets you save an agent workflow as a yaml file in your repo and run it again.
Each stage has one job and can call Codex, a shell command, or another tool. Some stages think,
some don't, and you choose which, per stage. A needs field defines the order, and independent
stages run at the same time. Pipelines can trigger other pipelines (ours chains a Telegram
delivery), and a pipeline can be exposed as a typed, token-protected API so other people (or
agents) can order runs. Every run ends with a content-addressed receipt where each claim is
graded, so you can trust work done by someone else's machine.
How we built it
The pipeline service layer was built by Codex with gpt-5.6-sol, coordinated through gitmoot
itself, and we can prove it: gitmoot mints receipts for its own implementation jobs
(Codex session 019f6e86-fdf2-78f1-8f6a-7c5e0f948340, proof sha256:78b3ab08...). The core
is Go, one static binary, no runtime dependencies, state in SQLite. The demo pipeline
(appkit-pro) reads a real app repo, derives the app identity with citations, builds the app
and captures real screenshots, has a Codex agent write the store copy in parallel with the
build, then composes framed shots, a landing page, and a launch kit delivered to Telegram.
The numbers (measured, not estimated)
We ran the same mission twice on the same app with the same model (Codex, gpt-5.6-terra): once as a plain conversation, once through the pipeline.
| Metric | Conversation (loop) | Gitmoot pipeline (graph) |
|---|---|---|
| Tokens spent | 18,814,978 | 4,231,476 |
| Prompts used | 4, but more iterations are required | 1 |
| Time used | 54m41s active, two sittings | 15m07s |
| Tasks completed | 2/3, after corrections, not ready | 3/3 |
Source: Codex session logs, gitmoot per-job token records, pipeline run timestamps. The point is not that the graph thinks better. It needs less help to complete the same job.
Challenges we ran into
- Real parallelism: pipeline shell stages share the repo checkout and serialize on its lock. We made the copy stage a real agent stage, which gets its own isolated worktree, so the two branches genuinely run side by side (measured 90+ seconds of overlap from job events).
- Honest measurement: stage timestamps are batch-stamped by the scheduler and can fake concurrency. We re-measured everything from job events, the source of truth, and filed the engine issue.
- Honest demos: we stripped the app's existing landing site from the demo repo so the conversation side could not copy it, and time-stamped both recordings.
- Agent patience: without a playbook, Codex misread normal scheduling gaps as a stall and started improvising. A short AGENTS.md in the repo fixed the behavior.
Accomplishments we're proud of
Everything in the demo is live on a public dashboard, not staged: the pipeline, the parallel fork, the chained Telegram delivery, and a public receipt page for served runs. The service API is deny-by-default: only typed-input, no-secret, no-network stages can be exposed at all.
What we learned
A loop improvises the plan every time; a graph is a plan you keep. And agents can use graphs too: in our demo, Codex calls the pipeline directly.
What's next
Sharing is already built in (publish and pull pipelines through GitHub). Next is the marketplace step: caller-granted credentials and billing hooks, so you can build a pipeline once and rent it out.
Log in or sign up for Devpost to join the conversation.