Multi-Cloud Agent Orchestration Without Centralized Schedulers

Regulatory framework

Multi-cloud agent deployments operate inside an increasingly dense regulatory perimeter. EU AI Act obligations apply wherever a high-risk AI system is placed on the Union market or its outputs are used in the Union, regardless of which provider's infrastructure hosts the inference. The EU Cyber Resilience Act extends product-security obligations to digital products and components, including the agent runtimes themselves. GDPR Article 28 requires that processors, including cloud providers and any sub-processors, operate under documented instructions and demonstrable controls; in a multi-cloud agent topology, every cross-provider handoff is a sub-processor relationship that must be auditable.

On the public-sector side, FedRAMP authorizes cloud service offerings at low, moderate, and high impact levels with explicit boundary documentation; an agent that crosses authorization boundaries without structural attestation invalidates the boundary's compliance posture. OMB Memorandum M-24-10 directs federal agencies to maintain inventories of safety-impacting and rights-impacting AI, including agent-based systems, with continuous monitoring obligations that presume the agent's identity and behavior are inspectable wherever it executes. ISO/IEC 27017 specifies controls for cloud-service customers and providers, and ISO/IEC 27018 governs personally identifiable information in public clouds, both of which are difficult to satisfy when agent state moves across providers under the control of an orchestrator that sits outside any single provider's control plane.

The FinOps Foundation framework adds a parallel set of operational requirements: cost allocation, unit economics, and showback or chargeback that depend on knowing which workload ran where, for how long, and against which budget. Centralized orchestrators conflate scheduling decisions with cost-attribution decisions, and the resulting telemetry is provider-specific rather than agent-specific. Regulators and finance functions both end up asking the same question: what did the agent do, where, and under whose authority. Centralized orchestration does not answer this question structurally; it answers it by reconstruction from logs, which is a forensic posture rather than a compliance posture.

Architectural requirement

A defensible multi-cloud agent architecture must satisfy four properties. First, governance portability: the agent must carry its policy commitments, regulatory constraints, and execution eligibility with it, so that compliance does not depend on the substrate. Second, boundary-validated migration: when the agent crosses a trust boundary, whether between cloud providers, between regions, or between authorization tiers, the boundary must validate the agent's credentials structurally, not by reference to an external orchestrator. Third, lineage preservation: the agent's history of decisions, inputs, and authorizations must persist across substrates so that GDPR Article 28 documented-instruction obligations and ISO/IEC 27017 audit trails remain coherent. Fourth, scheduler-independent operation: the agent must be able to operate, fail over, and coordinate with peer agents without depending on a central scheduler whose availability becomes a regulatory dependency.

Container orchestration delivers none of these properties. Kubernetes was designed for stateless workloads scheduled on resource availability and restarted on failure. It has no native model of agent governance, no representation of regulatory constraint, and no notion of execution eligibility beyond pod admission policies. Federated Kubernetes and multi-cluster control planes inherit the underlying assumption: there is one logical scheduler, however physically distributed, and agents are passive workloads it dispatches. Crossplane improves declarative resource management across providers, and Terraform improves declarative infrastructure provisioning, but neither addresses the agent identity and governance portability problem that the regulatory perimeter actually requires.

Why procedural compliance fails

Operators frequently respond to multi-cloud regulatory pressure with procedural compensations: cross-cloud audit log aggregation, periodic configuration reviews, and cloud-security posture management tools that scan for misconfiguration. These activities surface known control gaps. They do not address the structural gap that emerges when an agent's identity, policy, and lineage are managed by an orchestrator whose state is not portable across the substrates it orchestrates.

The failure mode in production is consistent. An agent dispatched by a central scheduler runs in cloud A under one set of credentials, generates outputs that influence a downstream decision, and is then rescheduled to cloud B for cost or capacity reasons. The orchestrator records the migration. It does not record, in the agent itself, the chain of authorizations that justified the agent's actions in cloud A or the policy state that should constrain it in cloud B. When an auditor later asks under what authority the agent acted at a specific moment, the answer requires reconstruction from orchestrator logs, cloud provider logs, and application logs, each with different retention, format, and access controls. GDPR Article 28 documented-instruction compliance becomes a forensic exercise. FedRAMP boundary documentation becomes ambiguous. ISO/IEC 27017 audit trails become incomplete.

The deeper failure is operational rather than evidentiary. Centralized schedulers create a coordination tax that scales superlinearly with multi-cloud surface area. Every cross-cloud migration requires orchestrator involvement. Every policy change must propagate through the orchestrator to every agent in every cloud. Every failover depends on orchestrator availability, and the orchestrator's availability domain rarely matches the failover scenario the multi-cloud topology was supposed to address. Organizations end up running redundant orchestrator deployments to mitigate orchestrator-as-single-point-of-failure risk, which is a strong signal that the architecture has the wrong shape.

FinOps maturity exposes a related symptom. Unit economics for agent workloads require attributing cost to the agent and its purpose, not to the pod, node, or scheduler that happened to dispatch it. Centralized orchestration reports schedule-time placement; it does not report agent-time intent. The accounting system inherits the orchestrator's blind spot. The regulator and the CFO end up asking the same structural question and receiving the same forensic answer, which is to say no answer that satisfies the obligation.

What AQ primitive provides

The AQ execution platform treats agents as self-governing entities rather than scheduled workloads. Each agent carries six canonical fields: governance policy, memory state, lineage history, execution eligibility, trust relationships, and capability declarations. These fields travel with the agent as a single coherent object across any substrate, whether centralized cloud, federated edge, sovereign regional cloud, or on-premises GPU cluster. The agent's identity and authority are properties of the agent itself, not of an orchestrator's record about the agent.

