Skip to content
Article reader Listen + reading controls
LISTEN + READ YOUR WAY

Article reader

Preparing the reader…

0:00 0:00
Reading settings
Text size
100%

The AI Market Is an Architecture of Dependencies

The Federal Trade Commission’s 2024 inquiry into partnerships among major cloud providers and generative-AI developers was often framed as a question of investment concentration: would multibillion-dollar relationships among Microsoft and OpenAI, Amazon and Anthropic, and Google and Anthropic distort competition?

The deeper question is architectural. Frontier AI developers need capital, specialized compute, storage, networking, distribution, engineering support, and access to enterprise customers. Cloud providers possess those complements at scale. Partnerships can accelerate innovation by joining them. They can also create dependencies that influence which models reach users, which clouds capture workloads, which startups can compete, and who exercises practical control over supposedly independent firms.

Competition cannot be inferred from the number of logos. It must be analyzed through the control points of the AI stack.

The FTC’s Section 6(b) inquiry required Alphabet, Amazon, Anthropic, Microsoft, and OpenAI to provide information about investment terms, governance and oversight rights, product decisions, input dependencies, and competitive effects. The agency later published a staff report on the partnerships—evidence unavailable when the original version of this essay was written.

The inquiry’s design was important because economic control can be exercised without a conventional acquisition.

Compute Is Both an Input and a Switching Cost

Training and operating large models require substantial computing capacity. A cloud partnership can provide a developer with reliable access, favorable pricing, technical integration, and financing. It can also make the developer’s architecture, tooling, data pipelines, and operating economics specific to one provider.

Switching then requires more than moving workloads. The company may need to:

  • port distributed training and inference systems;
  • recreate security and observability controls;
  • renegotiate data and network costs;
  • replace provider-specific services;
  • move enormous model and dataset artifacts;
  • revalidate performance and reliability;
  • and unwind commercial or investment commitments.

The market may appear multi-cloud while the important workloads remain structurally anchored.

Portability should therefore be evaluated through time, cost, performance loss, contractual restrictions, and access to alternative capacity—not through the existence of an API.

Capital Can Carry Governance Rights

An investment may provide the cloud partner with information rights, consultation rights, product influence, revenue participation, exclusivity, first negotiation, or other forms of strategic visibility.

Those rights can affect competition even when the investor does not formally control the company. Early knowledge of roadmap and performance may inform the cloud provider’s own products. Approval or consultation structures may influence which markets the developer enters. Revenue-sharing can align incentives in ways that reduce competition between partners while intensifying it against outsiders.

The analytical question is not whether a partnership is cooperative—partnerships are cooperative by definition. It is whether the specific rights reduce independent decision-making, foreclose alternatives, or allow a dominant firm to shape an adjacent layer.

Distribution May Matter More Than Model Quality

Enterprise buyers prefer models integrated with identity, data platforms, security, productivity tools, and procurement relationships they already use. A cloud provider can turn a model into a default option across a large installed base.

Defaults reduce adoption cost. They also make competition less sensitive to model quality. A technically stronger entrant may struggle if customers must establish new security reviews, data connections, contracts, and user workflows.

The competitive unit is therefore an ecosystem:

model + cloud + data + tools + identity + distribution + commercial terms

Regulators and buyers should examine whether interfaces and data rights allow models to compete inside that ecosystem or whether each model effectively requires customers to adopt a vertically integrated stack.

Information and Data Effects Compound

AI partnerships can create data advantages at several levels:

  • model-training and fine-tuning data;
  • user interaction and feedback;
  • system telemetry and failure information;
  • enterprise workload patterns;
  • and insight into developer roadmaps and customer demand.

The party that sees more usage can improve model routing, tooling, pricing, and infrastructure. The party that operates both cloud and model distribution may learn across multiple developers and customers.

Data advantage is not automatically anticompetitive. The relevant questions include whether data is exclusive, whether customers can export it, whether competitors can obtain comparable feedback, and whether one party may use information obtained through a partnership to compete against the partner or its customers.

Model Diversity Can Conceal Infrastructure Concentration

A market may offer many open and proprietary models while training and inference concentrate among a few infrastructure providers. This creates systemic risk as well as competition risk.

A cloud outage, pricing change, capacity restriction, export-control decision, or security compromise can affect many apparently independent model services. Public and private buyers may discover that vendor diversification did not create infrastructure diversification.

Resilience analysis should map second- and third-order dependencies:

  • Which models depend on which accelerators and clouds?
  • Which orchestration, evaluation, or safety services are shared?
  • Which identity and data platforms sit in the request path?
  • Where can a provider unilaterally change terms or access?
  • Which failures produce correlated impact?

This dependency graph is a market artifact and an operational artifact.

Open Models Change Some Layers, Not All

Open-weight models can reduce dependence on a proprietary endpoint and support local adaptation. They still require compute, tooling, expertise, data, and distribution. If most organizations can afford to operate them only through the same large clouds, openness at the model layer does not eliminate concentration elsewhere.

Open ecosystems need supporting infrastructure:

  • interoperable model formats and serving interfaces;
  • portable evaluation and safety tooling;
  • competitive accelerator and cloud options;
  • accessible fine-tuning and deployment environments;
  • and clear licensing and provenance.

The policy goal should not be to privilege one model-licensing philosophy. It should be to preserve meaningful entry and switching at multiple layers.

Public Buyers Can Influence the Architecture

Government procurement is large enough to shape market incentives. Agencies can require:

  • model and cloud portability;
  • disclosure of critical dependencies;
  • version identification and change notice;
  • export of government prompts, configurations, evaluations, and operational data;
  • independent testing;
  • interfaces that permit model substitution;
  • and continuity plans for provider failure or termination.

These requirements improve competition and mission resilience. They also reduce the risk that an agency’s AI strategy becomes an unexamined extension of one commercial partnership.

The Strategic Inference

The FTC inquiry matters because generative AI is not developing as an isolated software market. It is forming through dense relationships among capital, compute, models, clouds, data, applications, and distribution.

Those relationships can produce enormous efficiencies and important products. They can also make apparent competitors dependent on the same control points and make customers’ switching costs difficult to observe until after adoption.

The correct competition analysis is architectural. Who controls essential inputs? Which rights shape decisions? How portable are workloads and data? Where do defaults determine distribution? Which dependencies create correlated risk?

The answers reveal whether an ecosystem remains open to technical and commercial challenge—or merely presents several brands on top of a concentrated foundation.

This essay was substantially revised in July 2026 to replace the original inquiry summary with an evidence-based market-architecture analysis. It incorporates the FTC staff report published after the original January 2024 post.

For related work on cloud architecture, AI platforms, and enterprise strategy, visit my portfolio or connect on LinkedIn.

References

READER-NEUTRAL SUBSCRIPTION

Follow Field Notes via RSS.

Copy this address into the RSS reader you already use. New notes will appear there automatically—no account, email address, or tracking required.