Context Gravity: The Hidden Cost of an AI Platform

Context Gravity and the Hidden Cost of Choosing an AI Platform

The hardest part of switching an enterprise AI platform is usually not changing the model endpoint. It is moving the context and operating system around it.

Data connections, permissions, tool contracts, agent identities, memory, evaluations, traces, workflow history, approval rules, incident records, and team habits accumulate inside a platform. Together they create context gravity: the pull that makes nearby work easier and migration more expensive.

This is a Venture Step working theory, not a measured law. It is useful because it redirects platform evaluation away from a temporary model leaderboard and toward the assets a company will have to operate and eventually move.

The model is the most visible layer

Model comparisons are easy to discuss. A team can run prompts through several APIs and compare quality, latency, price, context window, and modality. A new release can make one provider look decisively better for a month.

Enterprise workflows accumulate much more than prompts.

A production agent needs access to customer records, documents, messages, and databases. It needs an identity and authorization policy. It calls tools through contracts. It may store session history and long-term memory. It is evaluated against cases the business considers important. It produces traces, alerts, incident history, and user corrections. People learn how to supervise it.

flowchart TB
    A["Model endpoint"] --> B["Agent logic"]
    B --> C["Data and retrieval"]
    B --> D["Identity and permissions"]
    B --> E["Tools and other agents"]
    B --> F["Memory and sessions"]
    B --> G["Evaluation and observability"]
    B --> H["Approvals and recovery"]
    C --> I["Team habits and operating history"]
    D --> I
    E --> I
    F --> I
    G --> I
    H --> I

The model is replaceable only to the extent that the surrounding layers can move with it.

The more valuable the workflow becomes, the more evidence and policy it tends to accumulate. Success can increase switching cost.

Dalton's E113 trial showed context gravity in miniature

In episode 113, Dalton Anderson tried Gemini Enterprise before recording his Google Cloud Next reaction.

The app found enough Workspace information to recognize travel plans, recurring news activity, and a podcast scheduling thread. It suggested a travel agent and a podcast-production agent. That was context creating immediate product value.

The same test showed the limit. Much of Dalton's working material lived in a private codebase or other systems. He did not want to expose a production environment on a podcast. The platform could not use context it did not have or was not authorized to see.

The test also became entangled with product packaging and rate limits. The issue was not merely whether Gemini could interpret text. Usefulness depended on the subscription boundary, connected environment, available quota, and location of the work.

That is context gravity before enterprise scale.

Seven assets create the pull

Data and semantic meaning

A connector can expose a table without explaining which field is authoritative, which definition changed, or which record may be updated. Enterprises build semantic layers, retrieval indexes, data products, and quality rules so the agent receives usable context.

Those assets may rely on one cloud's catalog, storage, database, identity, and monitoring. Moving the raw data is not the same as moving its operating meaning.

Identity and policy

An agent identity acquires roles, scopes, trust relationships, credential paths, and audit history. Tool gateways enforce rules around it. Approval systems recognize it.

Another platform may support the same principle while using different policy objects and enforcement points. The intent can move more easily than the implementation.

Tools and integrations

Model Context Protocol can standardize how tools, resources, and prompts are exposed. That can reduce custom integration work.

The tool behind the schema still depends on authentication, network access, data rules, error handling, rate limits, versioning, and support. A portable tool description does not guarantee a portable production connection.

Memory and sessions

An agent may carry conversation history, user preferences, summaries, retrieved artifacts, and long-running task state. Some of that material is useful precisely because it has accumulated over time.

Migration needs rules for export, privacy, retention, correction, schema, provenance, and deletion. A team may decide that certain memory should not move at all.

Evaluations

A serious agent develops an evaluation set based on real cases, edge conditions, policy failures, and past incidents. The execution harness records scores, traces, and regression history.

The test cases may be portable. The exact instrumentation, grading, dataset bindings, and comparison history may not be.

Operating evidence

Logs, traces, cost history, user feedback, incidents, and recovery exercises teach the team how the system behaves. This evidence informs thresholds and supervision.

A new platform begins without that local operating history even if its model is stronger.

Human routines

People learn where to inspect a trace, how to approve a task, what an alert means, which failure requires escalation, and how to correct context. Those habits have migration cost because training and confidence must be rebuilt.

Context gravity is partly technical and partly organizational.

Open protocols reduce friction without removing gravity

