01 / Midva
Queues the request
Midva keeps the conversation, process state, and the next action for the runner.
How it works
Midva coordinates the work. Your computer runs it.
Midva sends each request to a local runner. The runner opens the project on your computer, passes your request to your local AI or runs a fixed command, and reports the result. Raw execution logs stay with the runner.
Architecture
One outbound connection to the machine with your code.
The local runner asks Midva for work. Midva never needs an inbound connection to your computer.
02 / Local runner
Claims and executes it
The runner polls Midva, claims available work, and starts it in the registered project path.
03 / Your workspace
AI works beside the code
AI reads and changes files on the user's computer. Runner commands use the same local workspace.
Midva receives status, messages, and summary metrics. Complete Codex events and readable run logs stay on the runner host.
Three actors
Every active step has an owner.
Midva measures people, AI, and deterministic automation separately because they create different constraints.
Human
Decides and reviews
The human writes the request, answers questions, reviews the result, and decides what happens next.
AI
Reads and changes the project
AI handles the open-ended work inside the selected workspace and returns control with a response.
Runner
Runs fixed operations
The runner executes deterministic steps such as tests or deployment without asking AI to reason about them.
Starting process
Start with Direct. Add structure as you learn.
Direct gives you a measured baseline: a human sends work to AI, reviews the result, and can clear the context before the next request. From there, the process can grow with the work.
-
01
Direct AI + human
AvailableThe basic loop: request, AI run, review, and the next human action.
-
02
Midva Development
AvailableMidva's Elixir process gives tests, Credo, Dialyzer, and deployment to runner steps. AI fixes failed checks, then the process verifies the result again.
-
03
Your own process
PlannedMidva already runs versioned, composed processes. Self-service registration will let you build one for your stack and attach it to your Midva profile.
Runs and handoffs
One execution step is one run.
AI and runner work use the same accounting unit. Human work and waiting stay visible around those runs.
Human action
→
Concurrent machine work
→
Handoff
AI run A
AI run B
Runner run
Several AI and runner runs can move at the same time. Each one keeps its own start, finish, status, duration, and log. AI runs also record token usage and an API cost estimate. Midva counts a handoff when machine work returns control to a human.
Awaiting
One person can actively work on one task at a time.
AI and runners can serve several tasks concurrently, within their configured capacity. Human attention is the part that cannot be copied or scaled on demand.
Human capacity
1 active task
Task A · reviewing
Task B · awaiting human
Task C · awaiting human
AI + runner capacity
Concurrent runs
Task A · AI run
Task B · AI run
Task C · runner checks
Lever 01
Move work away from the human constraint
Delegate repeatable checks, preparation, and retry loops to AI or runner steps. Keep human time for decisions, clarification, and review that truly need it.
Lever 02
Make human time more effective
Keep the next decision ready, shorten gaps after handoffs, and protect focused review time. The aim is more useful progress from the same limited human capacity.
Midva keeps the causes separate. Global awaiting covers a deliberate pause or delayed start. Human awaiting starts when the next action needs a person, such as a reply, clarification, or review.
Local logs, shared summary
Detailed execution history stays on your computer.
The runner writes raw events and a readable log for every run. Midva keeps the summary used to compare tasks and find the next constraint.
Duration
AI, human, runner, awaiting
API estimate
Tokens and estimated AI cost
Handoffs
Returns to human action
Run log
Raw events and readable output