When the agent needs to operate in a different environment, it evaluates the target against its own policy. The governance field encodes the regulatory constraints that apply to the agent: residency requirements under GDPR, authorization boundary under FedRAMP, sectoral obligation under FFIEC, and so forth. The trust scope field encodes which counterparties and zones the agent is permitted to interact with. The execution eligibility field encodes the runtime preconditions that must hold for the agent to act. The agent computes, on its own, whether the target environment satisfies these preconditions, and refuses to migrate or act when it does not.

Cross-cloud migration becomes a structural operation rather than an orchestrated event. The agent presents its governance credentials at the trust-zone boundary. The boundary validates the credentials through quorum verification by the zone's anchor nodes, which themselves are not a single point of failure. The agent's memory, policy, and lineage state travel with it as part of the migration object. No central system needs to be aware of every agent's location at every moment, because every boundary crossing is its own self-contained attestation event with a verifiable record.

Lineage preservation operates by construction. The agent's lineage field accumulates a tamper-evident record of authorizations, inputs, and prior actions. When a regulator or auditor asks under what authority the agent acted at a specific moment, the lineage record is queryable directly against the agent, not reconstructable from heterogeneous logs. GDPR Article 28 documented instructions are encoded in the governance field and bound to specific lineage entries. FedRAMP boundary documentation references the trust zones the agent has crossed. ISO/IEC 27017 audit trails are first-class artifacts rather than retrospective compositions.

Compliance mapping

The execution platform's primitives map directly onto the regulatory perimeter. EU AI Act Article 17 quality management obligations are satisfied by the governance and lineage fields, which encode the system's documented-intent and provide trajectory-level evidence of behavior. EU AI Act Article 72 post-market monitoring is satisfied by the structural telemetry that the agent emits as it operates and migrates, without dependence on a separate observability stack. EU CRA secure-by-design and secure-by-default obligations are satisfied by execution-eligibility checks that fail closed when preconditions are not met.

GDPR Article 28 processor obligations map onto the trust scope and governance fields. The agent enters a sub-processor relationship only when its trust scope authorizes the relationship and its governance constraints are compatible with the sub-processor's posture. The lineage field provides the documented-instruction record. ISO/IEC 27017 cloud-security controls map onto trust-zone boundary validation: each zone is a control surface, and each agent migration is an evaluable control event. FedRAMP boundary integrity is preserved because authorization boundaries are explicit zone properties rather than implicit orchestrator topology, and OMB M-24-10 inventory and continuous-monitoring obligations are satisfied by querying the agents themselves rather than the orchestrator that scheduled them.

FinOps requirements map onto agent-time attribution. Cost is attributed to the agent's purpose, not to the placement decision, because the agent's governance field encodes the budget and cost-center against which it acts. Showback and chargeback become straightforward queries against the agent population, and unit economics for AI workloads become computable rather than forensic. Terraform and Crossplane continue to manage the underlying substrate; the execution platform manages the agent layer that runs on top, and the two coexist without contention because they address structurally different concerns.

Adoption pathway

Adoption proceeds in three phases, each of which is independently valuable and none of which requires displacing existing infrastructure. In phase one, the organization deploys an AQ execution-platform overlay alongside its existing orchestrators. Agents continue to be scheduled by Kubernetes, Airflow, or Temporal, but they are wrapped in the canonical six-field representation and registered with trust zones in each cloud. The overlay provides governance portability and lineage preservation immediately, while leaving placement decisions where they currently live. This phase delivers GDPR Article 28 and FedRAMP boundary clarity in weeks, not quarters.

In phase two, the organization migrates cross-cloud coordination from the centralized scheduler to trust-zone boundary validation. Agents that need to operate across providers now present credentials at zone boundaries directly, rather than being dispatched by a scheduler with cross-cloud awareness. The centralized scheduler retains responsibility for in-cloud placement; the boundary layer handles cross-cloud movement. The orchestrator-as-single-point-of-failure topology dissolves, and the multi-cloud resilience properties that motivated the strategy become operationally real. EU AI Act Article 72 post-market monitoring telemetry begins to flow from the agents themselves rather than from heterogeneous orchestrator logs.

In phase three, the organization adopts the execution platform as the substrate for new agent workloads, using Terraform and Crossplane for underlying resource management and the AQ primitives for agent identity, governance, and coordination. New deployments are natively portable across substrates. Adding a new cloud provider, a new sovereign region, or a new on-premises cluster means establishing a new trust zone. Existing agents operate there as soon as the zone's governance is compatible with their policy requirements, with no orchestrator reconfiguration. FinOps unit economics become a first-class property of the agent population, and compliance posture becomes a structural property of the deployed system rather than a procedural overlay maintained against drift.

The economic argument tracks the regulatory one. Centralized orchestration scales costs and risks superlinearly with multi-cloud surface area, because every additional substrate adds coordination load and another forensic seam. Self-governing agents scale costs and risks linearly, because every additional substrate is just another trust zone with the same boundary semantics. For organizations whose multi-cloud strategy is driven by resilience, residency, or sovereignty, the execution platform is the architectural primitive that makes the strategy compliant, defensible, and operationally tractable at the agent layer. The infrastructure layer has had Terraform for a decade; the agent layer needs a comparable abstraction, and the AQ execution platform is what that abstraction looks like when it is designed for the regulatory perimeter that now exists.