Wiring your internal systems to Claude — what's actually possible without an engineer
In brief
Most Agent Operators think connecting their internal systems to Claude requires an engineer. For the majority of use cases, it doesn't. Four levels of integration exist — and Level 2 (native connectors for Google/Microsoft) or Level 3 (Zapier) solve 80% of what you need.
Contents
Every Agent Operator hits the same wall eventually.
You've built the agent with a Claude Project, uploaded a few documents, written a solid system prompt. It works. Users are getting value. Then someone asks: "Can it look up a customer's order history?" Or: "Can it check our current inventory before answering?" Or: "Can it see the case notes from Salesforce when a customer asks a question?"
And you think: I need an engineer for that.
Sometimes you do. But less often than you think. Most Agent Operators are at Level 1 of integration when Level 2 or Level 3 would solve what they need — and they're skipping to thinking about Level 4 (which does require engineering) without realizing the middle options exist.
Here's the complete map.
The four levels of integration
Level 1: Paste or upload (no integration required)
What it is: You take the information the agent needs — a policy document, a runbook, a product catalog, a pricing sheet — and you paste it into the system prompt or upload it to the Claude Project as a file.
Works for:
- Policy documents, procedures, runbooks
- Product or service catalogs
- FAQs and knowledge base content
- Anything that changes infrequently (less than once a month)
How to set it up: Upload the document directly in your Claude Project settings. Claude can read PDFs, Word documents, plain text, and more. Or paste the content directly into the system prompt if it's short enough.
The limitation: The information is static. When the underlying source changes, you have to manually update the file in the Project. If you forget, the agent works from stale information. (See when-agents-break — stale context is failure mode #1.)
Right for: Every Agent Operator at the start. Also right for mature agents where the underlying data genuinely doesn't change much.
Level 2: Native connectors (no code required)
What it is: Claude has built-in connectors for Google Workspace (Drive, Docs, Gmail) and Microsoft 365 (SharePoint, OneDrive, Teams). When enabled, the agent can search and read files from your connected organization's Google Drive or SharePoint in real time.
Works for:
- Companies on Google Workspace or Microsoft 365
- Situations where documents change regularly but your team already maintains them in Drive/SharePoint
- Any workflow where the agent needs to reference files that your team already keeps updated
How to set it up: In the Claude for Work admin console, enable the Google Workspace or Microsoft 365 connector. Users authenticate with their work Google/Microsoft account. The agent can then access the files and folders those users have permission to see — no additional setup needed.
What the agent actually gets: The ability to search documents in Drive/SharePoint and pull relevant content into its context when answering a question. It respects the same permissions the user has — if they can't see a file, the agent can't either.
The limitation: Only works for Google Workspace and Microsoft 365. Permissions are per-user, so the agent sees what that user sees. You can't, for example, give the agent global access to all Salesforce data through this connector.
Right for: Most companies on Google Workspace or M365. This is the integration that feels like magic the first time it works. Your agent is suddenly drawing on the latest version of every document your team keeps in Drive, without any manual updates.
Level 3: Zapier or Make.com (no code, some setup time)
What it is: Zapier and Make.com are automation platforms that can connect hundreds of business tools — Salesforce, HubSpot, Jira, Notion, Airtable, Slack, and more — and let them talk to Claude without writing code.
Works for:
- CRM data (Salesforce, HubSpot) — look up customer records before answering
- Project management (Jira, Asana) — check ticket status, create tickets from agent output
- Spreadsheets and databases (Airtable, Google Sheets) — query tables, update records
- Any tool with a Zapier connector (there are thousands)
How it works:
There are two directions:
Feeding data into the agent: You create a Zapier flow that watches for a trigger (a new order, a Salesforce record update, a form submission), formats the relevant data, and sends it to Claude as part of the conversation context. When a customer service rep uses the agent, the agent automatically has that customer's latest order status from your order management system — because Zapier pulled it and formatted it.
Sending agent output to other systems: The agent produces structured output (a categorized ticket, a drafted response, a recommended action), and Zapier takes that output and creates a record in Salesforce, sends a Slack message, or updates a spreadsheet.
How to set it up: Start at zapier.com. Search for Claude AI in the app directory. Zapier has a pre-built Claude integration that lets you send text to Claude and receive a response. Connect it to whatever source system you need.
The limitation: There's some latency (Zapier flows take seconds to execute, not milliseconds). And you're building flows — not true live queries. If you need real-time bidirectional access to a database mid-conversation, Zapier isn't the right tool. But for the most common Agent Operator needs, it works well.
Right for: Agent Operators who need to connect to CRM, ticketing, or operational tools without an engineer. This is where most medium-complexity integrations live.
Level 4: MCP server (requires engineering help)
What it is: MCP stands for Model Context Protocol. It's an open standard that lets you build a custom server that gives Claude structured, live, bidirectional access to internal APIs and databases. When a user asks the agent a question, the agent can call the MCP server in real time to fetch exactly the data it needs — from your legacy ERP, your internal database, your proprietary system.
Works for:
- Real-time access to internal systems that don't have Zapier connectors
- Legacy ERP or warehouse management systems
- Proprietary databases with complex query needs
- High-volume, low-latency use cases where Zapier's speed isn't sufficient
Who builds it: A developer. This is not a no-code project. Building an MCP server requires writing server-side code, defining the tool interface, handling authentication, and deploying it somewhere. If you have an internal developer available, it's a few days of work. If you don't, it's a project that needs to be scoped and staffed.
The limitation: This is the right long-term architecture for a mature AI stack. It is not where you should start. MCP servers are powerful and flexible — but they take real engineering time to build and maintain.
Right for: When Levels 1–3 genuinely can't solve the problem, and you have engineering resources. Don't start here.
The decision framework
Four questions that tell you which level you need:
Does the data change less than once a month? → Level 1 is fine. Upload it, update it when it changes.
Is the data in Google Drive/SharePoint and your company uses Google Workspace or M365? → Level 2. Turn on the native connector. This is probably the fastest win you have available.
Does the tool have a Zapier connector? Go to zapier.com/apps and search for it. If yes, and if your use case is batch-style rather than real-time → Level 3. Build the flow.
Do you need real-time access to a proprietary internal system that has no external connector? → Level 4. Get engineering help, or scope it as a future project.
The most common mistake
Jumping straight to Level 4 because it sounds like the "right" architecture.
Level 4 is the right architecture for a mature, scaled AI stack. It is not the right starting point. Most Agent Operators who are 6–12 months into the role are still getting enormous value from Level 1 and Level 2. The move to Level 3 unlocks another round of capabilities without requiring engineering help. Level 4 is a year-two project for most companies.
The other common mistake: staying at Level 1 forever because it works, while paying the maintenance cost of manually updating documents that could be automated with Level 2.
A practical example
Here's how a logistics company might think through integration for a customer service agent:
The agent needs to answer questions about shipping status and delivery windows.
Option A (Level 1): Export daily shipping reports to a PDF, upload to the Claude Project every morning. Works, but manual. Misses real-time accuracy.
Option B (Level 2): If shipping reports are maintained as Google Sheets in Drive, connect the native Google Workspace connector. The agent can now read the current version of the sheet whenever needed. No manual updates.
Option C (Level 3): Build a Zapier flow that triggers when a Salesforce case is opened, fetches the order number from the case, looks up the shipment status in the order management system, and passes it to Claude as context. The agent now has the specific shipment status for this customer's order before the rep even types the first message.
Option D (Level 4): Build an MCP server with live access to the warehouse management system for real-time inventory and delivery window queries. Right answer if volume and latency demands require it. Significant engineering investment.
For most logistics company CS agents, Option B or C solves the real problem. Option D becomes worth considering at scale.
Try this today
For each agent you're currently running: look at the context it uses. Is it a static document? Could it be replaced with a live connection to something your team already maintains in Google Drive or Sharepoint?
If yes, turn on the native connector today. It's a 20-minute admin task and it eliminates one category of stale context failures permanently.