Forward deployed engineering, Part 5: Enterprise integrations, APIs, connectors and identity

In Part 4 we made Acme Consumer Brands’ documents ready for retrieval: parsed, chunked, indexed and checked. But documents are only one of the systems the agent has to reach. The order lines are in Databricks, the campaign spend is in BigQuery, the supply agreements are in SharePoint, the spec sheets are in Google Drive, supplier certificates are in Box, and the live order status comes from an ERP system that IT exposes through a REST API.

Each of those is an integration: a connection between two systems that lets one read from or act on the other. In my experience, integrations take more of an FDE’s calendar than any other part of the build. Every system has its own API, its own way of proving who you are, and its own way of failing at the worst moment.

This part starts from a single API call and builds up to managed connectors, identity standards, and MCP servers as the layer that ties them together.

If you prefer to watch first, here is the heart of this part as a short animated explainer.

Video: how an agent reaches the customer's systems through APIs, connectors, identity and MCP, in three minutes. The narration is a synthetic voice; the script and animation are mine.

Where does this show up in an FDE job description?

Google Cloud’s GenAI forward deployed engineer postings describe the integration work directly:

“Architect and code the connective tissue between Google’s AI products and customer’s live infrastructure, including APIs, legacy data silos, and security perimeters.”
“Serve as a developer for complex AI applications, transitioning from rapid prototypes to production-grade agentic workflows (e.g., multi-agent systems, MCP servers).”

A Google Cloud FDE role on the enterprise context layer asks the same thing from another angle: “Build custom skills or integrations to assist customers, and document successful processes for future standardization”, with “experience with agentic architectures, tool usage, or the Model Context Protocol (MCP)” as a plus.

What are we connecting at Acme?

Here is the estate the FDE inherits once the design from Part 3 is agreed:

the systems an FDE has to connect at Acme: Gemini Enterprise in the middle, document stores on the left reached through connectors, data platforms and a REST API on the right reached through MCP, and the identity provider above everything

Before going system by system, a few terms that every integration uses:

API (application programming interface). A defined way for one program to ask another for data or an action.
Endpoint. One address in an API, such as /v2/orders.
Authentication. Proving who is calling. Authorisation is deciding what that caller may do. They are different checks, and errors usually tell you which one failed.
Connector. A ready-made integration supplied by a platform, so that you configure it instead of writing code.
Identity provider (IdP). The system that signs people in and knows which groups they belong to. At Acme, that is Microsoft Entra ID.

How does a REST API call work?

Most enterprise APIs follow the REST style (representational state transfer): every thing the API knows about, such as an order, has a URL, and you act on it with standard HTTP methods. GET reads, POST creates, PUT or PATCH updates and DELETE removes. Data travels as JSON (a plain-text format of keys and values).

This is one call to Acme’s ERP, with the four parts that matter:

the anatomy of a REST call to Acme's ERP: the method and path with query parameters, a bearer token in the Authorization header, a status code in the response, and a page token for the next page of results

The status code in the response is the first thing to read when something breaks. The ones I meet most on engagements:

200 OK, and 201 Created.
400 Bad Request: your request is malformed. Check the body and the parameters.
401 Unauthorized: authentication failed. The token is missing, expired or for the wrong audience.
403 Forbidden: you are authenticated, but this identity is not allowed to do this.
404 Not Found: wrong path, or the object does not exist. Some APIs also return 404 to hide objects you may not see.
429 Too Many Requests: you hit a rate limit (a cap on calls per period). Wait, ideally for the time in the Retry-After header, then retry.
5xx: the server failed. Retry with exponential backoff (waiting longer after each failure), and only retry calls that are safe to repeat.

Two more ideas save a lot of pain. Pagination means large results arrive one page at a time, so your code must follow the page token until it runs out; an agent that reads only page one gives confident, incomplete answers. Idempotency means a call can be repeated without doing the work twice. Reads are naturally idempotent; for writes, many APIs accept an idempotency key so that a retry does not create a second order.

How does a program prove who it is?

There are three common ways, from simplest to most appropriate for agents:

API key. A long secret string sent with every call. Simple, but it identifies an application, not a person, and it is hard to rotate safely. Avoid it for anything sensitive.
Service account or the OAuth 2.0 client credentials grant. The application gets a short-lived access token for itself. Every call has the application’s permissions.
OAuth 2.0 on behalf of the user. The user signs in once and consents, and the application receives a token that represents that user. The source system then applies the user’s own permissions.

