Blueprints are not workflows.

The essay

Blueprints are not workflows.

A blueprint is a reusable agent configuration. A workflow is a one-off orchestration. The distinction matters because the cost of building an agent is in the configuration, and the cost of running an agent is in the runtime. Blueprints are how the configuration gets reused; workflows are how the runtime gets orchestrated. Conflating the two is a common mistake.

A blueprint has a goal, a toolset (MCP servers), a memory schema, an RBAC profile, and an audit trail configuration. A blueprint is versioned. A blueprint is testable. A blueprint is what the operator ships. Multiple workflows can run on the same blueprint. Multiple operators can use the same blueprint (with operator-specific configuration overlaid).

A workflow is an instance of a blueprint running against a specific input. The workflow is what the runtime executes. The workflow has a start time, an end time, a status, a result, and an audit trail. The workflow is ephemeral. The blueprint is durable.

The conflation happens when the operator tries to make a blueprint out of a workflow, or a workflow out of a blueprint. A blueprint with a specific customer's data in it is a workflow, not a blueprint. A workflow that is meant to be reused across customers is a blueprint, not a workflow. The naming matters because the engineering matters — blueprints need versioning, testing, and rollouts; workflows need monitoring, retries, and escalation.

In the Netwit runtime, blueprints are first-class objects. They are versioned. They are tested in CI. They are rolled out via the same deployment pipeline as the runtime itself. Workflows are first-class objects too, but they are observed, not versioned. The separation is what makes the system auditable.