PLATFORM
Workflows
Make agent work reviewable before it becomes risky.
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.
text
Intent -> draft -> compiler -> handoff contracts -> launch readiness -> runtime admission -> blocker or run -> evidence-backed completionEdges 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
| Stage | Purpose |
|---|---|
| Classify | Choose lane, scope, risk, and owner path. |
| Analyze | Produce plan, affected systems, and acceptance criteria. |
| Implement | Make the change in claimed scope with tests. |
| Review | Check correctness, CI, evidence, and risks. |
| Close | 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.