Workflows are live handoff paths
A Midfleet workflow is not a Zapier or n8n-style automation canvas. It is an execution map for agent work: who owns the next boundary, what evidence is required, which policy applies, and which handoff can advance.
Intent -> draft -> compiler -> handoff contracts -> launch readiness -> runtime admission -> blocker or run -> evidence-backed completion
Edges are managed responsibility transfers
Every transition should resolve into a handoff contract with source role, target role, scope, artifacts, allowed actions, guardrails, acceptance criteria, and audit events.
- Define who is handing off and who can accept.
- Name the scope, claimed resources, and expected next action.
- Attach required artifacts and evidence before completion.
- Resolve policy, approval, and blocker state before the boundary advances.
Default delivery path
Choose lane, scope, risk, and owner path.
Produce plan, affected systems, and acceptance criteria.
Make the change in claimed scope with tests.
Check correctness, CI, evidence, and risks.
Attach durable evidence and complete the handoff.
What operators should verify
- The parent handoff has a clear scope and expected evidence.
- Each stage has a responsible role: analyst, developer, reviewer, product owner, or watcher.
- Reviewer and product-owner gates are explicit when risk, merge, or deploy decisions are involved.
- Completion evidence is attached to the handoff or PR, not trapped in chat.
- Blocked stages name the missing input and owner.
Change requests are part of the workflow
A review failure should not be treated as chaos. It should create a small, specific loopback: what failed, who owns the fix, what evidence will prove it is resolved, and whether the same reviewer must re-check it.