Overview

Moveworks is the enterprise AI harness that connects your assistant to the business systems and content your organization relies on. It offers several tool frameworks, each optimized for a different kind of connection. Choosing the right framework for each use case leads to agents that are more reliable, more secure, and more cost-effective.

This page explains the tool frameworks and when to use each.

Enterprise Search

Purpose: find content anywhere. Enterprise Search hybridizes indexed and live search to deliver personalized results at scale.

• Indexed search mirrors your organization’s content into a managed AI search index for fast, ranked retrieval across knowledge base articles, PDFs, documents, presentations, and more. It scales to tens of millions of documents per connector.
• Live search queries a connector’s search API in real time, so there is no staleness and no practical scale ceiling. It works well for fast-moving content such as Slack threads.

Moveworks builds and maintains a large library of built-in connectors for many common systems, so you can index and search popular knowledge and content sources out of the box, without building an integration yourself.

Moveworks also manages multilingual document embedding, authoritative source ranking, and search personalization, so you don’t have to decide which system is the more authoritative source for a given query.

When you need a source that isn’t already covered, you can build a custom connector through Content Gateway, which handles most of the effort, including the ingestion infrastructure, crawling, content diffing, chunking, indexing, retrieval, and ranking. You define the API endpoints, map content to Moveworks’ canonical types, and describe the permission model.

Why Enterprise Search over MCP or Plugins for search? MCP and Plugins can technically fetch data, but Enterprise Search is purpose-built for retrieval and does it far better at scale. It hybridizes indexed and live search to return relevant results across millions of documents, applies authoritative source ranking and personalization so the best answer surfaces first, honors each system’s permissions, and stays fresh as content changes. Moveworks manages the ranking, embedding, and relevance tuning for you, so search quality holds up across many sources without per-connector effort. When the goal is to find and surface information rather than act on it, Enterprise Search is the right tool.

Use it for: searching content and files, such as ServiceNow knowledge base articles and attachments.

MCP

Purpose: quickly connect to productivity apps for read operations and reversible actions. MCP shines for everyday productivity use cases, where employees want to check a status, look something up, or make a quick update in the tools they already use, all without leaving the assistant.

The Model Context Protocol (MCP) has three parts:

• Host: the AI harness where users interact with AI (for example, Moveworks).
• Servers: the applications you read from or take actions in (for example, Linear, GitHub, Notion, or Slack).
• Client: the connection between the host and the servers.

MCP is a great fit for read operations and reversible operations, such as moving a Linear issue back to in-progress or changing its due date. Because these operations are low-risk and easy to undo, MCP’s speed of connection matters more than heavy guardrails, which makes it ideal for quickly reaching productivity apps. Moveworks can connect to any MCP server, whether a custom server you build or a built-in connector such as Linear, GitHub, Notion, or Slack, so you might create a Linear issue, look up a GitHub pull request, or fetch a Slack thread.

Considerations: standard MCP is a fast way to connect, but on its own it offers limited administrative visibility and control. Because the set of tools can vary from user to user, an administrator may not know which tools a given employee can see, and there is little built-in structure for blocking risky servers or disabling sensitive or high-volume operations. Standard MCP clients can also struggle to move large result sets between tools reliably, because values are often copied one record at a time and can be truncated or dropped as the context window fills.

MCP Workspace is built to close these gaps. Administrators can review sanctioned servers, add custom authentication, see every tool a server exposes, and block tools they don’t want employees to use. Its runtime client also moves data between tools programmatically, for example passing thousands of records from an identity system into an HR system, instead of copying values one at a time. This keeps large operations fast and accurate.

For example, with the built-in GitHub connector a user can ask, “What are my open pull requests in GitHub, and which have requested changes?” and MCP retrieves the answer in real time.

Where MCP falls short: MCP is less suited to high-stakes, multi-step write workflows. When a task must follow a strict sequence of steps, enforce business rules that aren’t in the API, resolve large dependent dropdowns, or complete without partial failures, a model working through raw MCP tools can guess, skip a required step, or submit data that a person never could. For example, an irreversible action like issuing a refund or submitting a purchase order, or a bulk update that must apply to every matching record, needs stronger guarantees than MCP provides on its own. For those cases, reach for a plugin instead.

