Watch the tutorial

Agent Operating Protocols (AOPs) follow a structured format that defines clear, sequential steps for automating business processes. Each AOP is composed of numbered steps that specify actions, skills to use, and expected outcomes.

AOP Step Structure

Each step in an AOP follows this format:

Step "<Step Name>": <Action Description>. <Skill/Tool Reference>. <Additional Context/Requirements>.

Key Components:

Step Number: Sequential ordering (1, 2, 3, etc.)
Step Name: Descriptive title in quotes
Action Description: What needs to be accomplished
Skill Reference: Specific skill to use (prefixed with @)
Context: Additional requirements, conditions, or notes

Complete AOP Example

Employee Application Access Management

Here's a comprehensive example showing proper AOP structure and design:

AOP Name: Employee Application Access Management
Description: Automate the process of ensuring all employees have required application access
Audience: All Employees

1. Step "Fetch Employee Data": Use the @Fetch All Employee Details to retrieve comprehensive employee information which includes their current application access status, department, role, and manager information.

2. Step "Analyse Current Access": Check which employees do not have access to any of the required applications. All employees must have access to ALL of these applications - Gmail, Confluence, and Bitbucket. Compare current access permissions against the required application list for each employee. Identify employees missing access to one or more applications.

3. Step "Compile Access Requirements": Create a comprehensive list of which employee needs which application access. Organise the data showing employee details, current access status, and missing applications. Prepare the information in a clear, structured format.

4. Step "HR Manager Approval": Send the compiled access requirements to the HR head for approval. Present the data in a markdown table with columns: Employee Name, Employee ID, Department, Current Access, Missing Applications, Justification, Priority. Request approval for provisioning the missing application access for identified employees.

5. Step "Configure Missing Access": After receiving HR approval, loop through each employee requiring access configuration. Use @Configure Access for each missing application. Note that Configure Access can only work on one application at a time, so multiple iterations may be required per employee.

6. Step "Send Notification Emails": Use loop to send personalised emails to each employee using @Send Email. Include details of the applications newly configured for them and the result of each configuration attempt (Pass/Fail). Provide instructions for accessing newly provisioned applications if configuration was successful.

7. Step "Send Bot Notifications": Use loop to send personalised notifications on bot to each employee using @Send Bot Notification. Include details of the applications newly configured for them and the result of each configuration attempt (Pass/Fail). Provide instructions for accessing newly provisioned applications if configuration was successful.

Step-by-Step Breakdown

Step 1 Analysis:

Action: Data retrieval
Skill: @Fetch All Employee Details (Custom built workflow)
Output: Employee information with access status
Purpose: Foundation data for the entire process

Step 2 Analysis:

Action: Data analysis and comparison
Skill: N/A
Logic: Compare actual vs required access
Criteria: Gmail, Confluence, and Bitbucket access
Output: List of employees with missing access

Step 3 Analysis:

Action: Data organization and formatting
Skill: N/A
Purpose: Prepare information for human review
Format: Structured data showing gaps
Skill: N/A

Step 4 Analysis:

Action: Human approval workflow
Skill: Not a direct skill tagged, but implicitly uses 'Feedback Task skill' to take approval/input
Stakeholder: HR head
Format: Markdown table with specific columns
Decision Point: Continue only with approval

Step 5 Analysis:

Action: Automated configuration with loops
Skill: @Configure Access (Custom built workflow)
Constraint: One application at a time
Logic: Iterate through employees and applications

Steps 6-7 Analysis:

Action: Multi-channel notification
Pattern: Loop through employees
Skills: @Send Email and @Send Bot Notification
Content: Personalised status updates (designed through LLM)

AOP Design Principles

1. Clear Sequential Flow

Number steps sequentially (1, 2, 3...)
Each step should logically follow the previous one
Avoid branching or complex conditional logic in step descriptions
Use clear, descriptive step names

Example:

✅ Good Sequential Flow:
1. "Fetch Data" → 2. "Analyze Data" → 3. "Generate Report"

❌ Poor Sequential Flow:
1. "Do Everything" → 2. "Check Something" → 3. "Maybe Send Email"

2. Specific Skill References

Always reference skills with @ prefix (@Skill_Name) and select relevant skill.
Specify skill parameters and requirements clearly
Include error handling considerations

Examples:

✅ Correct Skill Reference:
"Use @Configure Access for each missing application"

❌ Incorrect Skill Reference:
"Configure access somehow"
"Use the configuration tool"

3. Data Flow Management

Clearly indicate how data flows between steps
Specify what information is passed from one step to the next
Include data transformation requirements
Document expected outputs from each step

Data Flow Example:

Step 1: Retrieve employee data → [Employee records with access status]
Step 2: Analyze access gaps → [List of employees missing access]
Step 3: Format for approval → [Structured report]
Step 4: Get approval → [Approval decision + authorized actions]

4. Loop and Iteration Patterns

When processing multiple items, use clear loop syntax:

Good Loop Examples:

"Use loop to send personalised emails to each employee using @Send Email"
"Loop through each employee requiring access configuration"
"Iterate through all departments for compliance checking"

Include:

What to loop through (employees, applications, records)
What action to perform in each iteration
What skill to use for each iteration
How to handle errors within loops

