Writing
Building an Autonomous MCP Server with HITL Guidance
This experiment had a simple setup: ask an AI assistant to build not a toy script but a working MCP server with human-in-the-loop behavior baked in. It got further than I expected. The caveat — there is always a caveat — is that I still had to steer the shape of the solution the whole way. The build also turned out to be a decent test of agentic infrastructure in general, because it forced the agent to define tool contracts, handle state, and expose a workflow another system could call.
HITL is a protocol, not a meeting
The phrase "human in the loop" usually means something vague: a person will look at it at some point. That is not a design. The version that works is a protocol. The agent returns a compact decision packet — current state, proposed action, evidence, uncertainty, expected side effect, rollback path — and the human approves, rejects, edits, or asks for more, through a structured interface rather than a wall of chat.
This is what makes autonomy composable. An orchestrator can pause on the approval state. A reviewer can inspect the artifact. An audit log can show why the action was allowed. A future eval can replay the decision and ask whether the agent should have escalated sooner.
The implementation details matter more than they look. Approval states should be explicit — waiting_for_human, approved, rejected, expired, superseded — and an approval should attach to one exact proposed action, not to the whole task forever. Persist the evidence the human saw at approval time, because "what did we know when we said yes" is the first question asked after anything goes wrong. And let humans edit constrained parameters without rewriting the agent's whole plan; the alternative is a veto-only interface, and veto-only interfaces get rubber-stamped.
Where humans belong in the loop
The deeper lesson is that HITL is a placement decision, not just an approval step. Humans should sit at the points where the system lacks context, where a wrong action is expensive, or where taste and policy matter more than mechanical execution. Everywhere else, a checkpoint is just latency.
I would start narrow: small tasks, tight review, and autonomy that expands only after the review loop proves it works. Autonomy paired with a control surface is useful. Autonomy without one is a liability with good manners. HITL is not a weakness in the system; it is how the system earns permission to do more.