Context & constraints
The reusable part was the processing engine.
Our pilots took an initial client brief and ran it through a sequence of AI requests. Depending on the project, the output could include interest-funnel calculations, analysis by geography or audience category, recommendations for advertising or events, charts, and structured results.
Most of the work lived in the backend. A simple client interface collected the initial information, but the required reasoning steps, validation rules, and output formats changed from one pilot to the next. Client-owned interfaces could not simply be reused.
At the same time, a model could return an unexpected format, a refusal, or an answer outside the scenario’s expected range. A workflow needed to make decisions about the result of each request before continuing.
Separate reusable execution operations from client-specific prompts and scenarios. Keep the control flow in one engine, while allowing each pilot to define its own processing logic.
Engine & workflow design
Compose the scenario from operations.
I designed the Node.js-based DSL and implemented the complete JumpStart core. The language exposed operations for requests, intermediate analysis, validation, branching, parallel execution, formatting, and final output.
A dedicated prompt engineer used a command reference to write scenarios. I supported this work across all stages. Scenarios could be edited through the interface, making it possible to change a prompt or processing branch and check the concept without redeployment.
- Receive and analyze the input.Collect the client’s context and obtain the initial model responses.
- Clean, format, and validate.Check the response in the context of the request, including expected value ranges and output structure.
- Branch into more specific questions.Run category-specific requests in parallel and wait for the required branches to finish.
- Check the branch results.Validate individual answers and format them for the next processing stage.
- Assemble the result.Summarize the information, build the requested charts, and produce the final JSON response.
This is a conceptual example of the confirmed workflow, rather than a reproduction of the exact DSL syntax.
- Node.js
- AWS Lambda
- Database-backed state
- OpenAI
- Anthropic
- AWS Bedrock
Handling uncertain output
Validate each result.
Recover at the request level.
Cross-model validation was a required step: another model checked whether the answer made sense for the request. A second barrier checked the expected formatting. Together, these checks filtered many unsuitable responses, while still requiring explicit failure handling.
| Constraint | Response |
|---|---|
| A model returned an unsuitable answer | Retry the same request, change the model parameters, or ask another model. |
| Only some parallel requests failed | Keep completed results and rerun the failed requests using their stored states. |
| A branch was difficult to debug | Inspect the saved execution tree and the state of each request. |
| Processing hit an external limit | Delay a bounded retry and notify the client about the process status by email. |
One request, checked at every step.
The saved request tree supported both recovery and investigation. We could inspect where a workflow went wrong instead of treating the entire scenario as one opaque operation. Completed work stayed available when an individual request had to run again.
Ownership & outcome
From repeated implementation
to scenario authoring.
Typical delivery time for a working client pilot. This is an approximate delivery comparison across the four pilots.
I led a six-person team and worked across requirements, architecture, core implementation, and integration. The outcome was a working solution handed over to the end client.
The main improvement was in how new logic was created. Rather than implementing and debugging the same control-flow operations for every pilot, we wrote prompts and scenarios for validation, branching, and formatting. This shortened concept validation and reduced repeated development work.
Validation and fallback made failures manageable; they did not guarantee that every model response was correct. The delivery comparison concerns pilot handover, not an inference-latency or uptime benchmark.