Use it for: live fetches against productivity apps and reversible operations, using built-in connectors like Linear, GitHub, Notion, and Slack.

Plugins

Purpose: reliable, agent-safe write actions against enterprise applications. Plugins primarily interact with REST APIs, which is how they deliver dependable write actions against apps like Workday, Salesforce, and SAP.

Automating an enterprise app is more involved than connecting a model to a single API. To automate a task, you often have to turn an entire web app into a tool, and web apps carry constraints that a raw API call doesn’t capture:

• Ordered steps. An SAP intake form or a ServiceNow catalog item expects fields to be completed in a specific sequence, and skipping steps can break the workflow.
• Hidden business rules. Rules that live in the browser, such as ServiceNow client scripts, may not be enforced by the underlying API, so an agent can submit data that a person filling out the form never could.
• Dependent pick lists. Dropdowns can have thousands of options, and the order you fill fields in changes which options are valid. Setting the country to the United States rather than Canada, for example, changes the valid set of states.

Without structure, a model tends to guess and retry until something works. That behavior can silently skip a required compliance step, ignore a business rule when a related field changes (such as an invoice limit that stops applying once the currency changes), and generate many failed tool calls. Beyond the poor experience, those failed calls waste tokens, add latency, and can even overwhelm a production system that wasn’t designed for that volume.

Plugins solve this with the Agentic Automation Engine:

• Slot resolvers handle changing dropdowns with thousands of options.
• Policy validators capture and enforce the business rules that would otherwise be hidden in the browser.
• Action orchestrator reproduces the exact sequence of steps a web app expects, so multi-step processes complete in the right order every time.

There are three ways to build on the Agentic Automation Engine:

• Plugin Workspace: build agent-safe write actions directly, with deterministic validation, sequential execution, and dropdown handling.
• Catalog Interpreter: turn ServiceNow client-side validations into an agentic experience that checks eligibility and fills fields in the correct order.
• Ticket Gateway: bring service management, triage, and ticket experiences to any ticketing system, such as Asana, Jira, or Linear, not just ServiceNow ITSM.

Use it for: reliable write actions, from straightforward requests to multi-step processes with real business logic. For example:

• New-hire onboarding that provisions accounts, orders hardware, and routes the right approvals in the correct order.
• Expense and invoice submission where policy limits must hold even when a related field changes, such as the currency or expense category.
• Purchase orders and procurement with dependent fields like vendor, purchase code, and cost center that determine which options are valid.
• Complex catalog items and record producers in ServiceNow that rely on client-side eligibility checks and conditionally required fields.
• HR and finance transactions in systems like Workday or SAP, such as submitting a job requisition or a supplier record through a multi-screen intake form.

Simpler actions work too, such as submitting time off or requesting a single piece of hardware.

Agent-to-Agent (A2A)

Purpose: connect Moveworks to other agents and existing AI investments, such as a managed agent in Claude, an ADK agent in Gemini Enterprise, a GPT in OpenAI, or a Copilot in Copilot Studio.

Agents that support A2A expose an Agent Card, and Moveworks calls them through the A2A protocol.

Not every AI application publishes an Agent Card. For applications that don’t, connect them through plugins instead.

Use it for: more open-ended, creative tasks that are best delegated to an agent with more latitude. A2A allows more variability than the other frameworks, so reserve it for cases where that flexibility is an advantage. See Connect to other AI Agents & Applications for a walkthrough.

Conversations API

The frameworks above describe how Moveworks connects out to your systems. The Conversations API is the reverse: it lets another agent or application call Moveworks as a tool.

Instead of Moveworks calling a tool, you expose Moveworks itself to another framework, such as a managed agent, a custom application, or another AI platform, so it can access your Moveworks assistant’s capabilities. This pairs naturally with Agent-to-Agent: A2A is how Moveworks calls other agents, and the Conversations API is how other systems call Moveworks.

Use it for: making Moveworks available as a tool or agent inside another AI framework. See the Conversations API reference to get started.

Choosing the Right Framework

Match the framework to the kind of work you need to do. As a rule of thumb, use Enterprise Search to find information, MCP to read and take reversible actions in productivity apps, Plugins for reliable write actions that must respect business rules, Agent-to-Agent to hand off open-ended work to another agent, and the Conversations API to make Moveworks available to another system as a tool.