AI workflow orchestration
A new pilot should need
a new scenario.
Each client needed a different chain of AI requests, checks, and outputs. I designed a Node.js DSL and built the complete JumpStart core so these workflows could be assembled from reusable operations.
The constraint
Model responses were unpredictable. Client logic varied, and each interface belonged to its client. Reusing a previous pilot was rarely practical.
The decision
Move branching, parallel requests, validation, and formatting into an execution engine. Let a prompt engineer edit scenarios through the interface without a redeploy.
One request, checked at every step.
Typical delivery time for a working client pilot. Reusable orchestration reduced repeated implementation and debugging across four pilots. Timing is approximate.
More about the architecture and my role
I led a six-person team and worked across requirements, architecture, implementation, and integration. I designed the DSL and implemented the full JumpStart core underpinning GlenFlow Engine.
The engine used cross-model response validation and output-format checks. When a request failed, the scenario could retry, adjust model parameters, or use another model. Bounded, delayed retries and email status updates helped keep clients informed when processing could not finish immediately.
A dedicated prompt engineer wrote scenarios using the engine’s command reference, with my support throughout. The core handled branching, parallel work, intermediate checks, formatting, and JSON output; scenario changes no longer required writing and debugging that control flow again.
- Node.js
- AWS Lambda
- OpenAI
- Anthropic
- AWS Bedrock