Skip to main content
Level 3 is where the AI agent becomes part of your actual business workflow. It is no longer just answering questions or guiding customers toward a decision. At this level, the agent needs to know what systems exist, what actions it is allowed to perform, and how requests should move through your business. An Operational Agent should understand the difference between what it can do on its own and what requires a human. It should know where to route conversations, how to create or update records, when to trigger handoffs, and what it must never do without confirmation.
In Hardcore Mode, Level 3 rules define the agent’s operational logic: what systems it can use, what actions it can perform, what records it can create or update, when it should route or escalate, and what it must never do without confirmation.

​
What Level 3 unlocks

After completing Level 3, your AI agent should be able to:
  • understand connected systems and their purpose;
  • know which actions are allowed and which are prohibited;
  • work with CRM fields, statuses, tags, notes, and next steps;
  • follow booking and scheduling rules;
  • support payment-related flows where relevant;
  • use the right source of truth when information conflicts;
  • route conversations correctly based on request type;
  • create cleaner handoffs for managers with full context;
  • reduce repetitive operational work for your team.

​
1. Integrations and connected systems

Your AI agent needs to know what systems exist in your business and how it is allowed to interact with them. List all systems the agent may need to understand or work with. Common systems include:
  • payment systems (e.g. PayPal, Stripe);
  • knowledge base tools (e.g. Zendesk, Notion);
  • booking systems (e.g. Calendly, Booksy);
  • CRM (e.g. Salesforce, HubSpot);
  • e-commerce platforms (e.g. WooCommerce, Shopify);
  • scheduling tools (e.g. Outlook Calendar, Google Calendar);
  • ERP (e.g. Microsoft Dynamics 365, NetSuite);
For each system, provide:
  • system name;
  • what it is used for;
  • whether the agent can access it;
  • whether the agent can read data;
  • whether the agent can create or update records;
  • allowed actions;
  • prohibited actions;
  • when a human manager should take over.
Good input example: 
System: HubSpot CRM
Purpose: Store inbound leads and track sales pipeline stages.
Agent can: create a new lead, update contact details, add notes, assign tags, and change lead status according to predefined rules.
Agent cannot: delete contacts, change deal value, apply discounts, or mark a deal as won without manager confirmation.
Handoff: transfer to a manager if the client asks for custom pricing, legal terms, or contract changes.
Why it mattersWithout a clear map of connected systems and permissions, the agent either does too little or tries to do things it is not authorized for. Explicit permission rules protect the business and ensure consistent handling.

​
2. Communication channels

The agent needs to know where conversations happen and what behavior is expected in each channel. Unlike Level 2 channel rules, which define communication tone and sales style, Level 3 channel rules define operational behavior: what data to collect, what actions to take, and what records to create in each channel. Common channels include:
  • Instagram;
  • Facebook Messenger;
  • WhatsApp;
  • Telegram;
  • Threads;
  • TikTok;
  • Viber;
  • website chat;
  • email;
  • phone;
  • marketplace messages;
  • other industry-specific channels.
For each channel, define:
  • whether the agent should respond there;
  • whether the agent can send links;
  • whether it can collect personal data;
  • whether it can trigger a handoff;
  • whether it should create a CRM record;
  • whether replies should be short or detailed;
  • whether it can confirm bookings or only collect requests;
  • any special restrictions.
Good input example: 
Instagram:
- Keep replies short and friendly.
- Ask no more than one question per message.
- Create a CRM lead if the user shares name and phone number.
- Transfer to manager for complaints or custom cases.

Website chat:
- Be more direct and informative.
- Qualify the lead earlier in the conversation.
- Collect name, email, phone, and service of interest before handoff.

Phone:
- Keep answers short.
- Avoid long lists or complex explanations.
- Move quickly toward identifying the need and confirming the next step.
Why it mattersChannel rules ensure the agent behaves appropriately in each context and that the right data is collected and routed regardless of where the conversation starts.

​
3. CRM logic: fields, statuses, tags, notes, and next steps

If the agent works with a CRM or lead tracking system, you must define the exact rules for creating and updating records. Include:
  • when to create a lead;
  • required fields;
  • optional fields;
  • available statuses and when to use each;
  • available tags;
  • what notes to add;
  • when to create next steps or reminders;
  • who owns the lead;
  • what triggers a handoff.
Good input example: 
Create a lead when:
- the user shares a phone number or email address;
- the user asks to book a consultation;
- the user asks for pricing and matches the target customer profile.

Required fields:
- name;
- phone number;
- communication channel;
- service of interest;
- lead source;
- preferred date or contact time;
- conversation summary.

Statuses:
- New inquiry;
- Qualified lead;
- Booking requested;
- Manager required;
- Not relevant.

Tags:
- hot_lead;
- price_question;
- booking_request;
- complaint;
- custom_case;
- returning_client.
Hardcore Mode tip 
If the user asks for the nearest available appointment and shares a phone number, set status to Booking requested and add tag hot_lead.
If the user asks only a general question and does not share contact details, keep status as New inquiry.
If the user complains about a previous experience, set status to Manager required and add tag complaint.
Why it mattersConsistent CRM logic means managers always receive leads with complete information. It also allows the business to track conversion, response time, and lead quality accurately.

