r/agenticcoding

I made an evidence-gate workflow for coding agents — Codex + Claude Code support
▲ 3 r/agenticcoding+3 crossposts

I made an evidence-gate workflow for coding agents — Codex + Claude Code support

I’m the maker of Superloopy, an MIT-licensed workflow layer for coding agents.

The pattern I’m trying to make practical is an “evidence gate” before an agent claims a task is done:

  1. turn the task into explicit acceptance criteria

  2. ask the agent to leave receipts under `.superloopy/evidence/`

  3. use command-backed checks where possible, not just prose summaries

  4. keep manual/visual proof separate from deterministic proof

  5. finish with a report that says what passed, what still needs judgment, and where the artifacts are

It now works with both Codex and Claude Code. The implementation is intentionally thin: plugin hooks, skills/subagents, and a small CLI around evidence + final gates. The goal is not to create another agent, but to make existing coding agents easier to audit when they say “done.”

Repo:

https://github.com/beefiker/superloopy

I’m curious how other people building with coding agents structure this. Do you keep evidence artifacts? Do you require tests/screenshots/logs before accepting work? Or does that add too much ceremony for your workflow?

u/Simple_Somewhere7662 — 5 days ago
▲ 20 r/agenticcoding+5 crossposts

i built "flows": a custom markdown runtime for visualizing long-running agent loops

i've been running longer and longer agent workflows, and the hard part is no longer just writing the prompt.

it is orchestration, synchronization, and agent management: knowing what loop is running, what check failed, which agent needs attention, and how all the pieces fit together as one bigger system.

so i built `flows`.

-the basic idea is simple:
-agent blocks do fuzzy work.
-code blocks do deterministic checks.

the flow graph shows how all of them connect.

for example, you might have one agent loop trying to make JAX/GPU code faster. a Python block benchmarks the result. if the benchmark says `too_slow`, the code goes back into the optimizer agent. if it says `fast_enough`, the flow moves on to another loop, maybe memory optimization, then another check, then a final review agent.

the point is not just one agent plus one test. it is being able to run and inspect many agents, many checks, and many loops as one visible workflow.

goals are attached to individual agent blocks. code blocks decide whether a loop really passed.

the whole thing is written as markdown, so agents can read, edit, and operate on the workflow directly.

each `##` section becomes a block in the flow. YAML declares inputs, routing, loops, models, executors, max runs, and exhaustion behavior. normal markdown becomes the agent prompt. fenced Python/bash/etc blocks become deterministic runtime steps.

then the custom markdown runtime compiles that file into an executable graph.

there is also a local flowchart viewer for agent orchestration and live synchronization, so you can see the system as it runs: agents, code blocks, inputs, outputs, goal cards, loops, and live execution state.

i wanted something that felt closer to a notebook or org-mode file than a drag-and-drop builder, but still made long-running agent systems visible and debuggable.

github: https://github.com/samleeney/flows

u/chabuddy95 — 6 days ago