The token in each case is usually a bearer token: whoever holds it is let in, which is why tokens must never appear in logs or prompts. The difference between the last two options is the most important integration decision in an agent project:

two ways a program can call an API: as itself with a service account token, which sees everything the account can see, or on behalf of the signed-in user with the user's token, which sees only what that user can see

If the data differs by person, and in an enterprise it almost always does, call as the user. The agents series, Part 7 builds this flow step by step, including how to keep the token away from the model.

What are connectors and data stores in Gemini Enterprise?

Writing an integration for SharePoint, Box and Google Drive from scratch would take weeks. Gemini Enterprise provides them as connectors. In its documentation, data store and connector mean the same thing: a configured link to one source. Each source has entities (Jira, for example, has issues, attachments, comments and worklogs), and Gemini Enterprise creates a separate data store per entity.

As of October 2026, the generally available connectors include Box, Confluence, Dropbox, GitHub, Google Drive, Jira, Microsoft OneDrive, Outlook, SharePoint, Teams, ServiceNow and Slack, among others. A much longer list, including a Custom MCP Server connector, is in public Preview.

Every connector reaches its data in one of two ways, and some support both:

the two ways a Gemini Enterprise connector reaches data: federation sends each question to the source system live, while ingestion copies content and its permissions into the Gemini Enterprise index on a sync schedule

Data federation. Gemini Enterprise sends the query to the source system at question time. Nothing is copied, so there is no storage or sync to manage, but search quality may be lower. The documentation also warns that the query text, which may include parts of the conversation, is sent to the third-party system.
Data ingestion (indexing). Content is copied into the Gemini Enterprise index on a schedule. Search quality improves, at the cost of storage and a delay between a change in the source and its appearance in answers.

Ingestion runs on syncs. A full sync captures everything, including deletions. An incremental sync captures only additions and updates since the last run, by default every three hours, and does not pick up deletions or identity data. Identity data (users and groups) has its own schedule, from every 30 minutes to every 7 days. When a user says “I removed that file yesterday and the agent still quotes it”, the sync schedule is the first thing I check.

Connectors can also offer actions (operations that change something, such as creating a ticket), and in Gemini Enterprise the MCP word tools and the word actions mean the same thing.

How do identity providers fit in?

Every document in SharePoint has an access control list (ACL), a list of the users and groups allowed to open it. Those entries refer to identities in Entra ID. For Gemini Enterprise to respect them, it has to know which Entra ID user is asking and which groups that user belongs to. Three open standards make that possible:

three identity standards an FDE meets in every enterprise: SAML 2.0 and OpenID Connect sign a user in, and SCIM keeps the list of users and groups in step between systems

SAML 2.0 (Security Assertion Markup Language). The identity provider signs an XML document, an assertion, saying who the user is, and the browser carries it to the application. This is how most older enterprise applications do single sign-on (SSO), signing in once for many applications.
OpenID Connect (OIDC). An identity layer on top of OAuth 2.0. The identity provider issues a signed JSON ID token describing the user. It does the same job as SAML for newer web and mobile applications.
SCIM 2.0 (System for Cross-domain Identity Management). A REST API for provisioning: the identity provider pushes users and groups to other systems when they change, so that a leaver loses access everywhere without anyone raising a ticket.

For Gemini Enterprise, the documentation recommends Google Identity for new setups, and Google Identity is required for Google Workspace sources. A third-party identity provider such as Entra ID, Okta or AD FS works if it supports OIDC or SAML 2.0. One exception shaped Acme’s design: Microsoft 365 sources that use data ingestion, such as SharePoint, OneDrive and Outlook, require Microsoft Entra ID with Workforce Identity Federation (Google Cloud’s way of letting people sign in with an external identity provider without a Google account). SCIM provisioning for Workforce Identity Federation applies only to Gemini Enterprise and Looker (Preview for Looker), and the documentation notes that SCIM is push-based: if the connection from the identity provider breaks silently, group data can go stale.

With identity in place, the permission check happens on every question:

how permissions survive into an answer: the planner signs in through the identity provider, Gemini Enterprise knows her groups, searches the index, drops the document her groups cannot read, and answers only from what she is allowed to see

For Google Workspace sources the documentation states the principle plainly: a user can only view and ground responses on information they can already access in the source. That property only holds if the identity setup is right.

