Railyard

Railyard is a production-grade orchestration platform — not a framework you wire together, a running system. The API server is Go on go-chi, the dashboard is React on Vite with Shadcn components, and state lives in PostgreSQL. You build workflows visually from the dashboard or programmatically through the API, and you monitor execution in real time either way. The distinction from other orchestrators: Railyard owns the full stack from workflow definition through agent execution to policy enforcement.

The workflow engine executes stages as a DAG. Each stage binds one or more agents to a reasoning module from DSPy-Go — chain of thought, react, multi-chain comparison, and three others. Conditional branching routes execution based on agent output. Parallel stages run concurrently with configurable concurrency limits. Human approval gates pause the pipeline until an authorized user signs off. When a stage fails, the behavior is declared up front: stop, skip, retry with backoff, or escalate to a human reviewer. No implicit defaults.

CLIPS-based governors enforce policy at the agent boundary. Every input passes through an inbound governor before the agent sees it; every output passes through an outbound governor before it leaves. Governors are priority-ordered, so a compliance rule always fires before a formatting rule. The key difference from middleware: governors maintain working memory across invocations within a session. They can detect patterns across an agent’s entire execution history — not just evaluate individual calls in isolation.

Real-time WebSocket connections stream execution state to the dashboard as workflows run. Concurrency limits prevent runaway agents from saturating resources — exceed the limit and you get a 429 until a slot opens. Structured trace logs capture every LLM call, tool invocation, and governor evaluation with timing data, so when something goes wrong you can reconstruct exactly what happened and in what order.