AgentRun - DSL to turn agents into inspectable workflows
Show HN: AgentRun: DSL to turn agents into Workflows
AgentRun is a workflow language for the agents you already run. Define repeatable steps, use Jev for focused decisions, and call an agent only when work needs investigation. Your application keeps its tools, model access, permissions, and budgets. Write workflows as JSON or with a TypeScript builder and Zod contracts, then connect tools, agents, and Jev decisions through simple adapters. Install @parcha/agentrun-dsl@beta and run the scripted ticket-routing demo with no API key. Workflows can call other workflows, map work in parallel, and run bounded loops. A Pi extension lets you build, inspect, and run workflows directly from your coding agent.
AgentRun stores the steps in a workflow document that you can inspect, rerun, or call from an agent.
- speckzzz
Graph workflows are useless if there are edges without cost or effor attribues and termination states without reward. Such workflow can be vibecoded in one-shot anyone who knows about graphs.
I thought some time ago about expressing SDLC as combination of harness tools, finite state machines with weights (efforts) on edges and rewards on some states. The goal - model queue of tasks as sub-workflows and implement the most valuable. I tried to design approach which will allow to maximize reward with minimal costs and risks via Markov Decision Process. Hypotetically i can implement it. But it all ends up being really hard to wrap your head around because of the state machines, custom runtime for scripts, the agent loop control, supervisor's control mechanisms. Then you have to tune the weighting models. The model can be similar to models from reinforcement learing. Even if I pull it off, I'd have to be damn lucky for even one other person to figure it out. And the project will have from 3 to 5 stars on GitHub because almost nobody will understand what is it and how to use.
- JustFinishedBSG
I'll study it as I am toying with "what should a workflow definition language look like".
My current vision, and prototype, is that it should be as close as possible to a "real" language as possible so that both the user and the agent know immediately how to use it and how it functions.
So for `pi` it means using typescript.
Then the UI is derived from the AST / code as much as possible and for things that aren't neatly possible like that I eventually add small semantic helpers that define the UI.
For example "plan -> execute" is:
await flow.unroll(
remaining.map(point => ({
key: point.id,
label: point.objective,
})),
async () => {
for (const point of remaining) {
await flow.item(point.id, async () =>
await flow.agent(executePoint, {
title: `Point ${point.id}`,
prompt: point.objective,
}));
}
},
{ title: `Plan r${planRevision}` },
);
( simplified code )
in my implementation and `unroll` is only there to have a nice
● Plan r1 · 1/3 · active
1. Inspect parser behavior
● 2. Add empty-input coverage
○ 3. Run focused checks
UI instead of a plain "Plan · 1/3" UI with no detail (which would happen if I just used a for loop, yes it works)
- JonathanAgosto
¡Wepa Miguel! ¡Felicidades y mucho éxito con el release!
Congratulations, and wishing you the best with this release!