On July 23, 2026, Google Cloud added standalone agent skill governance to Agent Registry, including access policies, version history and semantic search, according to the official Google Cloud release notes. This technical announcement creates a practical management decision: should your company extend an existing suite, adopt a managed agent platform, build its own system, or stay with a rule-based workflow?
Our article about moving from assistants that answer to agents that act covered the functional shift. The issue here is different: choosing an architecture, operating model and acceptable level of vendor dependency.
The decision on the table
The real decision is not which AI model performs best on a benchmark. It is which technical layers your business wants to own and operate.
An agent may search internal knowledge, call an API, update a business application or request human approval. As its authority increases, the company must decide who manages permissions, instructions, versions, execution logs and emergency shutdown procedures.
The question for management is therefore: do we need an intelligent answer, a controlled action, or a strategically differentiating software component? That answer determines how much technical responsibility should remain in-house.
The architecture must also support your SME AI governance framework. A sophisticated platform cannot compensate for unclear ownership or poorly controlled data.
The available options
A deterministic workflow without an agent
The system follows predefined rules. When an event occurs, it checks conditions, calls specified applications and produces an expected result.
This option fits stable business rules, identifiable exceptions and precisely defined outputs. AI may still classify a document or extract information, but it does not choose the execution path.
An agent embedded in an existing suite
The company extends an environment it already operates, such as Microsoft 365 through Copilot Studio. The agent accesses authorised knowledge, uses connectors and triggers actions within the vendor’s ecosystem. The official Copilot Studio documentation covers knowledge sources, tools, connectors and workflows.
This reduces integration work when identities, documents and business applications already sit within the same suite. It also increases dependency on the vendor’s licensing, connectors and administration model.
A managed agent platform
A cloud platform provides runtime services, registries, permissions, observability and reusable component management. Google Agent Registry can automatically register supported Google Cloud agents and manually reference external, on-premises or REST-based agents, according to the Agent Registry registration documentation.
This architecture is relevant when different teams need to reuse tools and agent skills without rebuilding every integration. It requires structured cloud and identity administration.
A custom-built agent
The company develops the orchestration, integrations, approval rules and user interface around APIs or development kits. The OpenAI Agents SDK documentation describes tools, handoffs, guardrails, human intervention and built-in tracing.
This option provides the greatest functional control. It also makes the company responsible for maintaining code, evaluations, integrations, technical secrets and runtime monitoring.
The criteria that actually matter
| Criterion | Deterministic workflow | Embedded suite agent | Managed platform | Custom build |
|---|---|---|---|---|
| Cost | Integration and relatively predictable maintenance | Licence plus vendor consumption | Cloud consumption, operations and administration | Development, hosting, monitoring and maintenance |
| Lead time | Short when rules are documented | Short to medium depending on connectors | Medium because the platform requires configuration | Long, particularly when actions must be secured |
| Dependency | Low to medium depending on connectors | High dependency on the chosen suite | High runtime dependency, reduced by open interfaces | Depends on the model, SDK and architecture |
| Internal skills | Business analysis and integration | Suite administration and low-code skills | Cloud architecture, identity and operations | Software engineering, security and operations |
| Reversibility | Good when rules and interfaces are documented | Moderate because proprietary services are involved | Moderate to good with standard APIs and protocols | Potentially good, but expensive with tightly coupled code |
The cost of an embedded agent is not limited to its licence. Microsoft states that Copilot Studio consumption depends on agent design, usage frequency and the features invoked. A single interaction may involve different billing categories, as detailed in Microsoft’s Copilot Studio billing documentation.
Reversibility is also broader than data location. Runtime services, identity systems, logs and encryption controls should be assessed alongside the issues covered in our article on the actual control provided by sovereign cloud services.
When to choose what
Choose a deterministic workflow when the business path can be expressed through explicit rules, every result must be reproducible and exceptions can be routed to an identified person. The process owner should provide the decision table and exception list; IT should deliver the execution diagram and expected audit log.
Choose an embedded suite agent when most documents, identities and actions already reside in that ecosystem, and its connectors cover the critical applications. Before approval, the suite administrator should produce a consumption simulation, permission matrix and agent shutdown procedure.
Choose a managed platform when different departments need to share capabilities, versions must be centrally controlled and the cloud team can administer access policies and logs. The expected deliverable is not merely an agent, but an operational catalogue showing the owner, active version and authorised applications for every component.
Choose a custom build when the agent is part of your competitive advantage, must enforce company-specific rules or needs to connect heterogeneous environments without relying on a single suite. Require a modular architecture that separates the model, tools, authorisation rules, memory and user interface.
Do not deploy an agent yet when nobody can define the actions it may take or the conditions requiring human intervention. Document that boundary of authority before funding an impressive but unusable demonstration.
The traps hidden in each option
Deterministic workflow: accumulating exceptions
The hidden cost appears when each special case adds another branch, rule or manual intervention. Without a business owner, the workflow becomes difficult to change and nobody knows which rules remain necessary.
Embedded agent: unpredictable consumption
Ease of development can hide billing complexity. An answer, an internal data search and an application action may use different consumption meters. Testing must reproduce actual business journeys rather than simply checking whether the agent produces a plausible response.
There is also a functional risk: selecting the suite before defining the agent’s authority encourages teams to reshape the requirement around available connectors.
Managed platform: building the factory too early
A registry, semantic search and centralised skill management create value when components genuinely need to be shared. For an isolated use case, this additional layer may increase administration without reducing business risk.
Google’s new standalone skill management remains a pre-general-availability feature, provided as-is with potentially limited support, according to the official skill management documentation. Test it with an exit strategy before using it for a critical business function.
Custom build: underestimating operations
The visible prototype is only part of the system. Teams must also handle model changes, permissions, tool failures, API consumption, tracing and human intervention. Without a test corpus and an identified operational owner, each update can alter expected behaviour.
How D1 Consulting approaches the decision
We begin with an architecture decision brief, not a model selection exercise.
- The business sponsor defines the agent’s authority: permitted actions, prohibited actions, human approval and expected outcomes. The deliverable is a responsibility matrix used throughout testing.
- The process owner provides anonymised real records: inputs, outputs, exceptions and affected applications. The deliverable describes the current path, accessed data and decision points.
- D1 Consulting compares the architectures: fixed and variable costs, dependencies, required skills, degraded operation and reversibility. The deliverable is a decision scorecard and an operating-cost model based on expected usage.
- IT prepares an isolated environment and restricts the agent’s permissions. Business users execute the test corpus, while security reviews secrets and logs. The deliverable is a documented decision to deploy, revise or stop, together with a rollback procedure.
- Management approves the operating model: business owner, technical owner, incident handling and change review. The architecture is approved only when these responsibilities have been assigned.
When a deterministic workflow or a process-focused agent is the right answer, our Automation & Optimisation service covers design and integration. When the initiative spans applications and vendors and requires structured acceptance, our IT Project Management service secures the decision and delivery.
👉 Book your free 30-minute diagnostic: we will qualify your scenario, identify its dependencies and determine which architecture should be investigated first.