5. Approval and Human Interaction

For steps requiring human approval:

Structure:

"Send the [item] to the [role] for approval. Present the data in [format] with columns: [column list]. Request approval for [specific action]."

Example:

"Send the compiled access requirements to the HR head for approval. Present the data in a markdown table with columns: Employee Name, Employee ID, Department, Current Access, Missing Applications, Justification, Priority."

6. Error Handling and Fallback Logic

Handling skill or system failure:

Pattern

For each step that uses a skill, define:

What could go wrong (API timeout, invalid data, permission denied)
What to do about it (skip and continue, retry, escalate, halt)
Who gets notified if something fails

Example:

Step 5: "Configure Missing Access":
  Use @Configure Access for each missing application.
  
  Error Handling:
  - After the loop completes, compile all failures into a summary.
  - If more than 20% of configurations failed, escalate to IT Admin
    with the failure summary and pause further processing.
  - If fewer than 20% failed, include failures in the final
    notification email to HR for manual follow-up.

7. Conditional Branching and Decision Logic

For business processes that have conditions.

Example:

Step 4: "Route Approval Based on Department":
  - If department is "Engineering": Send approval request to Engineering Manager.
  - If department is "Finance": Send approval request to Finance Director.
  - For all other departments: Send approval request to HR Head.

8. Use of Helper AOPs

When an AOP contains a block of logic that is reusable, complex, or shared across multiple AOPs, extract it into a separate Helper AOP and call it from the parent.

When to Use a Helper AOP:

Reusable logic — The same sequence of steps appears in multiple AOPs (e.g., "send tiered approval", "fetch and validate employee data", "generate and email a PDF report").
Complex sub-processes — A block of steps within your AOP is self-contained and has clear inputs/outputs (e.g., "onboard a single employee" called inside a loop that processes 50 new hires).
Separation of concerns — The parent AOP handles the business flow; the Helper AOP handles the technical detail (e.g., "call Workday API, handle auth, parse response, retry on failure").

Pattern

Define clearly:

What the Helper AOP expects as input (parameters passed from the parent)
What the Helper AOP returns as output(data passed back to the parent)
Where it's invoked in the parent AOP (which step calls it and what it does with the result)

Example:

Helper AOP: "Tiered Approval Request"

Helper AOP Name: Tiered Approval Request
Description: Sends an approval request to a role, with automatic
             escalation if no response is received.

Inputs:
  - APPROVAL_DATA: The data to present for approval (markdown table)
  - APPROVER_ROLE: Who to send the request to first
  - ESCALATION_ROLE: Who to escalate to if no response
  - TIMEOUT_HOURS: How long to wait before escalating

Step 1: "Send Approval Request":
  Send APPROVAL_DATA to APPROVER_ROLE for approval.

Step 2: "Wait and Escalate if Needed":
  - If approved within TIMEOUT_HOURS: Return approval status = "Approved"
    along with any approver comments.
  - If rejected within TIMEOUT_HOURS: Return approval status = "Rejected"
    along with rejection reason.
  - If no response within TIMEOUT_HOURS: Send reminder to APPROVER_ROLE.
    Wait another TIMEOUT_HOURS. If still no response, escalate to
    ESCALATION_ROLE.

Output:
  - Approval status (Approved / Rejected / Escalated)
  - Approver name and timestamp
  - Comments or rejection reason (if any)

Parent AOP calling the Helper:

AOP Name: Employee Application Access Management

Step 4: "Get HR Approval":"Use @Tiered Approval Request" with:
    APPROVAL_DATA   = access requirements table from Step 3
    APPROVER_ROLE   = HR Head
    ESCALATION_ROLE = VP of HR
    TIMEOUT_HOURS   = 24

  - If returned status is "Approved": Proceed to Step 5.
  - If returned status is "Rejected": End AOP and log rejection reason.
  - If returned status is "Escalated": Wait for escalation outcome,
    then proceed or end accordingly.

9. Attachments

For spreadsheets, policy documents, lookup tables, rule matrices — that the AI Colleague reads and uses during execution to make decisions.

Pattern

When using an AOP attachment, define:

What the attachment contains (describe its structure so the AI Colleague knows how to read it)
Which step uses it and for what purpose
How to interpret the data(which column to match on, what the values mean)
What to do if the attachment doesn't cover a case (fallback behaviour)

Example:

AOP Name: Employee Application Access Management

Attachment description:
  - "Role_Application_Matrix.xlsx": A spreadsheet with columns:
    Role, Required Applications (comma-separated), Access Level
    (Standard / Elevated). This file is maintained by IT and
    defines which applications each role requires.

Step 2: "Determine Required Access":
  For each employee from Step 1, look up their role in the
  attached "Role_Application_Matrix.xlsx".Use @Document Parsing.
  
  - Match the employee's role to the "Role" column.
  - Read the corresponding "Required Applications" list.
  - Note the "Access Level" for use in the approval step.
  
  If an employee's role is NOT found in the matrix:
  - Flag the employee as "Unmapped Role."
  - Do not skip them — include them in the approval request
    with a note: "Role not found in matrix — requires manual
    review to determine application access."