What changes when a Miiwa Agent moves into real work?
A Miiwa Agent enters real work when a published native workflow is assigned to people or connected to approved triggers, and its runs and outputs become part of a workspace’s operations.
The decisive move in Miiwa is not from a weak model to a stronger one. It is from a Builder testing a graph in Native Studio to a specific, published version being used by people or invoked by an operational trigger.
The deployment becomes the production boundary
A Studio project can evolve through many edits and versions. A deployment points runtime traffic at the validated version intended for use. That gives Miiwa a stable object to assign, authenticate, trigger, observe and—when required—replace without exposing the editable graph to users.
- Project
- The authoring home for the workflow, its system behaviour and related versions.
- Version
- A fixed snapshot of the workflow definition used for validation and deployment.
- Deployment
- The published delivery boundary that connects a version to assignments and trigger configuration.
- Assignment
- The workspace- or user-level rule that determines whether a published Miiwa Agent is visible and runnable.
- Run session
- The persisted execution record containing workflow state, trigger context, status and result.
Real work can enter Miiwa in several ways
| Entry path | Typical operational use |
|---|---|
| Assigned agent | A user opens a finished Miiwa Agent, supplies guided input and receives the output. |
| Webhook | Another system starts the deployed workflow when an external event occurs. |
| Inbound email | A configured address turns an incoming message into workflow context. |
| Browser extension | A user sends selected page context into an allowed deployment. |
| Schedule | Miiwa queues recurring work without a builder keeping Studio open. |
| MCP | An approved external client invokes an assigned Miiwa Agent as a tool. |
The end-user experience gets smaller
In Studio, a Builder needs the canvas, block configuration, variables, model choices, logs and debugger. In delivery, a User needs only the assigned agent, its input form, relevant progress and the resulting output. Miiwa uses the same underlying workflow while deliberately removing the authoring surface from the user experience.
The work now has durable state
A production run records which workspace, deployment, version, workflow and trigger created it. While running, Miiwa can persist the current block, input and variables, emit run events, pause for a person and later resume. On completion or failure, the session retains the output or error context needed by the product’s history and operational surfaces.
That state is what turns a generated answer into operational work. A user can return to a completed run, a builder can inspect where a workflow failed, and an automated trigger does not depend on one browser request staying open from start to finish.
Who owns what after launch?
| Role | Operational responsibility in Miiwa |
|---|---|
| Admin | Own workspace access, shared service configuration, integrations, governance and platform-level operational controls. |
| Builder | Own the workflow graph, input and output contract, tests, version changes and interpretation of run failures. |
| User | Supply the requested business context, use the delivered output and report when the finished tool does not support the real case. |
| Native runtime | Execute the published graph, enforce its runtime boundaries and persist the run lifecycle. |
The output becomes the product
Miiwa can deliver more than raw text: a structured result, rendered HTML interface, generated image, video or speech asset, or an output stored for later use. Domain surfaces such as Marketing Hub can take native agent results into outbox, approval, calendar, report and result-bundle workflows. The value is the usable artifact and the next controlled step—not the number of messages exchanged with a model.
A Miiwa production checklist
- Choose the workflow version and resolve every publish-readiness error.
- Publish a deployment inside the correct workspace.
- Assign the Miiwa Agent at workspace or user level, including explicit allow or deny rules where needed.
- Enable only the trigger paths the workflow is designed to handle.
- Confirm Service Router credentials and required integrations in the same workspace context.
- Test guided input, pauses, failures, outputs and any unattended execution path.
- Inspect run history, errors, output quality and cost before widening access or automation.
When a Miiwa Agent moves into real work, the workflow stops being a Builder’s graph and becomes a workspace capability with a version, deployment, assignment, trigger, run history and delivered output.
Common questions
- Is publishing a Miiwa Agent the same as assigning it to users?
- No. Publishing creates the deployment boundary for a validated workflow version. Workspace and user assignments determine who can see and run that published Miiwa Agent.
- Can one deployed workflow be used from both the dashboard and MCP?
- Yes, when its deployment and workspace configuration enable those entry paths. Both calls reach the native workflow runtime, while each entry path still applies its own authentication and visibility checks.
- Does a Miiwa User need to choose the model or integration for every run?
- No. Builders and admins configure those decisions in the authoring and control layers. The user supplies the business input requested by the finished tool and receives its output.