Workflow-backed virtual models: beyond LLM routing

Most model gateways expose a simple abstraction: the client sends a request to a model name, and the gateway selects a provider or forwards the request. That abstraction is useful, but it leaves the behavior of the model largely unchanged.

A workflow-backed virtual model goes one step further. The model name points to an executable workflow that may call several models, invoke tools, branch, verify intermediate results, and synthesize one final response. The client still sees one normal model endpoint.

Agent client
  -> virtual model endpoint
  -> workflow
     -> planner model
     -> vision or search tool
     -> parallel reviewers
     -> synthesis model
  -> observable final response

Routing chooses a model; a workflow composes behavior

Routing answers questions such as “which provider is available?” or “which model is cheapest for this request?” A workflow answers a different class of questions:

• Should a text model ask a vision model to inspect this screenshot?
• Should three models review the same implementation in parallel?
• Should a verifier reject an answer that does not match a required schema?
• Which node introduced the latency or token spike?

These decisions are part of the model behavior presented to the client. Once the workflow is published behind a model name, every compatible client can reuse the same behavior without reimplementing orchestration.

Why protocol compatibility matters

Local agent tools already understand common APIs. Claude Code, Codex, OpenCode, Cline, Continue, and application SDKs should not need a custom integration for every workflow.

Publishing the workflow through OpenAI Responses, Chat Completions, or Claude Messages APIs preserves the small client-facing surface:

base URL + API key + model name

The workflow can evolve behind that contract. A single-model chain can become a vision-assisted workflow or a multi-model panel without changing every client.

Observability must follow the workflow graph

When one response contains several model calls and tool callbacks, request-level logging is not enough. Developers need to connect the final answer to:

1. Each workflow node that executed.
2. The exact input and output of every model call.
3. Tool arguments, results, duration, and errors.
4. Token consumption and latency by branch.
5. The synthesis step that produced the final response.

This graph-shaped evidence turns “the answer feels wrong” into a debuggable system. A weak reviewer, expensive branch, or failed visual tool can be identified directly.

When a virtual model is the right abstraction

Use a workflow-backed virtual model when the same enhanced behavior should be available to multiple clients, when orchestration is more complex than provider selection, or when you need connected execution evidence.

Keep a direct model endpoint when a single provider call is already sufficient. The goal is not to add a graph to every request; it is to make valuable composition reusable and observable.

1flowbase provides the visual runtime, protocol publishing, and execution traces for this pattern. Start with the Fusion-style workflow guide or explore the source code.