Limitations & Restricted Operations
Limitations define what AI Employees cannot do. Understanding these boundaries helps you know what to expect and prevents frustration when trying to use AI Employees for tasks outside their scope.
Permission Limitations
Cannot Bypass Workspace RBAC
AI Employees cannot bypass workspace role-based access control (RBAC). If a human user with a certain role cannot perform an action, neither can an AI Employee running under that context.
Example: If you're a Member (not an Admin), you cannot delete projects. Therefore, an AI Employee running under your context also cannot delete projects, even if you ask it to.
Cannot Escalate Permissions
AI Employees cannot do things that the context user cannot do. They cannot escalate their own permissions or the permissions of the user running them.
Example: A Member cannot change another user's role to Admin. An AI Employee running under a Member's context also cannot change user roles.
Connection Limitations
Cannot Access External Services Without Authenticated Connections
AI Employees cannot use external services (like Gmail or Salesforce) unless a connection has been explicitly set up and shared with them.
If a connection is missing or revoked, any skills that depend on that connection will fail. You'll need to reconnect or select a different connection to get the skill working again.
Example: If you revoke the Gmail connection, any skills that send emails will fail until you reconnect Gmail.
Cannot Access Connections Not Shared With Them
Even if a connection exists in your workspace, the AI Employee can only use it if it has been shared with them. Private connections are not automatically available to AI Employees.
Example: If you have a private Gmail connection that you haven't shared with Millie, Millie cannot use it to send emails.
Context Limitations
Cannot Act Outside Their Context
AI Employees can only access data and perform actions that the context user has permission to access. They cannot act outside the scope of that user's permissions.
In manual mode, the AI Employee runs under YOUR permissions. In autonomous mode, it runs under the permissions of the person who set up the trigger.
Example: If you set up a skill and you don't have access to Project 101, the skill cannot access Project 101 either.
Cannot Access Private Data of Other Team Members
AI Employees cannot access private workspaces, private documents, or personal data of other team members — even if other team members have access to those things.
This is a safety feature that prevents unintended data leakage.
Example: If Carol has a private workspace that you don't have access to, an AI Employee running under your context cannot access Carol's private workspace.
Can Access Private Workspaces (If Context User Has Access)
However, if YOU have access to a private workspace, the AI Employee running under your context CAN access that private workspace.
Example: If you have access to a private workspace called "Executive Team," an AI Employee running under your context can access that workspace and perform actions in it.
Data Format Limitations
Cannot Process Images, Audio, or Video
AI Employees cannot directly process image files, audio files, or video files. They can only reference metadata about these files (like the file name or size).
Example: You cannot ask an AI Employee to "analyze this image" and expect it to understand the image content. However, you can ask it to "find all images named 'logo'" and it can work with the file metadata.
Cannot Process Binary Files
Binary files (like .exe, .zip, or compiled code) are stored as links or metadata but are not parsed or analyzed by AI Employees.
Workspace Management Restrictions
Cannot Delete Workspaces
AI Employees cannot delete workspaces, even if they're running under an Admin's context. This is a safety restriction to prevent accidental workspace deletion.
Cannot Remove Team Members
AI Employees cannot remove users from workspaces or the team, even if they're running under an Admin's context.
Cannot Change User Roles or Permissions
AI Employees cannot modify user roles (like changing someone from Member to Admin) or change permission settings, even if they're running under an Admin's context.
Cannot Modify Workspace Settings
AI Employees cannot change workspace settings like workspace name, description, or configuration, even if they're running under an Admin's context.
These restrictions exist to prevent accidental or malicious changes to your workspace structure.
Self-Permission Restrictions
Cannot Modify Their Own Permissions
AI Employees cannot modify their own permissions or role assignments. Only workspace Admins can change what an AI Employee can do.
This prevents AI Employees from escalating their own access.
Cross-Workspace Restrictions
Cannot Access Multiple Workspaces Unless Configured
AI Employees cannot automatically access multiple workspaces. They can only access the workspace(es) they're deployed to.
If you want an AI Employee to access multiple workspaces, you must explicitly configure it for each workspace.
Example: If you add Millie to Workspace A, she cannot automatically access Workspace B. You would need to add her to Workspace B separately.
Motion Trigger Scope Limitation
When using Motion-based triggers (like "when a new task is created"), the AI Employee can only see and act within the specific workspace where the trigger is configured.
However, with other trigger types (like Gmail or Salesforce triggers), this workspace boundary doesn't apply the same way. The AI Employee can act based on the context user's permissions across different systems.
Example: If you set up a Motion trigger to "update tasks in Project A," the skill can only see and update tasks in Project A. But if you set up a Gmail trigger to "create a task when an email arrives," the skill can create tasks based on what you have access to.
Publishing & Sharing Restrictions
Cannot Publish Documents Without Approval
AI Employees cannot publish Motion documents or share external links without explicit approval. This prevents unintended data exposure.
Cannot Share Documents Publicly
AI Employees cannot make documents publicly available or share them with people outside your workspace without explicit configuration.
Skill Execution Restrictions
Cannot Sync Blocks Across Multiple Documents
AI Employees cannot sync blocks (like task lists or tables) across multiple documents. If you copy a block from one document to another, the copies are independent and don't stay in sync.
Autonomous Skills Cannot Run Outside Defined Scope
Autonomous skills are limited to the triggers and permissions you configured when you set them up. They cannot run outside the defined scope, even if you later gain access to new workspaces or data.
Example: If you set up a skill to run "every Monday at 9 AM in Workspace A," the skill will only run in Workspace A on Mondays. It won't automatically expand to other workspaces.
Approval Restrictions (Skills Only)
AI Skills Do Not Provide Approvals Within Skill Execution
This is an important distinction: AI skills do NOT have built-in approval mechanisms within the skill execution. Write actions execute based on the skill configuration you set up.
Approvals happen at setup time (when you configure the skill), not at execution time (each time the skill runs).
Example: You set up a skill to automatically update CRM records after sales meetings. You approve this setup once. Every time a sales meeting ends, the skill automatically updates the CRM without asking for approval each time.
Last updated
Was this helpful?