The pattern we use to put agents on enterprise data

After several of these builds the architecture has settled into a shape. This is the shape, and the reasoning behind each part, so you can push back on it intelligently.

SAP / warehouse / SQL Server
        │  (extract tool of record, timestamp-delta merge)
        ▼
    BigQuery raw tables
        │
        ▼
    BigQuery curated views   ← business rules live here
        │
        ▼
    MCP Toolbox on Cloud Run ← fixed, parameterised tools
        │
        ▼
    Vertex AI Agent Engine   ← runtime SA has NO BigQuery access
        │
        ▼
    Gemini Enterprise        ← the surface users see

Business rules go in views, not prompts

Which MRP elements count as demand, whether inspection stock is usable, how transit time is added to lead time — these are decisions. They belong in SQL that a data engineer can read, diff and test, not in a system instruction that changes meaning when the model version changes. The agent's job is to pick the right view and narrate what it returns.

MCP Toolbox gives you a fixed surface

The toolbox exposes named tools with typed parameters. The agent cannot compose arbitrary SQL. That is the point: it turns "the agent might query anything" into "the agent can call these nineteen things", which is a sentence a security reviewer can work with. It also makes the tool list the contract between the data team and the agent team.

The runtime has no data access

The service account the agent runs as gets run.invoker on the toolbox and secretAccessor for what it needs. Nothing else. If the agent is compromised or simply confused, the blast radius is the toolbox's read-only view set. This is the single design choice that most shortens the security conversation.

Things that bite

• Deploy output must state which data project it is pointed at. We watched a silent revert take a test suite from 25/25 to 6/25 because a config value pointed at the wrong dataset.
• Row caps are your cost control if byte caps aren't supported by your toolbox version. Know which one you have.
• Pin the model in deployment config and treat a model change as a release with a full regression run. Do not let it float.
• Staging IAM can be broad. Production IAM gets narrowed before go-live, and your own access comes off at handover.

All insights