Writing

Building an Autonomous MCP Server with HITL Guidance

This experiment asked a practical question: how far can an AI assistant get if the target is not a toy prompt but a working MCP server with human-in-the-loop behavior? The answer was encouraging, with the usual caveat that the human still had to steer the shape of the solution.

The core idea

The value of HITL is not just approval. It is a design pattern. Humans should intervene at points where the system lacks context, where the cost of a wrong action is high, or where taste and policy matter more than mechanical execution.

Why it matters

The MCP server became a useful test because it forced the agent to build interfaces, define tool contracts, handle state, and expose a workflow that another system could call. Those are the real ingredients of agentic infrastructure.

How to use it

The HITL interface

Human-in-the-loop should be modeled as a protocol, not as a meeting. The agent should return a compact decision packet: current state, proposed action, evidence, uncertainty, expected side effect, rollback path, and alternatives. The human should approve, reject, edit, or ask for more evidence through a structured interface.

This is what makes autonomy composable. A downstream 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 model should have escalated earlier.

Implementation details

Bottom line

Autonomy becomes useful when it is paired with a control surface. HITL is not a weakness in the system; it is how the system earns permission to do more.