Recommended resources
The freely available resources this lesson will direct you to.
Introduction
Welcome to the final lesson of our course! In the previous lesson, we focused on creating the foundational technical documentation for an agentic workflow, covering its architecture, prompt versioning, and knowledge base maintenance. This documentation serves as the single source of truth for what the system is. Now, we will build upon that foundation to define how the system is used.
This lesson directly addresses your goal of delivering agentic AI as a professional service by focusing on the final, critical step of a client handover: developing Standard Operating Procedures (SOPs). These SOPs are the practical, step-by-step guides your client will use to operate, monitor, and handle escalations from the workflow you've built.
An effective set of SOPs transforms a complex agentic system from a "black box" into a transparent, governable, and reliable business asset. By the end of this lesson, you will be able to design SOPs that provide your clients with the confidence and capability to manage their new AI-powered workflows effectively.
1. The Shift from Human SOPs to Agent Operating Procedures
When you hand over a system to a client, you're not just delivering software; you're delivering a new way of working. Traditional SOPs for human employees rely heavily on implicit knowledge, context, and judgment. An agentic system requires a different, more explicit approach.
To grasp this distinction, let's explore the concept of Agent Operating Procedures (AOPs), which translate high-level business rules into a format that an AI can execute reliably.
Agent Operating Procedures: From Manual SOPs to Automated AI ...
The article 'Agent Operating Procedures' from Decagon.ai provides an excellent framework for thinking about this translation process. It clarifies why instructions for AI must be far more explicit than for humans.
Please read the introduction and the sections 'What are Decagon's agent operating procedures (AOPs)?' and 'How do AOPs for AI differ from SOPs for humans?'. Pay close attention to the comparison table, as it concisely summarizes the fundamental differences in interpretation, flexibility, and consistency.
As the article highlights, an AI agent cannot "read between the lines." This means your SOP documentation for a client must serve a dual purpose:
- For the Human Operator: It provides instructions on how to interact with the system, interpret its outputs, and respond to alerts.
- As System Configuration: It codifies the explicit business logic, rules, and escalation paths that the agentic system will execute. This part is often embedded directly into your version-controlled configurations, as we discussed in the previous lesson.
The rest of this lesson will focus on structuring an SOP document around the three critical functions a client's team will perform: operating, monitoring, and escalating.
2. The Three Pillars of an Agentic Workflow SOP
An effective SOP document is built on three pillars that correspond to the lifecycle of any task the agent performs. These pillars are the practical implementation of a governance framework, ensuring the system remains aligned with business goals, is controllable, and provides visibility into its operations.
The video below from IBM Technology introduces a high-level governance framework. The principles of Control and Visibility are what we will make concrete through our SOPs.
Building an AI Agent Governance Framework: 5 Essential Pillars
To understand the strategic context for our SOPs, let's quickly review the key pillars of AI agent governance.
Watch the sections on the 'Control' (03:19 - 05:00) and 'Visibility' (05:00 - 06:38) pillars. Note the specific strategies mentioned, such as action authorization policies, kill switches, activity logs, and incident investigation protocols. Our SOPs will be the documents that detail how to use these mechanisms.
Now, let's structure our SOP around these principles.
Pillar 1: Operating the System (Routine Procedures)
This section of the SOP covers the "happy path" and day-to-day management of the workflow. It should be written as a clear, actionable runbook for the client's operations team. It translates the technical documentation you created in the last lesson into procedural steps.
Your operations SOP should include instructions for:
- Task Initiation and Oversight:
- How to start a new workflow (e.g., via an API call, a UI button).
- How to view the status of all active and completed workflows.
- How to cancel a running task if needed.
- Routine Maintenance (linking to RAG documentation):
- Adding a New Knowledge Source: A step-by-step guide based on the ingestion pipeline documentation.
- Forcing a Re-index of the Knowledge Base: When and how to trigger a full refresh of the vector database.
- Reviewing and Updating Prompts: The process for proposing a change, testing it, and deploying it, following the versioning strategy from the previous lesson.
- User and Access Management:
- How to grant or revoke access to the agentic system.
- How to manage tool access permissions if applicable (Principle of Least Authority).
Pillar 2: Monitoring (Visibility)
This is perhaps the most critical section for ensuring long-term success. Given the non-deterministic nature of LLM-based systems, traditional monitoring of CPU and memory is insufficient. The SOP must define what to monitor to understand the agent's behavior, cost, and quality.
AI Agent Monitoring: Operational Guide (Part 1) - Medium
The article 'AI Agent Monitoring: Operational Guide' provides a superb, in-depth look at the specific metrics that matter for agentic systems. It is written from a system architect's perspective.
Read the introduction ('The Agent Monitoring Gap'), the 'Monitoring Architecture' section, and the detailed breakdown in 'What Actually Matters: Operational Metrics'. Finally, review the summary in 'What You’ll Actually Build'. Focus on understanding why metrics like Time-To-First-Token and Agent Step Counts are more informative than traditional latency or error rates.
Based on this guide, your monitoring SOP should define a dashboard or report that tracks the following key categories. For each metric, the SOP must specify the Target Range and the Alerting Threshold.
| Metric Category | Key Metrics to Monitor | Why It Matters for Agents | Example SOP Entry |
|---|---|---|---|
| Latency (Perceived) | • Time-To-First-Token (TTFT) • Per-step latency |
Users perceive speed based on initial response, not total time. Long steps indicate bottlenecks in reasoning or tool calls. | Target: TTFT < 1s. Alert: Trigger a P2 alert if average TTFT exceeds 2.5s over a 5-minute window. |
| Cost & Economics | • Token cost per task/user • Cost breakdown by model (e.g., GPT-4 vs. 3.5) |
Autonomous decisions can lead to unpredictable cost overruns. Tracks efficiency and prevents budget surprises. | Target: Average cost per task < $0.10. Alert: Trigger a P3 alert if any single task exceeds $2.00. |
| Behavior & Reliability | • Agent Step Counts • Max iteration threshold hits • Tool call error rates |
A rising step count is the earliest indicator of a "runaway" or looping agent. It signals inefficiency or confusion. | Target: 95% of tasks complete in < 8 steps. Alert: Trigger a P2 alert if the max iteration threshold (15 steps) is hit on >5% of tasks. |
| Quality | • LLM-as-Judge scores (relevance, helpfulness) • Format validation failures |
Measures if the agent is producing useful, correct, and well-structured outputs, not just avoiding crashes. | Target: Average helpfulness score > 4.0/5.0. Alert: Trigger a P3 alert for human review if relevance score < 2.0/5.0. |
This monitoring architecture provides the data needed for such a dashboard.