​
4. Booking and scheduling systems

Businesses that use appointments, demos, reservations, or consultations must define explicit booking rules. Include:
  • booking system used;
  • whether the agent can read available slots;
  • whether it can suggest slots;
  • whether it can create bookings;
  • whether it can reschedule or cancel bookings;
  • information required before a booking can be made;
  • whether manager confirmation is required;
  • what to do if a requested slot is unavailable;
  • what to send after a booking is confirmed.
Good input example: 
Booking system: Calendly
The agent can read available slots and send the booking link.
The agent cannot manually create a booking outside the booking system.
Required information before sending the booking link: name, service of interest, and preferred time range.
If the requested time is unavailable, offer the closest available alternatives.
If the client wants to reschedule, collect current booking details and transfer to manager.
Important rule: 
The agent can confirm a booking only after the slot is successfully created in the booking system.
If the system does not confirm the slot, the agent must not tell the client that the booking is confirmed.
Why it mattersBooking rules prevent double bookings, incorrect confirmations, and uncoordinated scheduling. Clear rules protect both the client experience and your team’s calendar.
Payment flows require strict rules. The agent must know exactly what it is and is not allowed to do with payment information. Include:
  • accepted payment methods;
  • whether prepayment is required;
  • whether the agent can send payment links;
  • when to send a payment link;
  • whether the agent can confirm payment;
  • what to do if payment fails;
  • what to do after successful payment;
  • refund rules;
  • when payment questions must be transferred to a manager.
Good input example: 
Payment methods: online payment link, card at location, cash at location.
Prepayment: required for first-time clients.
The agent can send a payment link only after service, date, time, name, and phone number are confirmed.
The agent cannot manually confirm payment. Payment confirmation must come from the payment system.
Refund requests must always be transferred to a manager.
Why it mattersPayment rules protect the business from errors, fraud, and disputes. The agent should never make promises about payments or refunds that it cannot verify.

​
6. Routing and escalation workflows

The agent needs a clear map of where each type of request should go and what action to take. Define routing rules for each request type:
  • sales inquiries;
  • booking requests;
  • support questions;
  • complaints;
  • refund requests;
  • partnership requests;
  • technical issues;
  • VIP clients;
  • not relevant requests;
  • urgent requests.
For each type, define:
  • who owns it;
  • whether the agent handles it or escalates;
  • what information to collect before escalation;
  • priority level;
  • the message shown to the user;
  • the internal note added to the CRM or handoff.
Good input example: 
Sales inquiry:
- Agent handles initial qualification.
- If qualified, create a CRM lead and assign to the sales manager.
- Note should include service or product of interest, budget if mentioned, urgency, and preferred contact time.

Complaint:
- Acknowledge politely.
- Do not argue or defend the company.
- Collect name, phone number, order or booking details, and a summary of the issue.
- Transfer to support manager with high priority.

Partnership request:
- Collect name, company, email, and type of partnership.
- Assign to business development manager.
Why it mattersRouting logic ensures that requests reach the right person with the right context. Without it, the agent may handle things it should not or fail to escalate things that need human attention.

​
7. Knowledge base and source of truth

The agent must rely on accurate, current information. If documents conflict, it needs a clear order of priority. Common sources include:
  • FAQ;
  • price list;
  • product catalog;
  • service descriptions;
  • booking instructions;
  • delivery policy;
  • refund policy;
  • scripts;
  • tone of voice guide;
  • legal terms;
  • SOPs;
  • onboarding documents;
  • internal process documents;
  • examples of good and bad conversations.
For each source, define:
  • what it contains;
  • whether it is current;
  • who owns it;
  • how often it is updated;
  • priority if sources conflict;
  • whether the agent can quote it directly;
  • whether it is internal-only or customer-facing.
Good input example: 
Source priority:
1. Current price list — highest priority for all pricing questions.
2. FAQ — highest priority for common customer questions.
3. Booking policy — highest priority for rescheduling, cancellation, and no-show rules.
4. Manager scripts — use for tone and structure, but do not treat outdated prices in old scripts as current.

If two sources conflict, use the newest approved policy document.
If the conflict cannot be resolved, transfer to a manager and do not guess.
Why it mattersWithout a defined source of truth, the agent may give contradictory or outdated answers. Source priority rules ensure the agent always uses the most reliable information available.

​
Level 3 completion checklist

Before launching an Operational Agent, make sure you have prepared:
  • a list of connected systems and their purpose;
  • agent permissions for each system, including allowed and prohibited actions;
  • communication channel rules for each active channel;
  • CRM fields, statuses, tags, notes, and next-step logic;
  • booking and scheduling rules including confirmation logic;
  • payment-related rules if payments are part of the workflow;
  • routing and escalation workflows for each request type;
  • approved knowledge sources with ownership and update frequency;
  • source priority rules for when documents conflict;
  • clear rules for what the agent can and cannot do operationally.
Level 3 turns your AI agent into part of your business workflow. If the agent should perform actions, update systems, or route requests, the operational rules must be written clearly and treated as business logic, not general guidance.