Problem
Unbounded loops are easy to describe and hard to trust.
The model can produce text forever. That does not mean the workflow should. I wanted a layer that decides when a task advances, stops, or gets kicked to review.
Execution proof
This orchestrator exists to stop agent theatre.
deterministic-agent-orchestrator turns vague “agent” claims into bounded steps, approval pause, retries, and a dead-letter path. The system is only useful if a human can still inspect the state.
Why it exists
Multi-step AI work gets brittle fast. Small failures compound when there is no contract, no budget, and no visible stop point.
System response
Contract-first execution.
Workflow state, approval requirements, retry limits, and blocked responses are first-class parts of the engine, not comments in a README.
Architecture block
The useful shape is bounded workflow in front of the model, not the model in charge of the workflow.
Workflow contract
Tasks begin with explicit state and expectations.
Engine gate
Approval rules, retry logic, and execution budgets are enforced here.
Fortress-backed worker
Model calls stay behind the gateway instead of running direct.
Audit or dead-letter
Every path ends in visible state, not silent failure.
Concrete artifacts
The engine matters because it leaves behind something you can actually reason about.
{
"task_id": "demo-021",
"state": "AWAITING_APPROVAL",
"requires_approval": true,
"attempt": 1,
"worker": "fortress_generate"
}
{
"task_id": "demo-022",
"state": "DEAD_LETTER",
"reason": "Fortress policy block",
"next_action": "operator review"
}
Next surface
The vault shows the control model. The arena shows the workflow breathing.
Open the demo page if you want the visual lane, example artifacts, and the more tactile side of the execution path.