Build your first AI Colleague
Watch the tutorial
Create your first AI Colleague
Step 1: Navigate to AI Colleagues Dashboard
- Log into the platform
- Select "AI Colleagues" from the main navigation
- Click "Create AI Colleague"

Step 2: Configure Basic Settings
- Name: Name of the AI Colleague which represents its role. For example, 'HR Operations Specialist'.
- Description: The Job Description of the AI Colleague. For example, 'Automates employee onboarding, document compliance, and attendance management'.
- Escalation Manager: Select an employee as Escalation Manager. Wherever an AOP execution is stuck, it would reach out to Escalation Manager for further guidance.
Building Your First AOP
Step 1: Navigate to AI Colleagues Dashboard
- From your AI Colleague profile, click "Create AOP"


Step 2: Basic details of AOP
Fill in the basic details that define what the AOP is, how it runs, and who can use it.
AOP Name
The name of the AOP (business process). For example, "Daily Attendance Reconciliation."
Keep it short and action-oriented — the name is one of the signals the Master Orchestrator uses when deciding which AOP to route a user's query to, and it also appears in Run History and reports. Avoid vague names like "HR Process 1."
Description
A short description of what the AOP does. For example, "Check employee time punches against schedules, identify discrepancies, and request manager approval for exceptions."
The description is the primary routing signal — the Master Orchestrator reads it to match user queries to the right AOP. Describe what the AOP does and when it should be used, not how it works internally. A clear description directly improves routing accuracy.
AOP Model
Selects the LLM this AOP runs on — the model used to follow the AOP's instructions, make decisions, call tools, and generate responses during execution. Every AOP resolves to a model in one of two ways: inheriting from the Master Orchestrator, or holding its own.

Inherited from Master Orchestrator (default)
By default, the AOP uses the Master Orchestrator's model configuration and follows it live — if an admin changes the Master Orchestrator's model, every inheriting AOP switches with it, with no action needed on the AOP. The picker shows the currently inherited configuration (e.g., "GPT 5.5 · OpenAI — Inherited from MO") so you always know which model the AOP will actually run on.
Inheritance is the right choice for most AOPs: it keeps model management in one place and ensures consistent behaviour across the bot.
Or choose a specific model (override)
Override the inherited model when this AOP has different cost, speed, or reasoning needs than the rest of the bot — for example, a simple acknowledgement AOP that doesn't need a heavyweight model, or a complex multi-step decision flow that benefits from deeper reasoning.

The picker is organised provider-first. Select a provider, then a model:
| Provider | Available models |
|---|---|
| OpenAI | GPT 5.5, GPT 4.1 |
| Azure OpenAI | GPT 5.5, GPT 4.1 |
| Anthropic | Sonnet 4.6, Opus 4.6, Opus 4.7 |
| Amazon Bedrock (Anthropic) | Sonnet 4.6, Opus 4.6, Opus 4.7 |
An overriding AOP stores its own full configuration (provider, model, and model settings) and is unaffected by Master Orchestrator changes. Re-selecting the inherited option at the top of the picker returns the AOP to live inheritance.
Use the Compare models link in the picker header to view benchmarking data before deciding.
Model settings:
- Effort — Controls how thoroughly the model thinks before responding (Low / Medium / High). Higher effort improves reasoning quality on complex, multi-step AOPs at the cost of response time.
- Priority processing — Runs requests through a priority lane for faster, more consistent response times. Available on supported models only and On by default where supported.
How it works:
- Changes apply on save and take effect from the AOP's next run — in-flight runs are not affected.
- Run History and the Debugging Console record the resolved provider and model for every run (marked as inherited where applicable), so you can always trace which model handled a request.
- Existing AOPs default to inheriting the Master Orchestrator's configuration; nothing changes until you explicitly override.
AOP Type
Determines how and when the AOP can be executed — for example, whether it can be invoked by employees through the Virtual Assistant, triggered by another AOP, or run on a schedule. Access detailed documentation here.
Audiences
Controls who can use the AOP. An AOP can be enabled for all employees or restricted to specific employees/audiences. If restricted, only users in the selected audience can invoke the AOP from the Virtual Assistant — for everyone else, it won't be considered during routing. Use this for role-specific processes (e.g., a payroll correction AOP limited to HR Ops).
Attachments
Documents the AOP can reference at execution time. For example, a Reimbursement Policy document attached to a reimbursement AOP is parsed to fetch category-wise limits.
Attach reference material the AOP needs to make decisions — policies, rate cards, escalation matrices — rather than putting that content inline in the instructions. This keeps instructions short and lets you update the source document independently.
Step 3: Define AOP Steps
- The steps of the business logic can be provided within the 'Instructions' segment of the AOP.
- Use '@' to tag a step with a tool.

Step 4: Final 'Create' action
- Click on 'Create' to finally create the AOP.
- By default, an AOP is marked as Active at the time of creating it. Once marked as active, an AOP is enabled for utilisation by AI Colleagues.


Managing AI Colleagues & AOPs
Delete an AI Colleague
You can permanently delete an AI Colleague that has no AOPs linked to it.
- Click the ⋮ (kebab menu) on the AIC card.
- Select Delete.

- If the AIC has linked AOPs, you'll see an error.

- If no AOPs are linked, a confirmation modal will appear.

- Click Delete to confirm.
Delete a Draft AOP
Only AOPs that have never been published (status: Draft) can be deleted. Active or Inactive AOPs can only be deactivated.
- Click the ⋮ (kebab menu) on the draft AOP row.

- Select Delete.
- Review the confirmation message.

- Click Delete to confirm.
Clone an AOP
Cloning creates a duplicate of an AOP as a new draft. You can clone any AOP regardless of its status (Active, Inactive, or Draft) and place the clone in the same AIC or a different one.
- Click the ⋮ (kebab menu) on the AOP row.

- Select Clone.
- Select the target AIC for the clone.
- Click Clone.

- You will be directed to a create new AOP page. Cloned AOP requires a unique Name, Identifier and Description to avoid conflicts with the original AOP.

- Click Create after filling in the details.
- A validation check will validate your AOP.

- Click Publish.
A new cloned AOP is created in the target AIC.
Transfer an AOP
Transferring moves an AOP from one AI Colleague to another. The AOP retains its identifier, name, all versions, and execution history. You can transfer Active, Inactive, or Draft AOPs.
- Click the ⋮ (kebab menu) on the AOP row.
- Select Transfer.

- In the Transfer modal, select the Target AI Colleague.

- Click Transfer.
Updated 10 days ago
