Midva coordinates human actions, AI reasoning, and deterministic execution as one adaptable
process. It measures each actor’s work and every handoff so its owner can change the process
around the current constraint.
H-01 / ACTORS
Delegate to Runner what limits Human or AI.
In the basic Human → AI process, without agentic loops, human attention limits throughput
and AI reasoning drives cost. Runner is the process harness that takes repeatable work from
either actor. It orchestrates AI calls and executes deterministic steps without human
attention or AI reasoning.
Human
Judgment
Decisions · review · approval
Limited capacity sets throughput.
DELEGATES→
AI
Reasoning
Analysis · open-ended changes
Every reasoning turn adds cost.
↓ DELEGATE REPEATABLE WORK↓ DELEGATE KNOWN OPERATIONS
A shared event history makes active work, queues, handoffs, and cost comparable across
cycles. The record exposes anomalies that intuition can miss.
E-01
Steps and ownership
Which actor held the work, what it attempted, and what state followed.
WHO / WHAT
E-02
Time and handoffs
Active duration, ready-but-waiting time, queues, and control transfers.
WHEN
E-03
Tokens and execution
Token usage, run status, checks, and the evidence returned for review.
COST / RESULT
H-03 / PROCESS
The process coordinates the actors.
A process describes who acts, what can run concurrently, when a handoff is ready, and
which evidence must return. Change the process when you see a way to decrease the
responsibilities of the constraint or its idle time.
CURRENT OWNER DEVELOPMENT PROCESS
The delivery loop kept its shape while ownership changed.
STARTING PROCESS
The human carried the delivery loop.
AI changed code and ran mix test. The human prepared the workspace,
reviewed the result, synchronized with dev, deployed, and cleaned up.
HUMAN TASKAI TASKLATER DELEGATED TO RUNNER
HUMANRUNNER / PROCESS NOT YET USEDAI
1 / PREPARE
01HUMAN / WORKSPACE
Prepare the workspace
Update dev, create the task branch and worktree, install dependencies, and compile.
Later delegated to Runner
02HUMAN → AI
Write the implementation request
Describe the change and wait until the workspace is ready before starting AI work.
2 / IMPLEMENT AND CHECK
03AI / WORKSPACE
Change the code
Implement the request and inspect the affected paths.
04AI / CHECKS
Format and run the test suite
Use AI time to execute repeatable checks and interpret their output.
Later delegated to Runner
3 / REVIEW AND REPAIR
05HUMAN / REVIEW
Review the result
Read the diff and check results, apply coding rules, then describe any repair.
06AI / REPAIR
Repair review findings
Apply the feedback, rerun affected tests, and return the result for another review.
4 / SYNC AND RELEASE
07HUMAN / GIT
Synchronize with dev
Merge the latest dev revision, resolve conflicts, and repeat verification.
Later delegated to Runner
08HUMAN / RELEASE
Publish and deploy
Commit, push, deploy the verified revision, and remove the task workspace.
Later delegated to Runner
CURRENT PROCESS VERSION 9
Runner carries the repeatable work.
The human decides what to do. AI handles open-ended implementation and repair.
Runner owns preparation, deterministic gates, Git synchronization, and release
mechanics.
HUMAN DECISIONAI REASONINGRUNNER RESPONSIBILITYASYNC STAGE
HUMANRUNNER / PROCESSAI
1 / START AND PREPARE ASYNC
01HUMAN → PROCESS
Start the task and send the request
Midva queues the implementation message while workspace preparation continues.
02RUNNER / WORKSPACE
Prepare an isolated workspace
Resolve the exact origin/dev revision, create or reuse the task branch, install dependencies, and compile when needed.
2 / AI IMPLEMENTATION
03PROCESS → AI
Implement in the prepared workspace
Change the code, inspect the diff, and request focused checks from Runner.
04AI → PROCESS
Return the primary response
The human can send another message or start another process while later stages continue.
3 / QUALITY PIPELINE ASYNC
05RUNNER / CHECKS
Run deterministic gates
Capture changes, format, preflight, audit dependencies, run Credo, Dialyzer, mix test, and Playwright.
06PROCESS → AI
Review coding rules in parallel
Reviewers inspect explicit checklists in batches of up to eight files, with four batches running at once.
07AI → RUNNER
Repair concrete findings once
If reviewers find a problem, AI applies the findings in one turn and Runner repeats the affected checks.
08RUNNER / GIT
Publish the verified task revision
Commit the captured change set and push that exact revision to the task branch only.
4 / SYNC WITH DEV ASYNC
09RUNNER / GIT
Check the durable sync point
If origin/dev moved, merge it into the task tree, run the full suite, and update only the task branch.
10RUNNER / STATE
Preserve recoverable failures
Use one bounded repair or retry. If work stops, keep the task and worktree intact.
11RUNNER → HUMAN
Return the reviewed revision
Midva hands control back after queued messages and processes have stayed in order.
5 / HUMAN DECISION
12HUMAN → PROCESS
Choose the next action
Continue implementation, ask a read-only question, run another process, or complete the task.
13RUNNER / PROCESS
Execute the selected process
Run review, verification, merge, staging, audit, production, or final integration under its versioned contract.
14RUNNER / GIT
Complete and clean up
For completion, merge current dev, verify, publish the exact revision to the task branch and dev, then remove local task state.
Dashed blue and black cards in the starting process mark work that Runner owns now.
H-04 / ADAPTATION
Midva coordinates. The local runner executes.
Midva aggregates the selected processes and plugins into one measured flow. A local
open-source runner executes that flow beside the workspace, so AI activity and detailed
execution logs stay local.
MIDVA
Coordinates the system
Aggregates processes and plugins, tracks state, and routes explicit handoffs.
LOCAL RUNNER
Executes capabilities
Runs AI actors, deterministic tools, and nested subprocesses while retaining local logs.
PRIVATE WORKSPACE
Keeps work close
Source, execution artifacts, and detailed AI traces remain beside the user’s work.
Stable capability boundaries let actors, providers, tools, checks, and handoff rules change
without turning the measured development system into a different product.