Bronson

DAG Generator
Job Runner
Schedule

Inspiration

During my experience working with agents, I often found that agents worked fine during the initial steps but gradually worsened the deeper they went into the task. There was no visibility on where they went wrong, what tools they used, and how much they cost to run. I wanted to fix those issues all in one tool.

The prompt "build what agents want" inspired us to think differently. Agents don't need more memory or tools, and there's already so many people working on these problems. What I thought agents lacked was autonomy. That means running defined workflows with no hand-holding, no having to approve a new shell command every 10 seconds. Pausing for humans only when stakes are high, and settling their own invoices without having to worry about crazy high token costs, from a predefined budget

What it does

Bronson is workflow runtime, inspired by job schedulers like Control-M and Apache Airflow, in the mold of AI agents. You define your end-to-end workflow in a YAML file, readable by both humans and other meta-agents. Bronson saves context and outputs after each successful step ran, decreasing retry costs in tokens and makes running large jobs easier. Bronson also provides scheduling options for running jobs autonomously. Most importantly, you can set up human gates explicitly and Bronson will show you the current output and needs your approval to move forward.

name: Equity Research
steps:
  - id: search
    tool: web_search
    prompt: "Find recent news about {company}"
  - id: codebase_scan
    tool: greptile
    prompt: "Find any existing analysis on {company}"
    depends_on: search
  - id: approve
    type: human_gate
    message: "Review findings before generating memo"
  - id: memo
    tool: llm
    prompt: "Write a research memo based on prior steps"
    depends_on: [search, codebase_scan, approve]

Flowpay executes it step by step, streams every event to a live dashboard, and when the run completes — bills automatically via Allscale in USDT.

How we built it

Workflow engine : YAML parser with dependency resolution into a DAG and human gate support, emitting structured events over WebSocket
Agent layer : Clod with tool use (web search, Greptile codebase search, LLM calls), executing each workflow step
Dashboard :React frontend consuming live WebSocket events; trace waterfall, token cost per step, human approval UI
Scheduling : Schedule future jobs to run
Billing : Allscale Checkout integration with HMAC-SHA256 request signing; checkout intent created on run completion, status polled until on-chain confirmation ## Challenges we ran into Retry logic : One of the core features we wanted was being able to retry on failure. Implementing it cleanly was harder than expected, canceling an in-flight job while a new one spins up created race conditions that corrupted workflow state. We had to build explicit job lifecycle management with generation counters to ensure stale results from a canceled run couldn't overwrite a fresh one.

Accomplishments that we're proud of

Fully customisable workflow - A true platform as a service, that is capable to run any possible skill and tools, both on your local file system as well as being able to do web searches.
Human gates : mid-workflow pause-and-approve built into the runtime. They stop, wait for a human decision, and resume. This is the feature that makes Flowpay production-ready rather than a demo.
Live autonomous billing :Allscale stablecoin settlement triggered automatically on workflow completion. No invoicing, no manual reconciliation. The agent bills for its own work.

What we learned

Orchestration is genuinely hard : coordinating dependent steps, handling failures mid-pipeline, managing retries, and keeping state consistent across async execution is not a solved problem. Every edge case we fixed revealed another one. Building a reliable runtime from scratch in 12 hours gave us deep respect for what tools like Airflow and Temporal actually do.
Parallel model calls compound the complexity : spawning multiple Clod calls concurrently for independent steps sounds simple until you're managing partial failures, out-of-order completions, and results that need to merge before the next step can run. Getting this right without corrupting workflow state was the hardest engineering problem we faced.