Why are MCP servers becoming the integration layer?

Connectors cover popular products. They do not cover Acme’s ERP, a supplier portal or a twenty-year-old warehouse system. For those, the integration you write should be reusable by every agent, not buried inside one. That is what the Model Context Protocol (MCP) provides.

MCP is an open protocol for connecting AI applications to tools and data. Its specification describes three roles: a host (the application the user works in, such as Gemini Enterprise), clients (connectors inside the host) and servers (services that expose capabilities). Servers offer tools (actions the model can ask to run), resources (data to read) and prompts (templates). Messages use JSON-RPC 2.0, and remote servers use the Streamable HTTP transport. The latest specification revision is dated 28 July 2026, and its authorisation section makes a protected MCP server an OAuth 2.1 resource server that must publish Protected Resource Metadata (RFC 9728) so clients can discover where to get a token.

why MCP helps: without a shared protocol every agent needs custom code for every system, twelve integrations for three agents and four systems; with MCP each system is wrapped once as a server and each agent speaks MCP once, seven pieces in total

Without a shared protocol, every agent needs custom code for every system. With MCP, each system is wrapped once as a server and any MCP-capable host can use it: Gemini Enterprise, an ADK agent, or a developer’s IDE.

Gemini Enterprise can register your own server as a Custom MCP Server data store (public Preview as of October 2026). The documentation lists the rules that matter in the field:

Only the Streamable HTTP transport is supported; the older server-sent events (SSE) transport is not.
Public and private servers both need a TLS certificate from a publicly trusted certificate authority. Self-signed certificates are rejected.
Keep enabled actions to 100 or fewer per data store.
For per-user access, register Gemini Enterprise as an OAuth client with your identity provider, using the redirect URL given in the documentation. For a server on Cloud Run, Gemini Enterprise sends a Google-signed ID token for IAM authentication.

What does a real integration look like end to end?

My post on wiring Gemini Enterprise to Databricks Genie is a worked example of everything in this part. In short:

Identity first. Every query runs in Databricks as the user who asked, through an OAuth on-behalf-of flow, so Unity Catalog applies the same permissions it would in a notebook.
Four ways to connect, one back end. A Cloud Run gateway calling Databricks REST APIs, the same gateway calling Databricks managed MCP servers, the managed MCP servers registered directly in Gemini Enterprise, or an A2A agent at the front door. All four reach the same governed data.
The protocol choice is about the front door. MCP connects an agent to tools; A2A connects agents to each other. The Databricks side stayed on MCP or REST in every option.
The gotchas were integration gotchas. Genie answers asynchronously, so the caller must poll. A confidential OAuth client cannot use PKCE and a client secret together. A stopped SQL warehouse adds a cold start to the first question.

four ways to connect Gemini Enterprise to Databricks Genie, from the worked example: a gateway calling REST, a gateway calling managed MCP, managed MCP registered directly, or an A2A agent at the front door; all four reach the same governed data as the user who asked

The Genie post explains when to choose each option and what each one costs to run.

For Acme, the integration plan came out like this:

Acme's integration plan, one row per system: the documents use Gemini Enterprise connectors, Databricks uses managed MCP with the user's token, and the ERP's REST API is wrapped in a small custom MCP server

What should I ask in week one?

I send this list to the customer’s platform and security teams before the first integration workshop. Every unanswered line is a risk to the plan.

INTEGRATION QUESTIONNAIRE: one copy per system

System and owner
  - Name, version, hosting (SaaS, cloud, on premises)
  - Business owner and technical owner (names, not teams)

Access
  - API type (REST, GraphQL, SOAP, database, files) and documentation link
  - Is there a Gemini Enterprise connector or a vendor MCP server already?
  - Federation, ingestion, or both? Sync frequency the business accepts

Identity
  - Identity provider for this system (Entra ID, Okta, Google, other)
  - Call as the user (OAuth) or as a service identity? Why?
  - Which scopes or roles are needed? Who approves them, and how long does it take?
  - Are permissions set per document or row? Are they in the identity provider's groups?

Limits and failure
  - Rate limits, page sizes, payload limits, maintenance windows
  - Test environment with realistic data? Test users in each permission group?

Network and compliance
  - Public endpoint, private connectivity, or allowlisted IPs only?
  - Data residency, retention, and what may leave the system in a query

