Human in the loop

The hardest engineering problem in agent design isn’t getting the agent to do useful work. It’s making sure a useful agent doesn’t do harmful work. Studio’s answer is a single, opinionated architecture: every tool call passes through a classifier, every classifier-flagged call passes through an approval gate, the gate is rendered in a way the operator can actually read, and the operator can stop or redirect a run at any moment. This page is the engineering description of that architecture. It is the page to read if you are deciding whether to grant your team Autopilot.

​

The trust levels

Studio has three trust levels. They are the primary lever you have over agent behavior. The trust level applies to the conversation, not to the tool. A read-only call in Manual still asks for approval; a destructive call in Autonomous still pauses if the policy classifies it as Dangerous. The trust level moves the threshold; the classifier moves the floor.

​

Tool classification

Every tool that Copilot can call is classified before it runs. The class determines whether the trust level alone is enough to authorize the call. The classifier is part of the tool registry. Each tool’s domain (terminal, connector, MCP, diagram, search, network discovery, packet capture, etc.) declares which subset of its operations require approval. New connector and MCP tools default to Unknown until the org admin explicitly classifies them.

​

The approval gate

When a tool call requires approval, Copilot pauses and renders a card the operator can read. The card includes:

• The tool name and the domain it belongs to — so you know whether it’s a terminal command, a connector call, a write to your inventory, or a destructive operation on a device.
• The exact arguments — including the destination (host, connector endpoint, file path), the payload (command text, request body), and any parameters the model is filling in.
• The risk class — Read-only / Moderate / Dangerous / Unknown.
• The credential reference that would be used, if any — by name only, never the secret.
• A diff or preview for staged commands, so you can see the change in human-readable form before approving.
• Approve, reject, or modify as actions. Modify lets you edit the arguments before approving.

The approval gate is non-bypassable. A tool that wants to run cannot get past it; the agent simply waits. The wait is observable — Copilot’s status shows “awaiting approval” with the tool and the time elapsed.

​

Streaming and steering

While Copilot is running, you watch progress in real time. The right-side panel shows:

• The current model thinking state (when extended thinking is enabled).
• Each tool call as it streams (name, arguments, partial output as the call returns).
• Token and turn usage against the run’s budget.
• The classification and approval state of any pending tool.
• Sub-agent activity when a delegated agent is running.

You can act on what you see in three ways: Steering is a first-class feature. It exists because no one writes a perfect first prompt, and because plans drift. You should use it freely. The transcript will show what the agent did and what you said in response — that’s the record, and it’s complete.

​

Sub-agents inherit the gate

Copilot can delegate to specialist sub-agents — researcher, executor, terminal-ops, browser-ops, network discovery, procedure authoring. A sub-agent runs in the same conversation, with the same trust level, and the same approval policy. A delegation cannot escalate beyond what the parent’s posture allows. This matters because it would be easy to design an architecture where a sub-agent gets its own scope, and a Read-only researcher could quietly call a Dangerous executor without the parent’s gate. Studio’s design is the opposite: the gate sits at the agentic loop, every tool call from any agent goes through it, no exceptions.

​

Just-in-time credentials

When a tool call requires a credential — to authenticate to an SSH host, to call a connector — the credential is requested through the vault, not through the LLM. The flow is: This is what we mean when we say “secrets never enter the model context” — the LLM sees the credential reference, the protocol library sees the secret, and the two are wired together by the vault without the LLM ever holding the plaintext. The exception is procedure substitution: if a procedure body explicitly substitutes {{password}} into a prompt that goes to the model, that plaintext does enter the model context. This is documented under known limits and the AI-context scrubbing roadmap.

​

Pre- and post-tool hooks

Studio supports hooks that run before and after every tool call. Hooks are an extensibility point, not a default behavior, and they exist for organizations that want to:

• Log every tool call to a SIEM.
• Block specific tool argument patterns regardless of class.
• Reject calls that target hosts outside an allowlist.
• Re-classify a tool dynamically based on the argument (for example, treating interface gigabitethernet0/0/0 as Dangerous on the management interface).

Hooks run server-side or in the agent depending on the kind. Failed hooks block the tool call and surface the failure in the approval gate.

​

Choosing the right posture

A practical mapping for the kinds of work Studio gets used for: The shape that emerges: the threshold for Autopilot is “I know what’s allowed and what target it’s allowed against.” Not “I trust the agent.”

​

What this is not

The HITL surface is not a substitute for any of the following:

• A change-management process. Approval at the agent gate is not approval at the CAB.
• A separation-of-duties review. One person approving their own approvals is one person doing both.
• An audit log. The gate produces evidence; the audit page describes what’s recorded.
• A guarantee that the agent does not surprise you. The gate makes surprises observable, not impossible.

The gate is the enforcement point. Process around it is the reason the enforcement matters.

​

Related