Pillar 3: Handling Escalations (Control)
This section of the SOP defines what to do when the system deviates from the happy path. It is the core of human oversight and control. From a design perspective, it's crucial that the system is built to make human intervention reliable and straightforward.
This is where the concept of "durable execution" becomes critical. If an agent needs to wait for human approval, the system must manage that state reliably, potentially for hours or days, without losing context or crashing.
Human-in-the-Loop (HITL) for AI Agents: Patterns and Best Practices
The following video from Temporal explains the technical challenges of building durable Human-in-the-Loop (HITL) workflows and demonstrates a robust solution. Understanding this enables you to design escalation procedures with confidence.
Please watch these three segments: The Challenge (05:05 - 09:11): This explains why waiting for human input is hard in distributed systems. The Solution Concept (09:11 - 11:58): This introduces the idea of 'durable execution' that handles state, resilience, and resource management automatically. The Durability Demo (32:25 - 41:13): This powerfully demonstrates the system's resilience by killing and restarting client and worker processes without losing the workflow's state. This is the technical guarantee that underpins a reliable escalation SOP.
With a durably designed system, you can define three types of escalation procedures in your SOP:
-
Pre-defined Human-in-the-Loop (HITL) Checkpoints:
- When: For high-stakes actions identified during the design phase (e.g., processing a refund over $1000, deleting user data).
- SOP: Defines who receives the approval request (e.g., "Finance Manager"), the information they will receive, the interface for approval/rejection (e.g., a link in an email, a button in Slack), and the SLA for their response.
-
Automated Failure Escalations:
- When: The agent's own internal guardrails are triggered. This includes hitting the max iteration limit, repeated tool failures, or failing output validation.
- SOP: Defines the automated action (e.g., "fail the task gracefully and notify the user") and the notification procedure (e.g., "create a high-priority ticket in Jira with the trace ID and error logs for engineering review").
-
Incident Response (The "Kill Switch"):
- When: For unexpected, severe failures such as a security breach, uncontrolled cost spike, or generation of harmful content that bypasses automated filters.
- SOP: Defines a clear, unambiguous protocol for immediate intervention. This is the "break glass" procedure. It should include:
- Who is authorized to activate the kill switch.
- How to activate it (e.g., an API endpoint, a button in a master control panel).
- What the kill switch does (e.g., immediately pauses all new tasks, gracefully terminates running tasks, reverts to a last-known-good version).
- The communication plan for notifying stakeholders.

Conclusion
You have now reached the end of the course and completed the final step in delivering a production-ready agentic service. By developing clear, comprehensive Standard Operating Procedures, you provide your client with the tools and knowledge not just to use their new system, but to own it.
Key Takeaways:
- SOPs Must Be Explicit for AI: Unlike procedures for humans, SOPs for agentic systems must translate business logic into explicit, machine-executable rules, covering every likely scenario and edge case.
- Structure SOPs Around Three Pillars: A robust SOP document is organized around Operating (routine tasks), Monitoring (observing behavior, cost, and quality), and Handling Escalations (managing exceptions and human interventions).
- Monitor What Matters: Focus on agent-specific metrics like Time-To-First-Token, step counts, and token cost attribution to gain true insight into system performance.
- Design for Durable Escalations: Build your system on an architecture that makes human-in-the-loop workflows reliable, allowing you to confidently design SOPs for approvals, automated failures, and emergency "kill switch" scenarios.
By mastering the journey from initial client problem to a proof-of-concept, and then to a fully documented and operational system with clear SOPs, you are now equipped to design, build, and deliver high-value agentic AI solutions as a professional service. Congratulations, and best of luck in your new ventures.