Try it

This is a tiny MCP server that wraps a fake version of Acme’s ERP orders API. It needs Python 3.11 or later and the official MCP Python SDK (pip install "mcp[cli]"). Save it as server.py:

"""A tiny MCP server that wraps Acme's (fake) ERP orders API."""
from mcp.server import MCPServer

mcp = MCPServer("acme-erp")

# Stand-in for the real REST call. In production this function would call
# GET /v2/orders with the user's token and follow next_page_token.
FAKE_ORDERS = [
    {"id": "SO-88412", "retailer": "northmart", "otif": False, "value": 41200},
    {"id": "SO-88413", "retailer": "northmart", "otif": True, "value": 18950},
    {"id": "SO-88501", "retailer": "freshway", "otif": False, "value": 7300},
]

@mcp.tool()
def late_orders(retailer: str, limit: int = 20) -> list[dict]:
    """List orders for one retailer that were not delivered on time and in full.

    Use this for questions about late or short deliveries. Read-only.
    retailer: lower-case retailer code, for example "northmart".
    """
    rows = [o for o in FAKE_ORDERS if o["retailer"] == retailer and not o["otif"]]
    return rows[: max(1, min(limit, 100))]

Run it over Streamable HTTP with mcp run server.py --transport streamable-http, then call it from a second terminal:

import asyncio

from mcp import Client

async def main() -> None:
    async with Client("http://localhost:8000/mcp") as client:
        tools = await client.list_tools()
        print([t.name for t in tools.tools])
        result = await client.call_tool("late_orders", {"retailer": "northmart"})
        print(result.structured_content)

asyncio.run(main())

You should see the tool name and one late Northmart order. Then try three things:

Notice that the type hints and the docstring became the tool’s schema and description. The description is the tool’s contract with the model, exactly as in agents series Part 2.
Call it with "limit": 5000. The server caps it at 100. Limits belong in the server, not in a prompt.
Add a second tool for one retailer’s on-time rate. Then ask yourself how the server would know which user is calling, which is where OAuth comes in before this goes anywhere near production.

What can go wrong

Integrating as a service account by default. It is quicker in week one and a security finding in week six. Decide per system, and write the decision down.
Ignoring pagination and rate limits. The agent answers from page one, or a busy morning produces a burst of 429 errors. Test with production-sized data.
Forgetting sync delays. Users expect yesterday’s change in today’s answer. Agree the sync schedule with the business, and show document dates in citations.
Assuming groups are in the identity provider. Some systems keep their own local groups. If an ACL refers to a group the identity provider does not know, nobody can see the document, or everybody can.
Building a connector that already exists. Check the Gemini Enterprise connector list and the vendor’s own MCP servers before writing code.
Treating Preview as production. The Custom MCP Server data store is in Preview. Pin the configuration, tell the customer, and keep a fallback.

What I would do now

Draw the estate diagram for your engagement, one box per system, and label every line with its integration pattern.
Send the integration questionnaire to every system owner in week one.
Use a managed connector wherever one exists, and decide federation or ingestion per source.
Settle identity before writing code: identity provider, on-behalf-of or service identity, and who approves scopes.
Wrap anything without a connector as a small MCP server with narrow, read-only tools first.

What did we learn?

An integration is a connection that lets one system read from or act on another, and each one brings its own API, authentication and ways of failing.
The status code of a REST call is the first thing to read when something breaks, and pagination and idempotency prevent incomplete answers and duplicate writes.
If the data differs by person, the agent should call the source system on behalf of the signed-in user rather than as a service account.
Gemini Enterprise connectors reach data by federation or by ingestion, and ingestion depends on sync schedules for both content and identity data.
SAML 2.0 and OpenID Connect sign users in and SCIM keeps users and groups in step, and permissions only survive into answers if that setup is right.
MCP lets each system be wrapped once as a server that any MCP-capable host can use, which is why it is becoming the integration layer.

What comes next?

With data ready and systems connected, the next choice is how to build the agent itself. In Part 6: Agent frameworks compared, we put ADK, LangGraph, CrewAI and AutoGen side by side, look at the ReAct, reflection, supervisor and graph patterns, build the same small task in two frameworks, and see how A2A and MCP let agents from different frameworks work together.

Sources

Opinions are my own. Every fact in this post comes from the public documentation linked above. Acme Consumer Brands and its data are fictional.