AI Architecture Provider Lens Notes

Goal

The chapter has treated AI and agentic architecture as provider-neutral controlled capability. Provider services should now appear as implementation lenses for model access, orchestration, retrieval, tools, identity, safety, evaluation, monitoring, and operations.

The durable idea is:

Provider AI services should implement controlled reasoning, data access, tool use, evaluation, and operations requirements.

The Short Version

A weak provider lens asks:

Which model service should we choose?

A stronger provider lens asks:

Which provider services implement the controls this workflow needs?

Use this translation shape:

Pattern responsibility:
Provider implementation:
Design warning:
Operational note:
Source check:

This keeps the provider lens connected to the architecture instead of turning it into a list of products.

Azure and Microsoft Foundry Lens

Microsoft's current Azure AI platform language is centered on Microsoft Foundry and Foundry Models. Older Azure AI Foundry and Azure OpenAI language still appears in many teams and source materials, so treat naming carefully and verify current documentation before publication.

Pattern Responsibility	Azure / Microsoft Implementation Examples	Design Warning
Model access and model catalog	Microsoft Foundry and Foundry Models, including Azure OpenAI models and selected models from other providers.	Model choice should follow task quality, latency, region, lifecycle, quota, cost, and safety requirements.
Agent and application platform	Microsoft Foundry projects, agents, tools, evaluations, observability, governance, and portal/API surfaces.	A platform surface does not remove the need for domain ownership, tool boundaries, and release controls.
Retrieval and grounding	Azure AI Search for retrieval-augmented generation patterns and enterprise search.	Retrieval needs source selection, metadata, freshness, ranking, authorization, and evaluation.
Safety controls	Azure AI Content Safety and provider/platform policy controls where appropriate.	Safety is broader than one content filter; include workflow policy, escalation, and audit.
Identity and secrets	Microsoft Entra ID, managed identities, and Azure Key Vault.	Avoid broad credentials; apply user, workload, data, and action-level authorization.
Observability and operations	Foundry observability concepts, Azure Monitor, traces, evaluations, feedback, and cost signals.	Monitor behavior and quality, not only service health.
Tool and context integration	Provider tool catalogs, enterprise APIs, and protocol-based integration patterns such as MCP where suitable.	Tool contracts need scope, idempotency, validation, audit, and human approval for sensitive actions.

These are implementation examples. They are not a universal target architecture. A small internal assistant may need a simpler implementation than a regulated customer-facing agent. A multi-cloud or SaaS-heavy environment may use provider tools for only part of the workflow.

Provider-Neutral Translation Questions

Before comparing providers, ask:

Question	Why It Matters
What task is the AI system allowed to perform?	Prevents model selection from hiding scope and risk.
What may the system see?	Drives retrieval, grounding, authorization, and data governance.
What may the system say?	Drives output constraints, citations, refusals, and safety checks.
What may the system do?	Drives tool contracts, permissions, idempotency, and approval.
What must be evaluated?	Drives test sets, quality gates, rollout, and rollback.
What must be monitored?	Drives telemetry, feedback, incident response, and cost controls.
Who owns the outcome?	Prevents the platform team from accidentally owning business meaning and risk.

Once those answers are clear, provider services can be mapped to responsibilities.

Future AWS and GCP Lens Notes

Future AWS and GCP sections should be added only after official source verification.

For AWS, a future lens might need sourced notes for model access, managed agent workflows, knowledge bases or retrieval, guardrails, identity, secrets, monitoring, evaluation, and cost controls.

For GCP, a future lens might need sourced notes for model access, agent/app platforms, retrieval and grounding, safety controls, identity, observability, evaluation, and cost controls.

Do not publish shallow equivalence tables that imply one AI service directly replaces another. Compare provider services by responsibility: model access, orchestration, retrieval, tools, identity, safety, evaluation, observability, cost, and operations.

Example: Commerce Support and Operations AI on Azure

A commerce company might implement the chapter pattern with an Azure/Microsoft lens like this:

Customer or employee request
  -> application identity and policy checks
  -> Microsoft Foundry / Foundry Models for model access
  -> Azure AI Search for authorized retrieval
  -> approved enterprise APIs and workflow tools
  -> safety checks, evaluation, escalation, and audit
  -> Azure Monitor and Foundry observability for operations

The design still needs business decisions: which policies are authoritative, which customer records can be retrieved, which refund actions require approval, how tool calls are logged, which evaluation cases must pass, and when the workflow should refuse or escalate.

Common Mistakes

Treating AI provider selection as only model selection.
Publishing provider claims without official documentation.
Ignoring data access and tool permissions because the AI experience looks conversational.
Letting provider service names replace safety, evaluation, and operations design.
Forgetting that current provider names and APIs can evolve quickly.

If Someone Asks You

How should provider services appear in an AI architecture article?

A good answer is:

Provider services should appear as implementation lenses after the controlled AI workflow is clear. First define what the system may see, say, and do; then define retrieval, tools, identity, safety, evaluation, observability, cost, and owners. Finally, map provider services to those responsibilities and verify factual claims against official documentation.

What You Should Remember

Provider services are lenses for controlled AI capability and operating responsibility.

Questions to Check Understanding

Which AI responsibilities should a provider lens translate?
Why should safety and evaluation lead provider selection?
Which provider facts need official source verification before publication?