Skip to main content
When a troubleshooting session ends well, you usually want to run it again — against a different host, a different interface, a different incident. Procedures are that. They capture the successful path as markdown with fixed metadata — title, description, arguments, allowed tools, a maximum turn budget, success criteria, and the steps themselves. You author a procedure once and run it as many times as you need. Each run substitutes your argument values into the body, restricts Copilot to the allowed tools, and executes as a single controlled loop with progress, token accounting, and a full transcript. Procedures are the bridge between one-off investigation and a repeatable operating practice. The good ones start as a chat that worked.

​
Creating a procedure

The fastest way to build a procedure is to promote a conversation that already succeeded. Studio reads the successful path out of the conversation, drafts the metadata, and drops you into the procedure editor for review. You can also start from the Procedures activity. If your library is empty, the sidebar shows Create Procedure; selecting it seeds Copilot with a Create a procedure... prompt so you can describe the runbook you want in natural language. That empty state is deliberate. Studio treats procedure authoring as a conversation first because the best procedure usually needs context: what device family it targets, which checks are safe, what success looks like, and which inputs should become arguments.
1

Right-click the conversation

Find the source conversation in the chat sidebar and open its context menu.
2

Choose Create procedure

Studio extracts the successful path from the conversation and opens a draft.
3

Review the draft in the procedure editor

The editor shows the title, description, arguments, allowed tools, success criteria, and the step body as markdown.
4

Adjust the metadata and steps

Tighten the title and description, add or rename arguments, narrow the allowed tools, and state the success criteria in terms you can check.
5

Save

Run becomes available once everything is saved.
You can also create a procedure from scratch. Start blank, write the steps as markdown ## headings, and define the arguments and allowed tools that make sense for the work.
When you are starting from scratch, describe the operational goal, target device type, required arguments, and safety constraints in the Copilot prompt. A useful first prompt is: “Create a procedure for checking BGP adjacency health with arguments for hostname, neighbor IP, and VRF. Use read-only checks only.”

​
From prompt to runbook

When you use Create Procedure from the sidebar, describe the operation the way you would brief another engineer:
  • The operational goal.
  • The target type, such as Cisco IOS-XE edge routers or Linux jump hosts.
  • Required arguments, such as hostname, interface, neighbor_ip, vrf, ticket_id, or maintenance_window.
  • Tools that are allowed and tools that are out of scope.
  • Commands or checks that must stay read-only.
  • The evidence that proves the run succeeded.
Copilot drafts the procedure from that prompt, but you still own the final shape. Review the allowed tools carefully, replace vague steps with explicit checks, and keep destructive or configuration-changing actions behind a clear approval point.

​
Procedure fields

FieldPurpose
TitleName shown in the library, sidebar, and run tab.
DescriptionOne-paragraph summary of what it does.
ArgumentsNamed values substituted into the procedure at run time ({{hostname}}, {{interface}}, etc.).
Allowed tools* for all available, or a specific list. Narrow this for production procedures.
Default modelOptional override — fast, balanced, or deep.
Maximum turnsUpper bound for the run.
When to useGuidance for operators choosing between procedures.
Success criteriaConditions the run should satisfy before stopping.
StepsMarkdown ## sections forming the ordered body.
StatusDraft, active, or archived.

​
A good procedure shape

Use this structure when you are writing by hand: 
## Confirm scope
State the host, interface, VRF, ticket, or incident context the run will use.

## Gather read-only evidence
Run commands or connector calls that cannot change state.

## Interpret the evidence
Summarize findings and decide whether the procedure should continue.

## Stage any change
Prepare commands or API calls, but keep execution behind approval.

## Validate
Run the post-checks that prove the expected state is present.

## Report
Return the final finding, evidence, and follow-up actions.
Not every procedure needs every section. The pattern matters because it keeps the run auditable: scope first, evidence before action, validation after action, report at the end.

​
Running a procedure

Pick the procedure from the sidebar, supply values for its arguments, and Studio opens a run tab. The bottom panel streams live progress — turn count, token usage, tool calls, and output — and the transcript is preserved for later review. You can stop a run at any point if you’ve seen enough.
StatusMeaning
PendingQueued, hasn’t started yet.
RunningIn progress.
CompletedFinished successfully.
FailedHit an error or exceeded the turn budget.
CancelledYou stopped it.

​
Authoring guidance

  • Extract procedures from working conversations whenever possible — replay is more reliable than recall.
  • Keep steps linear. Describe decisions inside a step rather than branching.
  • Use specific arguments (hostname, interface, vrf, site, change_ticket) over vague ones.
  • Put read-only validation before any command that changes state.
  • Write success criteria you can check from evidence, not just intent.
  • Don’t include exploratory dead ends from the source conversation.
  • Avoid * allowed tools for production procedures unless the operator will pick at run time.
  • Prefer Ask or Planning while drafting production procedures, then run in a controlled scope before marking active.
  • Archive procedures you no longer trust rather than leaving stale runbooks in the main library.

​
Run history

Every run stores its arguments, messages, tool summaries, token usage, final output, and the full transcript. Past runs are searchable and shareable — so you can compare two executions of the same procedure, link a run to a change ticket, or hand a transcript to a colleague for review.

​
Reflection and repair

When a run fails or finishes outside its success criteria, Copilot can reflect on the transcript — what was attempted, what evidence was gathered, where the run diverged — and propose a repair to the procedure body or the allowed tools. Reflection is a separate step from the run itself: it generates a diff against the procedure, you review it, and you decide whether to apply it. The original run transcript stays intact as evidence either way. Use reflection sparingly. A procedure that needs reflection often is a procedure that’s trying to do too much in one runbook. The healthier response is usually to split it.

AI Copilot

The conversation surface that produces the best procedures.

Memories and search

Keep the facts procedures rely on close to the work.