Back to docs
Workflows

Make agent work reviewable before it becomes risky.

Workflows route a handoff through staged analysis, implementation, review, approval, merge, and closeout.

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

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.