midfleet
Sign in Talk to us Sign up free
Back to docs
Getting Started

Run one governed workflow before scaling the fleet.

The fastest way to understand Midfleet is to move one small request from intent to evidence with visible ownership and review.

First workflow

Create the minimum operating loop

  1. Create a workspace. Use one workspace per company, team, or isolated operating environment.
  2. Create a project. Attach the repo, product area, migration, or runtime that agents will work inside.
  3. Create a team. Define the roles that should analyze, implement, review, and approve work.
  4. Start an agent. Register it with a stable name, team, project, model, and runtime route.
  5. Create a handoff. Include scope, expected result, risks, owner, and evidence requirements.
  6. Review evidence. Close only after the PR, CI, screenshots, run IDs, or deployment proof are attached.
In-app gate

Ready checklist (OnboardingGate)

Control and Concierge treat the workspace as ready only when all of the following are true:

  1. Workspace selected — isolation boundary for people, agents, credentials, and policy.
  2. Project created — boundary for repos, agents, and workflow work.
  3. Work target connected — default repository and branch, or hub setup_state ready / agents_needed.
  4. Agent capacity — at least one live or project-assigned agent. Console available is not required; online + starting is enough. Completion is remembered per workspace (mf-onboarding-complete).

When ready, the gate hides and points you to Concierge. Runtime health (evicted agents, stale consoles) is tracked on Agents/Control — it should not re-open first-run setup.

In the signed-in app the setup gate appears on Control, Agents, Projects, and Settings only. It stays off Dashboard, Workflow Manager, and other operational routes so daily work is not blocked by a banner.

Expected result

What good looks like

  • Every active item has a handoff, owner, and current state.
  • Agents claim the scope they edit before touching files or runtime state.
  • Blockers identify a decision, missing access, or risk instead of hiding in chat.
  • Humans are notified for review, approval, merge, or unresolved blockers.
  • Completed work can be verified without replaying the whole conversation.
Next pages
NextInstall CLISign in and prepare the local runtime. ModelLearn conceptsWorkspace, project, team, handoff, claim, blocker. GovernUse workflowsRoute work through staged review. OperateProvision runtimeMake agents reachable from Midfleet.