Use case: Mainframe

Where Flow proved the pattern

Mainframe engineers work across ISPF, terminals, spool viewers, and job schedulers. Flow's first use case collapsed that into one canvas with local AI at every interpretation point.

Journey map

Submit-and-interpret, with and without Flow

Without

  1. Open ISPF, navigate to the JCL.
  2. Submit the JCL manually.
  3. Check the job queue periodically.
  4. Open the spool viewer.
  5. Copy results to email for QA.
  6. If failed, re-edit or ask a senior dev.

With Flow

  1. Drag nodes onto the canvas (or generate from a prompt).
  2. AI Syntax Validator checks the JCL locally, with zero network.
  3. The engine submits the job with an authenticated profile.
  4. Download Spool retrieves output. The Spool Interpreter annotates it in plain language.
  5. Failure recovery suggests a fix and can re-run on approval.
  6. An email notification with the AI-generated summary goes to QA.

All AI inference happens on the engineer's machine. No data leaves the laptop.

The execution graph

Five steps, two of them thinking

The flow submits the job through the authenticated CLI, validates the syntax with a local model, downloads the spool, interprets it with a second local model, and sends the summary. When a step fails, the engine passes the failure context back to the models for diagnosis. The retry state lives in the orchestrator, never in the model.

Spool from a failed job can also seed flow generation. You feed the spool to the generator and get a proposed recovery flow to review.

Spool-driven generation
jcl-pipeline.flow
flow "JCL Pipeline"
submit[action: "Submit JCL"] {
  command: "zowe jobs submit local-file"
  retry: 2
  timeout: 30s
}
validate[ai: "jcl-validator:v1"] {
  model: "jcl-validator:v1"
}
interpret[ai: "spool-interpreter:v1"] {
  model: "spool-interpreter:v1"
}
email[utility: "Send Email"] {
  template: "job-failure-summary"
}
submit --> validate
validate.success --> interpret
interpret --> email when status == "failed"

The platform is not mainframe-specific

The same architecture extends to CI/CD and QA. A new domain means new models, not a new platform.