By skyforbes I’m testing a different approach: treat the LLM as a compiler that emits a typed contract, and treat the runtime as a deterministic interpreter of that contract. This gives us something ML desperately needs: reproducibility and replayability for agent behavior.
Here’s the architecture I’m validating with the MVP:
Reducers don’t coordinate workflows — orchestrators do
I’ve separated the two concerns entirely:
Reducers:
- Use finite state machines embedded in contracts
- Manage deterministic state transitions
- Can trigger effects when transitions fire
- Enable replay and auditability
Orchestrators:
- Coordinate workflows
- Handle branching, sequencing, fan-out, retries
- Never directly touch state
LLMs as Compilers, not CPUs
Instead of letting an LLM “wing it” inside a long-running loop, the LLM generates a contract.
Because contracts are typed (Pydantic/JSON/YAML-schema backed), the validation loop forces the LLM to converge on a correct structure.
Once the contract is valid, the runtime executes it deterministically. No hallucinated control flow. No implicit state.
eployment = Publish a Contract
Nodes are declarative. The runtime subscribes to an event bus. If you publish a valid contract:
- The runtime materializes the node
- No rebuilds
- No dependency hell
- No long-running agent loops
Why do this?
Most “agent frameworks” today are just hand-written orchestrators glued to a chat model. They batch fail in the same way: nondeterministic logic hidden behind async glue.
A contract-driven runtime with FSM reducers and explicit orchestrators fixes that.
I’m especially interested in ML-focused critique:
- oes a deterministic contract layer actually solve the reproducibility problem for agent pipelines?
- Is this a useful abstraction for building benchmarkable systems?
- What failure modes am I not accounting for?
Happy to provide architectural diagrams or the draft ONEX protocol if useful for discussion.