Agent-Human Interactions — How Humans and AI Actually Complete a Task Together
Three interaction modes between a human and an AI on one task, why chat is the wrong default for teams, and a practical test for which mode your process is actually running.
If you have run an AI pilot on an operations team, you have probably seen at least one of three patterns. Overflow: the AI produces so many proposals that the team reviewing them falls behind within a week, and the notifications quietly start getting ignored. Stall: the AI stops at the first decision point and waits for a human, and the process gets stuck because the human cannot always be available at the moment it asks. Miss: a condition was supposed to trigger AI action and nothing happened, because no one was watching and the AI had no way to fire on its own.
These get described as UX problems — notifications too aggressive, approval flow too demanding. They are not. They are symptoms of a mismatch between how the AI is actually interacting with the team and what the platform underneath supports.
Three modes, distinguished by context
When one human and one AI combine on one task, three distinct modes show up — distinguished not by who holds final decision authority, but by how context flows between them at that step.
In supervision, the AI holds the operational context continuously and the human samples it when attention allows. The AI can watch everything without fatigue; the human brings judgment when something genuinely matters. This is the mode most teams want and most tools fail to deliver — because true supervision requires the AI to prioritize what it surfaces, which requires context structured enough for it to know what “matters” actually means here. Without that, observations become an unfiltered notification stream, and the team’s response degrades into mass-dismissal.
In pair execution, the AI and the human share context turn by turn: the AI proposes, the human reviews and accepts or modifies, the AI proposes the next thing. This is what most AI products actually offer, and it is right for work that is genuinely paired — drafting a proposal, reviewing a plan. It is wrong for work that does not need per-step judgment, where it just means the human’s day gets in the way of the process.
In delegation, the AI acts inside a bounded envelope — what it can see, propose, and commit — defined by the process itself, not reconstructed by the AI on the fly. Delegation is not autonomy: a human is still accountable, simply not present at the moment of execution. When the envelope is well-defined, delegation is safe. When it is vague, it is dangerous, and teams are right to be nervous — the risk is never the AI’s reasoning, it is the quality of the envelope.
Why chat pushes teams toward the wrong mode
Most tools support only pair execution natively: a chat interface embedded in a workflow step. It is built on one assumption — there is one user, and they are present — which is the right assumption for an individual writing or researching, and the wrong one for a team.
Operational work has multiple people with different roles and different attention windows. A chat-based AI does not know where anyone else on the team is in their work; it knows what one person typed. Teams then try to simulate supervision by bolting dashboards onto that same chat mechanism — the observations become notifications, and overflow follows — and simulate delegation by writing longer prompts, which is a reconstruction of context that should have been structurally projected in the first place, and can be wrong, incomplete, or out of date.
The result: the dispatcher measured as more productive, while the cost quietly lands somewhere else — the supervisor drowning in notifications, the downstream team evaluating output without the context it was generated from, the team lead reconciling inconsistent decisions on a Friday afternoon. It reads as a productivity gain. It is usually a transfer.
Context as the coupling mechanism, not a policy choice
The real design work is not choosing a mode. It is deciding what context a step owns, what it inherits, and what it returns on completion. Get that right, and the three modes become available where they fit — delegation for the well-constrained cases, pair execution for the ambiguous ones — without anyone flipping a setting. Get it wrong, and every step collapses back to pair execution, with a tired human in the loop. This is why Metronome grounds every step in a governed model of the operation rather than a prompt: the mode available at a step is a property of how well that step is specified, not a switch an administrator sets.
A practical test
For any step where AI is involved, ask two questions. What does the AI need to see to do this step, and where does that context come from? If the answer is “the user types it into a prompt,” the step is structurally locked into pair execution regardless of what the tool promises. And: what happens if a human is not available when the step needs to run? If the answer is that nothing happens and the process stalls, you are running in pair execution even if delegation was the goal.
Next — Step 4: Decisions and Actions, on how agent decisions and actions become fully deterministic — dispatched, not inferred.