Show HN: AgentRun: DSL to turn agents into workflows
AgentRun is a new TypeScript DSL and runtime for defining structured workflows that coordinate AI agents, tools, and typed decision engines.
summary is enough The announcement introduces a specialized workflow DSL, but the real value is in the HN debate on agent state management versus traditional engines like Temporal.
summary
AgentRun provides a TypeScript domain-specific language and interpreter to structure AI agent execution into repeatable steps, supporting parallel mapping and bounded loops. It splits tasks between deterministic typed decision checks using Jev and open-ended investigations handled by standard agents. A packaged Pi extension allows developers to scaffold and execute these workflows directly through conversational prompts. Commenters discuss alternative state architectures, such as isolated filesystem volumes, and question whether custom agent DSLs offer advantages over established durable workflow engines.
key points
- Defines workflow schemas using TypeScript and Zod contracts, supporting runtime state checks, parallel mapping, and loops.
- Integrates Jev for confidence-scored binary decisions, automatically routing failures to agent investigations or human review.
- Provides a Pi extension enabling developers to build and run workflows using natural language prompts.
who should read it
Software engineers building multi-agent systems who need to constrain non-deterministic loops with structured orchestration.
discussion positive
consensus
Commenters debate whether custom DSLs are necessary for agent orchestration compared to existing durable workflow engines like Temporal, noting that managing workflow business logic and state is the true bottleneck.
pushback
A minority view suggests that graph workflows are ineffective without explicit cost weights and reward states akin to Markov Decision Processes.
Only state I keep is filesystem and last message (but even that is persisted in the filesystem). Each agent gets its own btrfs volume, when it’s done the “next” agent get the previous agent work mounted in its own filesystem ( and told about it ). Agent is also able to “promote” files if it wants and they are mounted in a more prominent place.
I don’t know yet if it’s a good solution. But only thinking in terms of files / filesystem sure make things easier.
Also makes branching “easier”: no handling of merging or conflicts, the receiving agent just gets N file systems and decides how to …
It proposes a unique file-system-based state management strategy where each agent gets an isolated btrfs volume to sidestep complex merge conflicts.
Generated by an LLM from the article and thread. Check the sources before relying on it.