Skip to content

Workflow Templates

Workflow templates are pre-configured workflows in the MDK that demonstrate how multiple agents, tasks, and operators can be orchestrated together. They provide ready-to-use patterns for common problem types, so you can get started quickly without building from scratch.

What You'll Learn
  • How to use the Traffic Model Workflow Template
  • How to use the Agentic Planner Workflow Template
  • Configurable parameters for each workflow
  • Example use cases for workflow templates

Traffic Model Workflow Template

Traffic Model Workflow Template

The Traffic Model Workflow connects three models into a pipeline that builds a city road network, generates traffic schedules, and runs a full traffic simulation. This allows users to go from a city name input to a dynamic simulation of vehicles moving through intersections, complete with configurable driver and road behaviours.

The workflow begins with the City Graph Network Generation model, which creates a road network graph from OpenStreetMap (OSM) data. A location such as Melbourne (the default) is used to generate the structure of roads, intersections, and connections. This graph forms the foundation for all later steps and can also be used independently for urban planning or routing analysis.

Valid Place Names

Valid place names for graph networks are based on the OSM Nominatim API and can be cross-validated here: Melbourne City. Too large of a graph can cause graph initialisation issues, so city-sized graphs are recommended, rather than regional. If finding a valid place name is difficult, you can switch to use the Graph generation from bounding box or point and radius which allow you to specify latitudes and longitudes.

Next, the Schedules Generation model builds a time-based plan for vehicles. Using the graph as input, it assigns departure times, routes, priorities, and other parameters to each vehicle in the simulation. The number of vehicles is configurable, enabling scenarios ranging from light traffic to peak-hour congestion. The output is a detailed schema describing paths, velocities, intersection behaviours, and environmental attributes such as:

  • Traffic lights: whether intersections are signalised or uncontrolled
  • Critical nodes: intersections that govern flow across the network
  • Lane structures: number and arrangement of lanes per segment

The final stage is the Traffic Model Solver, which runs the simulation itself. It uses the graph and schedules to calculate how vehicles move through the city, resolving conflicts at intersections and adjusting behaviours in real time. The solver is driven by configurable parameters that define how realistic the simulation will be:

  • Intersection algorithm: how the model decides which vehicle passes first at a junction
  • Max acceleration / deceleration: physical limits that replicate how vehicles can speed up or slow down
  • Driver reaction time: the delay between an event (e.g. the car in front braking) and the driver's response
  • Safe following distance: how much space vehicles maintain to avoid collisions
  • Simulation time window (start_time, end_time, dt): how long the simulation runs and how finely time steps are calculated

The solver produces a GeoJSON Timeseries output, which records the positions of vehicles over time. This data can then be analysed to:

  • Measure congestion and delays
  • Estimate fuel use and emissions
  • Test how changes to road design, signals, or schedules affect performance

By chaining these models, the workflow provides a complete loop: input a city → generate its road graph → create vehicle schedules → simulate realistic traffic flow. With input and output dependencies set to a database, users can run repeatable experiments, compare scenarios, and store results for further decision-making.

Agentic Planner Workflow Template

The Agentic Planner Workflow is designed to coordinate multiple AI agents and operators to generate, execute, and refine structured plans. Instead of a single agent handling everything, the workflow connects specialised steps — planning, execution, information retrieval, summarisation, and feedback — into one continuous loop. The result is a plan that improves as it runs.

The workflow starts by defining constants such as the Run ID, Agent ID, and Prompt. These set the context: what problem is being solved, who (or what) is solving it, and how the outputs will be tracked across stages.

Once the context is set, the workflow moves into stage extraction and execution:

  • An operator extracts the stage key prefix from the plan
  • An LLM Tool Task is called to handle reasoning at that stage, while a Web Search Task retrieves relevant external information
  • Their outputs are merged, creating a richer picture that blends reasoning with real-world data

The workflow then applies a Summary Task, where an LLM agent condenses the results and checks their quality. If the task was incomplete or low quality, the Feedback Loop operator sends the summary back to the planning agent with the original prompt so the process can be refined and retried. This loop allows the workflow to self-correct instead of moving forward with weak results.

At the core is the Planning Agent, which generates a structured plan to solve the problem. The plan is broken into stages, and a Plan Select Task chooses the next stage to execute. By iterating through these stages, the workflow gradually builds towards the final solution.

The Planning Final Task produces a comprehensive report. Unlike the earlier summaries, this is a detailed, structured output in markdown that includes:

  • An executive summary of the original problem and outcome
  • Detailed findings from each task, presented with tables and lists
  • Key insights, anomalies, and observations
  • An appendix with raw data for reference

Configurable Elements

While much of the process is automated, some aspects can be configured depending on use case:

  • Prompt string: defines the problem to be solved
  • Feedback criteria: whether tasks should be retried if quality is low
  • Agent selection: different agents can be called at each stage depending on the domain (e.g. research, planning, analysis)

What the Workflow Enables

By chaining together planning, information retrieval, execution, and quality control, the workflow produces plans that are:

  • Structured: broken into clear stages with explicit outputs
  • Adaptive: able to loop back and refine if outputs aren't good enough
  • Comprehensive: the final report captures all stages, data, and insights in one place

Example Use Cases

  • Research projects: plan literature reviews, gather web data, and summarise findings in a structured report
  • Business strategy: generate step-by-step action plans with feedback on feasibility and quality
  • Process design: break down complex workflows into manageable stages and iterate until all gaps are covered

User documentation for Optimal Reality