Enterprise AI agents are becoming a platform decision. Google used Gemini at Work 2026 to present a universal work agent with enterprise context, skills, tools, model selection, cost controls, and centralized governance. Earlier releases added agent identities, a registry, a gateway, long-running execution, evaluation, and observability to the same platform.
That is a compelling operating model: one control plane for building, discovering, running, and governing agents. It is not automatically the right answer for every company. Some organizations benefit from one platform's defaults and accountability. Others need specialist models, runtimes, security products, or business applications that no single vendor serves equally well.
The useful question is therefore not simply buy or build? It is: which responsibilities should one platform own, and where does specialization create enough value to justify another boundary? Use the following checklist before a procurement process turns an architectural preference into a multi-year commitment.
Start with the operating model, not the demo
A polished agent completing a cross-application task proves that the workflow is possible. It does not prove that your organization can operate hundreds of agents safely.
Map one consequential workflow from request to outcome. Identify the employee or system that starts it, the data it reads, every tool it can call, the records it may change, the approvals it needs, and the team accountable when it fails. Then compare the platform and composable options against that map.
A unified platform is usually the stronger default when:
- most workloads already sit in one cloud or productivity ecosystem;
- a central platform team must apply the same identity, policy, audit, and lifecycle rules everywhere;
- business users need a governed catalog rather than an engineering toolkit;
- integrations supplied by the platform cover the highest-value workflows; and
- one support and incident path is more valuable than choosing each component independently.
A composable stack deserves serious consideration when:
- regulated or sensitive workloads require separate execution and data boundaries;
- different teams need meaningfully different models, runtimes, or domain tools;
- critical systems are spread across vendors and no platform has a natural center of gravity;
- you already have mature identity, policy, observability, and platform-engineering capabilities; or
- portability and negotiating leverage are explicit business requirements.
Do not confuse “composable” with “unmanaged.” A collection of specialist tools without a common control layer is agent sprawl, not an architecture.
1. Give every agent its own identity and authority
Ask the vendor to show how an agent is represented in identity and access management. A production agent should not hide behind a developer's token or a shared service account. You need to know which agent acted, on whose behalf, under which policy, and with what delegated authority.
Test whether permissions can be scoped by tool, action, data set, destination, tenant, time, and risk. Check how credentials are issued, rotated, revoked, and disabled when an agent is retired. Ask whether an employee's access is re-evaluated when the agent acts later, and whether the platform can separate autonomous authority from authority delegated by a user.
Google's current platform describes cryptographically attested agent identity, least-privilege permissions, OAuth propagation, and attribution of actions to the agent. Treat those capabilities as a benchmark, not a reason to skip validation. Bring your own identity team into the proof of concept and require evidence in your actual environment.
This identity layer should connect to the controls in a broader operating model for enterprise AI agents.
2. Demand a governed registry for agents, tools, and skills
An enterprise catalog must answer more than “what can I install?” It should record an owner, purpose, version, approval status, data classification, permissions, dependencies, evaluation results, and retirement date for each agent, tool, connector, and reusable skill.
Check whether unapproved components can be discovered but blocked, or whether they remain invisible. Ask what happens when a tool schema changes, a connector loses support, or a skill is copied into another agent. The registry should make reuse safer without turning every local experiment into an approved enterprise capability.
For a composable stack, decide which system is authoritative. A spreadsheet maintained after deployment will not remain accurate. Registration should be part of the delivery path, and the runtime gateway should reject components that are missing, expired, or outside policy.
3. Inspect the audit trail as evidence
“Full observability” is too vague for procurement. Run a test task and reconstruct it from the logs. The record should connect the initiating user, agent identity, prompt and policy versions, retrieved context, model calls, tool requests and responses, approvals, cost, final output, and changed business records.
Confirm retention, export, redaction, regional storage, access controls, and integration with your security and incident systems. Determine whether you can distinguish a proposed tool call from an executed one and whether an approval is bound to the exact action that occurred.
NIST's AI Risk Management Framework calls for ongoing monitoring, incident response, recovery, and change management. Your evidence must support those activities after the original conversation has disappeared. Pair auditability with a tested AI agent incident-response and kill-switch procedure.
4. Test portability before you depend on it
Protocol support helps, but it does not equal portability. MCP can standardize how agents connect to tools and context, while A2A can support communication between agents. Neither automatically moves prompts, memory, evaluation data, identity policy, approval logic, or operational history between platforms.
Ask for exports of agent definitions, tool schemas, skills, evaluation sets, traces, and memory. Identify proprietary services in the execution path. Then move one representative workflow to an alternative model or runtime during the evaluation. Record what transfers unchanged, what needs an adapter, and what must be rebuilt.
A unified platform may still be the correct choice after this test. The goal is not zero lock-in; it is knowing where lock-in exists, what value it buys, and how much a future exit would cost.
5. Model cost as a controlled workload
Seat price is only one line. Include model tokens, tool and connector charges, runtime duration, storage, network transfer, evaluation, observability, security products, support, and the people operating the platform. For a composable stack, add integration work and the cost of reconciling logs, policies, and incidents across vendors.
Require budgets by team, workflow, and agent. Verify hard limits for loops, retries, runtime, model choice, tool calls, and external actions. Ask whether routing to a cheaper model changes quality or compliance and whether cost data can be exported to your existing financial controls.
Use a business unit, not a synthetic chatbot, for the comparison. Measure successful outcomes, reviewed exceptions, recovery work, and cost per completed outcome for several weeks. Our guide to AI credit and usage budgets explains why variable agent consumption should be managed more like cloud spend than a fixed software licence.
Make the decision with a bounded pilot
Score both options against the same workflow and acceptance criteria. A practical pilot should demonstrate:
- a unique agent identity and least-privilege access;
- approved discovery of tools and skills through a registry;
- a complete, exportable reconstruction of one successful and one denied action;
- a stop control that prevents new and queued work;
- a tested model or runtime substitution;
- a budget alert and a hard spending or execution limit; and
- named ownership for deployment, incidents, updates, and retirement.
Choose the unified platform if it meets these controls and removes more integration and operating work than it creates in dependency. Choose a composable stack if specialist capability, isolation, or portability produces measurable value—and if you are prepared to own the common identity, policy, registry, audit, and cost layers.
Many enterprises will land on a governed core with carefully approved specialist components. That is a valid answer. The important part is to define the control boundary deliberately, test it with a real workflow, and price the operating model before the agent fleet grows around an accidental architecture.