A2A and MCP are important because they create shared interaction contracts.

MCP uses a client-host-server architecture to expose tools, resources, and prompts. A2A lets independent agents publish Agent Cards, advertise capabilities, exchange messages, and manage stateful tasks. AWS documents both protocols in Bedrock AgentCore, while Google supports them across its agent stack.

This is meaningful portability evidence. A tool or remote agent does not have to be written exclusively for one proprietary call pattern.

The protocols do not standardize every surrounding concern. A2A authorization remains implementation-specific. Identity systems, policy languages, secrets, memory stores, evaluation services, observability, deployment, billing, and data residency can still differ.

Interoperability is therefore a gradient.

The table is a decision lens, not a universal score. Architecture choices can raise or lower portability.

Staying is not always the conservative choice

Dalton's episode advice was to stay with the platform already in use rather than switch whenever another provider releases an attractive feature. The instinct is sensible when the difference is temporary and the migration surface is large.

Staying can also carry cost.

A platform may lack a required security control, region, contract, model, tool, or service level. Prices may become materially worse. The vendor may deprecate a dependency. The organization may discover that its architecture is too closed to support a strategic partner or acquisition.

Context gravity should make the switching decision explicit, not predetermined.

When switching may be justified

A migration becomes more credible when the current platform fails a durable requirement rather than a short-lived preference.

Examples include a regulatory or data-residency need, unacceptable incident history, missing identity or audit controls, a cost difference that survives full-workflow analysis, a required model or modality unavailable under acceptable terms, or a strategic need to consolidate infrastructure.

The team should calculate the cost of moving data, connectors, policies, evaluations, memory, histories, user interfaces, support processes, and skills. It should also calculate the cost of remaining, including opportunity cost and future dependency.

A staged migration can reduce risk. New agents may use the target platform while existing workflows remain in place. A shared gateway can normalize tool access. Evaluation cases can be moved before production traffic. A2A can let an agent on one platform delegate to another during transition.

When staying may be rational

Staying is rational when the platform meets the durable requirements, the apparent competitor advantage is likely to narrow, and the accumulated context produces real value.

The case is stronger when the company can still swap models, expose tools through open contracts, export core records, preserve evaluations outside the vendor, and maintain clear ownership of data and policy.

That is not passive lock-in. It is an intentional platform position with exit options.

Build a context-asset map before purchase

Before selecting a platform, map the assets the first production workflow will create.

Identify the authoritative data, semantic definitions, identities, tools, memory, session state, evaluations, logs, incident records, approval routes, and user-facing surfaces. For each, record where it lives, who owns it, how it is exported, which open contract applies, what would need to be rebuilt, and what can be retired instead of moved.

Run an exit exercise during the pilot. Export the agent definition and evaluation set. Reconnect one tool from a second environment. Confirm how identity and logs would be mapped. Determine whether memory can be separated from the application.

The goal is not perfect portability. That can impose its own cost and force every platform into the smallest common feature set. The goal is knowing which advantages create dependency before the dependency becomes invisible.

The strategic question

An enterprise AI platform is not only where a model runs. It is where context becomes operational.

Google Cloud's advantage, if it earns one, will not come simply from having a strong Gemini release. It will come from connecting infrastructure, data, Workspace, identity, security, agents, and employee workflows in a way customers can operate. The same logic applies to Microsoft, AWS, OpenAI, Anthropic, and future platforms through different asset combinations.

Context gravity explains why a temporary model lead may not justify a migration. It also explains why a platform's governance and export design deserve attention before the first successful agent makes switching harder.

Choose the ecosystem with the full lifecycle in view. Then keep the most important context assets legible enough to move when a durable reason appears.

Continue the series

The Agent Platform explainer shows where Google's context assets live. The governance Guide explains how to keep identities, permissions, tools, evidence, and recovery under control. Episode 65 goes deeper on A2A and MCP as interoperability mechanisms.

Sources and disclosure

Google's current architecture comes from the Agent Platform launch, agents overview, and Next 2026 recap. Protocol boundaries use the A2A specification, A2A and MCP guide, MCP architecture, and AWS AgentCore runtime contract.

Context gravity is a Venture Step working theory. The sources establish current platform and protocol behavior, not a universal migration-cost formula. Dalton Anderson's E113 transcript controls his first-person trial and opinion. AI assisted with research organization and drafting; final source boundaries and editorial decisions remain Dalton's.