Distributed systems gave us a useful vocabulary for thinking about coordination: sequential pipelines, fan-out/fan-in, event-driven messaging, supervisor hierarchies. The patterns are mature. The failure modes are documented. The tooling exists.

Agent systems inherit that vocabulary and then break it in one specific place: every coordination hop is a reasoning step, and reasoning degrades with context. In a microservices pipeline, passing a message between services doesn't make either service worse at its job. In a multi-agent system, what you pass, how much you pass, and in what order you pass it directly affects the quality of every downstream decision. Context is not just data , it's the cognitive working memory of the system, and it's finite, it's expensive, and it accumulates garbage.

That single constraint , context as a managed resource , is what makes agent architecture genuinely different from the distributed systems problems you've solved before. It's why the architectural decision that matters most isn't which model you use or how many agents you deploy. It's where you draw the boundaries, what you let each agent see, and how much coordination overhead you're willing to pay for.

This post maps the canonical patterns ( single-agent, sequential, concurrent, evaluator-optimizer, and dynamic supervisor ) onto Microsoft Foundry, Microsoft Agent Framework, and Microsoft Fabric. For each one: what problem it actually solves, where it fails, and what the implementation looks like in practice.

What Actually Matters

I've seen a lot of teams get this wrong in the same way. They spend three weeks benchmarking GPT versus Claude, pick the winner, and then wire it up with whatever architecture felt intuitive. Six months later they're rewriting it from scratch.

The model is not the hard part. Architecture is the hard part ,because once you have a context management problem, a coordination failure, or a token budget blowout at scale, no amount of model-switching fixes it. The structure determines whether the system works in production. The model determines how good the answers are within that structure.

This post is about the structure. Specifically, how the canonical agent design patterns from Anthropic's production research map onto the three Microsoft components you're most likely building on right now: Microsoft Foundry, Microsoft Agent Framework, and Microsoft Fabric.

A quick note on naming before we start

If you've been building on Semantic Kernel or AutoGen, those are now legacy paths. Microsoft Agent Framework is the direct successor to both — same teams, merged into one SDK, with proper workflow orchestration added on top. Microsoft's own docs include migration guides from both. I'll only reference Agent Framework here.

"Azure AI Foundry" is also old. It's just Microsoft Foundry now, with Foundry Agent Service as the runtime at the centre of it.

The three pieces and how they actually fit together

Before the patterns, let me clarify what each piece does and where the seams are — because the marketing descriptions of these products don't make it obvious.

Foundry Agent Service is the runtime. It manages conversation threads server-side, orchestrates tool calls, enforces content safety, handles Entra identity and RBAC, and integrates with Application Insights for tracing. When you deploy an agent here, governance is not something you add later — it's structurally enforced. There's also a hosted agents model in public preview: you bring your own agent code in any framework, containerise it, and Foundry runs it on managed infrastructure.

Microsoft Agent Framework (open source, .NET and Python) is the SDK you write your orchestration logic in. It targets Foundry Agent Service but also supports Azure OpenAI, OpenAI, Anthropic, Ollama, and others via a shared AIAgent base class. Its five built-in orchestration patterns — Sequential, Concurrent, Handoff, Group Chat, Magentic — are what I'll spend most of this post on.

Microsoft Fabric is your data layer. OneLake, Lakehouse, Warehouse, Real-Time Intelligence (Eventhouse/KQL), and semantic models — all under one governance model. What matters for agents is that Fabric has a native Fabric Data Agent that you publish as an endpoint. That endpoint connects directly to Foundry Agent Service as a knowledge source, with identity passthrough: the agent queries Fabric using the end user's credentials, not a service principal. This one detail matters enormously for enterprise governance and you should understand it before you design any data access pattern.

These three don't compete; they form a coherent stack. Foundry is the runtime, Agent Framework is the orchestration SDK, Fabric is the data substrate.

Pattern 1: Single-Agent

The perceive → reason → act loop. One model, one tool set, iterates until done.

Most production use cases fit here. I know that's not what people want to hear — everyone wants to build the cool multi-agent system — but the evidence is pretty consistent: single-agent systems cost less, debug faster, and produce auditable traces that actually mean something to the people who need to read them (compliance teams, regulators, management). The most common mistake I see is jumping to multi-agent architecture before a single well-equipped agent has been properly pushed.

There's a practical ceiling on tool count: around 10-15 function tools before the model starts making poor selection decisions. If you're hitting that ceiling on a single agent, that's a signal — but first check whether you've structured your tools well. Broad, vague tool descriptions are usually the culprit before agent count is.

Where it breaks down: genuine cross-domain parallelism, tasks that overflow a context window without clean summarisation, and anything that structurally requires an independent review step on the generated output.

In Foundry, a single agent is built with PersistentAgentsClient. The conversation history is stored server-side per thread — you're not managing it in memory:

import os
from azure.ai.agents.persistent import PersistentAgentsClient
from azure.identity.aio import DefaultAzureCredential

async with DefaultAzureCredential() as credential:
    client = PersistentAgentsClient(
        os.environ["PROJECT_ENDPOINT"],  # https://<resource>.services.ai.azure.com/api/projects/<project>
        credential
    )

    agent = await client.create_agent(
        model=os.environ["MODEL_DEPLOYMENT_NAME"],
        name="credit-risk-analyst",
        instructions="""You are a credit risk analyst.
        Use the available tools to evaluate loan applications.
        Always complete AML screening before generating a risk verdict.
        Flag any regulatory non-compliance explicitly.""",
        tools=[
            {"type": "function", "function": get_credit_bureau_data},
            {"type": "function", "function": query_internal_risk_model},
            {"type": "function", "function": check_aml_screening},
        ]
    )

    thread = await client.threads.create()
    await client.messages.create(
        thread_id=thread.id,
        role="user",
        content="Evaluate REF-2025-009341 for a £250K commercial loan."
    )
    run = await client.runs.create_and_process(thread_id=thread.id, agent_id=agent.id)

Connecting Fabric here: Instead of writing SQL connectors per agent, publish a Fabric Data Agent over your Lakehouse or Warehouse and register it as a knowledge source in Foundry via workspace ID and artifact ID. The Foundry agent decides at runtime whether the incoming query warrants calling Fabric — and when it does, it passes through the user's own identity. Your credit risk agent querying a customer's transaction history never needs database credentials: it gets exactly the data that user is allowed to see, governed in Fabric, with the lineage tracked there.

# After publishing a Fabric Data Agent from the Fabric portal:
# Foundry portal: Agent Setup → Knowledge → Add → Microsoft Fabric
# Requires FABRIC_WORKSPACE_ID and FABRIC_ARTIFACT_ID from the published endpoint URL:
# https://<env>.fabric.microsoft.com/groups/<workspace_id>/aiskills/<artifact_id>

Pattern 2: Sequential Orchestration

Agents in a defined order. Each one receives the previous agent's output. The control flow is static — you decide it, not the model.

This is the right pattern when your process decomposes into stages with hard linear dependencies: stage 2 cannot start until stage 1 is verified. Document processing pipelines, multi-stage compliance checks, content workflows that go draft → review → publish. The benefit is predictability — you can trace exactly which stage produced what, estimate costs before running, and debug by examining individual stage inputs and outputs.

The trade-off is latency: stages run serially. This is often fine. People underestimate how much quality improves when each model call is narrowly focused rather than handling everything at once.

from agent_framework import ChatAgent
from agent_framework.orchestrations import SequentialBuilder
from agent_framework.azure import AzureChatClient

chat_client = AzureChatClient(
    endpoint=os.environ["AZURE_OPENAI_ENDPOINT"],
    model_id="gpt-4o"
)

# Three agents, three clearly separated responsibilities
extraction_agent = ChatAgent(
    name="DocumentExtractor",
    description="Extracts structured data from unstructured contract text",
    instructions="Extract all financial figures, parties, dates, and obligations. JSON output only. No analysis.",
    chat_client=chat_client,
)

analysis_agent = ChatAgent(
    name="RiskAnalyst",
    description="Analyses extracted contract data for risk indicators",
    instructions="Analyse the structured data for financial and operational risk. Apply IFRS 9 standards. Flag anomalies.",
    chat_client=chat_client,
)

compliance_agent = ChatAgent(
    name="ComplianceChecker",
    description="Validates risk analysis against CBUAE regulatory requirements",
    instructions="Validate the risk analysis. Produce a compliance verdict: PASS, CONDITIONAL, or FAIL with reasons.",
    chat_client=chat_client,
)

workflow = SequentialBuilder() \
    .participants([extraction_agent, analysis_agent, compliance_agent]) \
    .build()

async for event in workflow.run_stream(contract_text):
    print(event)

The extraction agent doesn't reason about compliance. The compliance agent doesn't re-extract data. Each one does one thing well. That separation is what makes each stage reliably auditable.

The Fabric angle for sequential workflows: map stages to the medallion architecture. Extraction writes to Bronze. Analysis reads Bronze, writes enriched data to Silver. Compliance reads Silver, writes its verdict to a certified Gold table — the only layer that downstream Power BI reports and business systems consume. You get data lineage from agent pipeline to governed data product essentially for free.

Pattern 3: Concurrent Orchestration

Multiple agents, same input, running in parallel. Results collected and aggregated when all finish.

There's a rule you have to get right here: concurrent agents must not depend on each other's intermediate output. If Agent B needs Agent A's result to start, that's a sequential dependency disguised as a parallel topology. Forcing it into concurrency introduces race conditions you'll spend weeks debugging. When in doubt, check: could you run these agents in any order and get the same result? If yes, concurrent is valid.

Where this pattern genuinely delivers is multi-dimensional analysis: financial risk assessment across credit, market, and compliance dimensions; content review against multiple independent criteria; voting patterns where you run the same task through N agents and aggregate. The quality improvement from independent perspectives on the same problem is real and measurable.

from agent_framework.orchestrations import ConcurrentBuilder

credit_agent = ChatAgent(
    name="CreditRiskAgent",
    description="Assesses creditworthiness and probability of default",
    instructions="Evaluate credit risk: debt ratios, payment history, collateral. Output a credit risk score 0-100 with justification.",
    chat_client=chat_client,
)

market_agent = ChatAgent(
    name="MarketRiskAgent",
    description="Evaluates exposure to market volatility and macro factors",
    instructions="Assess market risk: sector exposure, rate sensitivity, economic indicators. Output a market risk score 0-100.",
    chat_client=chat_client,
)

aml_agent = ChatAgent(
    name="AMLAgent",
    description="Screens for AML, KYC compliance, and sanctions exposure",
    instructions="Screen for AML/KYC issues, sanctions lists, PEP status. Output a compliance risk score 0-100.",
    chat_client=chat_client,
)

# All three run simultaneously. Total wall time ≈ slowest single agent.
workflow = ConcurrentBuilder() \
    .participants([credit_agent, market_agent, aml_agent]) \
    .build()

async for event in workflow.run_stream(loan_application_json):
    if isinstance(event, WorkflowOutputEvent):
        # Aggregate: weighted score per institutional risk policy
        aggregate_risk_score(event.data)

A BFSI example where I've seen this work well in practice: loan underwriting where regulatory requirements mandate independent assessments across risk dimensions. The assessments are genuinely independent. Running them concurrently cuts decision time without compromising the separation requirement.

Pattern 4: Handoff and Group Chat

Two separate patterns that both address multi-agent collaboration, but with different control philosophies.

Handoff transfers complete task ownership between agents based on context. There's no supervisor — an agent decides for itself to pass the conversation to a peer, and when it does, the receiving agent takes full responsibility. It's inherently interactive: designed for triage and routing scenarios where a first-contact agent identifies the right specialist and exits.

Don't confuse this with agent-as-tools (where a supervisor delegates a subtask and retains control). In Handoff, once the handoff fires, the originating agent is done. The context propagation model in Agent Framework broadcasts user and agent messages to all participants but deliberately excludes tool call contents — worth knowing before you design a workflow that assumes otherwise.

Group Chat is a shared conversation where multiple agents participate in the same thread. Each agent sees the full conversation history and contributes when the orchestrator selects them. Good for research tasks, design reviews, anything where you genuinely benefit from agents building on each other's observations rather than working independently.

Neither of these is inherently "better" than the other. Handoff is cleaner operationally; Group Chat is more flexible. Pick based on whether you need clean ownership transfer or collaborative refinement.

Pattern 5: Magentic — The Dynamic Supervisor

Magentic is Agent Framework's implementation of the supervisor/hierarchical pattern. A manager agent receives the task, builds a plan, selects which specialist to invoke, evaluates progress after each response, replans if needed, and synthesises the final result. The control flow is entirely LLM-driven — the manager decides everything at runtime.

This is the most capable orchestration pattern and also the most expensive and operationally complex. It's genuinely appropriate for open-ended tasks where you cannot predetermine the sequence of steps: competitive intelligence gathering, multi-domain research, incident analysis across systems. For anything where you can predetermine the steps, Sequential is cheaper, faster, and easier to debug. Use Magentic when the problem resists decomposition.

from agent_framework import ChatAgent
from agent_framework.orchestrations import MagenticBuilder
from agent_framework.openai import OpenAIChatClient

# The manager agent is implicit in MagenticBuilder.
# You define the specialists and their descriptions — the manager
# uses those descriptions to decide who to call and when.

researcher = ChatAgent(
    name="Researcher",
    description="Gathers information, market data, and evidence. Does not draw conclusions.",
    instructions="You find and surface relevant information. Present evidence; let the analyst draw conclusions.",
    chat_client=OpenAIChatClient(model_id="gpt-4o-search-preview"),  # web search enabled
)

analyst = ChatAgent(
    name="FinancialAnalyst",
    description="Performs quantitative analysis on data. Produces structured numerical outputs.",
    instructions="Analyse data quantitatively. Use figures. Avoid speculation without data.",
    chat_client=chat_client,
)

strategist = ChatAgent(
    name="Strategist",
    description="Synthesises research and analysis into recommendations.",
    instructions="You produce final recommendations based on evidence from the researcher and analyst.",
    chat_client=chat_client,
)

workflow = MagenticBuilder() \
    .participants([researcher, analyst, strategist]) \
    .build()

One production consideration worth flagging: Magentic includes optional human-in-the-loop at the planning phase and at stall detection points. If you're running this in a regulated environment where someone needs to approve the agent's plan before it executes, that hook is there. Use it.

Pattern 6: Evaluator-Optimizer

Two agents in a loop: one generates, one evaluates, repeat until quality criteria are met. Typically converges in 2–4 cycles.

The pattern is only worth its token cost when three things are true: quality criteria can be made explicit enough for an agent to apply them consistently; the generator is capable of meaningfully incorporating feedback (not just acknowledging it); and the business value of a higher-quality output justifies 3–5× the token spend of a single pass.

For contract clause generation, security-sensitive code, regulatory disclosures, and technical documentation — where precise wording genuinely matters and errors have downstream consequences — this pays for itself. For anything where first-pass quality is already acceptable, it doesn't.

async def evaluator_optimizer_loop(
    generator_agent_id: str,
    evaluator_agent_id: str,
    task: str,
    max_iterations: int = 4,
    quality_threshold: float = 0.85
) -> str:
    current_output = ""
    feedback = ""

    for iteration in range(max_iterations):
        gen_prompt = (
            task if iteration == 0
            else f"{task}\n\nPrevious output:\n{current_output}\n\nEvaluator feedback:\n{feedback}\n\nRevise."
        )

        gen_thread = await client.threads.create()
        await client.messages.create(thread_id=gen_thread.id, role="user", content=gen_prompt)
        gen_run = await client.runs.create_and_process(thread_id=gen_thread.id, agent_id=generator_agent_id)
        current_output = extract_last_message(gen_run)

        eval_prompt = f"""Evaluate this contract clause against:
        1. Legal precision under UAE law
        2. No ambiguous terms
        3. DIFC compliance
        4. Risk exposure for the issuing party

        Clause: {current_output}
        Return JSON only: {{"score": 0.0-1.0, "feedback": "...", "approved": true/false}}"""

        eval_thread = await client.threads.create()
        await client.messages.create(thread_id=eval_thread.id, role="user", content=eval_prompt)
        eval_run = await client.runs.create_and_process(thread_id=eval_thread.id, agent_id=evaluator_agent_id)
        result = parse_json(extract_last_message(eval_run))

        if result["approved"] or result["score"] >= quality_threshold:
            print(f"Converged at iteration {iteration + 1} — score: {result['score']}")
            break

        feedback = result["feedback"]

    return current_output

Write every iteration to a Fabric Lakehouse table: generator output, evaluator score, feedback, cycle number, and final verdict. After a few months of production data, you'll have a clear picture of which task types consistently require 3–4 cycles versus converge on the first pass. That data directly informs where to invest in prompt engineering and where your generator is reliably good enough.

Which pattern to use: three questions, not a matrix

I've seen enough pattern-selection matrices that don't survive first contact with a real requirement. So here are the three questions that actually resolve most decisions:

Can you write down the steps before you run it? If yes, Sequential or Concurrent. If no, Magentic or Group Chat. This single question eliminates 80% of the ambiguity.

Do the subtasks depend on each other's outputs? If yes and they're linear, Sequential. If yes and the dependency structure is complex and dynamic, Magentic. If no, Concurrent.

What does it cost to get this wrong? High-stakes regulated outputs (loan approvals, compliance verdicts, contract clauses) should start simple — single agent or sequential — because you need a trace that a compliance officer can follow. Research and analysis tasks with lower consequence have more room for collaborative/dynamic patterns.

Multi-agent systems consume roughly 10–15× more tokens than equivalent single-agent ones. That's not a reason to avoid them — it's a reason to be intentional about when you deploy them.

Observability is not a feature you add later

Every pattern above will eventually produce a failure mode you didn't anticipate. An agent that consistently makes the wrong tool selection in a specific context. A Magentic manager that replans unnecessarily on a particular class of input. A concurrent workflow where one agent's output systematically degrades the aggregated result.

A stack trace won't tell you any of that. You need visibility into the full reasoning path: what was in the context window, which tool was selected and why, what the intermediate outputs looked like, where the orchestration branched.

Foundry Agent Service emits run-level traces via OpenTelemetry to Application Insights — individual runs, tool call sequences, token consumption per step. Agent Framework adds structured telemetry on top. For multi-agent orchestrations, you need correlation IDs that span the entire workflow, not just individual runs.

Ship that telemetry to Fabric Real-Time Intelligence (Eventhouse). Store it. Query it:

// Agent runs that are candidates for investigation: high token spend or repeated retries
AgentRunLogs
| where timestamp > ago(24h)
| where totalTokens > 15000 or retryCount > 2
| summarize
    avgTokens    = avg(totalTokens),
    p95Tokens    = percentile(totalTokens, 95),
    failureRate  = countif(status == "failed") * 100.0 / count()
  by agentName, orchestrationPattern, bin(timestamp, 1h)
| order by failureRate desc

The KQL is not the point. The point is that once your agent telemetry lives in Fabric alongside your operational data, you can correlate agent behaviour with business outcomes — which is the question that eventually matters, not just whether the agent ran successfully.

The reference architecture

This is the setup I keep coming back to for enterprise deployments. Clean separation between orchestration, tool, and data layers.

Two decisions baked into this that are worth making explicitly:

Agents don't hold database credentials. They access data through published Fabric Data Agents, which means access control lives in Fabric and travels with the user's identity. When a user queries through an agent, they see what they're permitted to see — not what the service principal is permitted to see. This is not a minor governance detail.

Telemetry flows to Fabric, not just to Application Insights. App Insights is where you debug individual runs. Fabric is where you understand system behaviour over time, correlate with business data, and build the improvement loop that makes the system better over months.

What I'd actually do if I were starting today

Start with a single Foundry agent. Wire up a Fabric Data Agent as its primary knowledge source for structured data. Get it working well. Measure.

Add Agent Framework orchestration when — and only when — you have specific evidence that the single-agent pattern is hitting a structural ceiling: context overflow on a particular task class, quality degradation that traces back to the agent trying to handle too many independent concerns at once, or a genuine parallelism requirement.

The teams I've seen do this well shared one habit: they were suspicious of complexity. They pushed single agents further than felt comfortable, proved the ceiling, then made the architectural move. The teams I've seen waste months doing the opposite — designing an elegant multi-agent system on a whiteboard and spending six months debugging coordination failures — did the opposite.

The patterns are all available. Use the simplest one that works.

Every enterprise AI initiative eventually confronts the same brutal reality: your agents are only as good as the knowledge they can access. Two failure modes dominate production deployments. First, knowledge fragmentation—critical information scattered across SharePoint sites, data lakes, databases, and file shares, each requiring custom integration work. Second, hallucination without context—agents confidently generating plausible-sounding answers with no grounding in your actual organizational knowledge.

Foundry IQ addresses both challenges through a unified, permission-aware knowledge architecture purpose-built for agentic workloads. Rather than forcing architects to build custom RAG pipelines for each data source, Foundry IQ provides a single abstraction layer that handles the complexity of multi-source retrieval, hybrid search, and enterprise security requirements.

The impact is measurable: organizations report 30-40% faster knowledge discovery, 25-35% improvement in agent response accuracy, and dramatic reduction in the engineering effort required to maintain production AI systems.

Figure 1: Foundry IQ layered architecture enabling unified knowledge access for AI agents

2. Architecture Deep Dive

Foundry IQ's architecture reflects lessons learned from thousands of enterprise RAG implementations. The system comprises four interconnected subsystems that work together to deliver reliable, permission-aware knowledge retrieval.

Knowledge Source Abstraction

The foundation layer normalizes access patterns across three source categories. Indexed sources include SharePoint, OneLake, and Azure Data Lake Storage, which Foundry IQ crawls and indexes for optimal query performance. Federated sources encompass external APIs and database connections queried in real-time. Web sources leverage Bing Search integration for current information beyond organizational boundaries.

Hybrid Search Engine

Unlike vector-only solutions, Foundry IQ implements true hybrid search combining BM25 keyword matching with vector semantic search. The system dynamically balances these approaches based on query characteristics, using a fusion formula: Score = α × BM25(q,d) + (1-α) × CosineSim(embed(q), embed(d)), where α adapts automatically based on query analysis.

Azure Content Understanding

Document processing goes far beyond basic text extraction. Azure Content Understanding performs layout-aware analysis that preserves document structure—tables remain queryable as structured data, figures are captioned and indexed, and hierarchical relationships are maintained. This matters enormously for enterprise documents where context derives from formatting.

Figure 2: The six-stage agentic retrieval pipeline with hybrid search optimization

3. Competitive Landscape Analysis

Understanding Foundry IQ's positioning requires examining the alternatives organizations typically consider for enterprise knowledge management.

Databricks Unity Catalog

Unity Catalog excels at data governance and catalog management but lacks native RAG capabilities. Organizations must build custom retrieval pipelines, manage their own vector stores, and implement permission propagation manually. The integration overhead is substantial.

Pinecone

As a purpose-built vector database, Pinecone delivers excellent vector search performance. However, it offers no native hybrid search, requires external orchestration for multi-source queries, and provides no built-in permission model—critical gaps for enterprise deployment.

Weaviate

Weaviate provides open-source hybrid search capabilities and strong developer experience. The trade-offs emerge in enterprise scenarios: limited governance features, no native integration with enterprise identity systems, and the operational burden of self-hosting.

Figure 3: Capability comparison across key enterprise requirements

Foundry IQ differentiates through agent-native integration, automatic multi-source orchestration, permission-aware retrieval, Azure Content Understanding, and enterprise governance. It is the only solution designed from the ground up for agentic workloads within the Microsoft ecosystem.

4. The Microsoft IQ Ecosystem

Foundry IQ represents one component of Microsoft's broader intelligence strategy. Understanding the full picture requires examining its relationship with Fabric IQ and Work IQ.

Fabric IQ: Semantic Intelligence

Fabric IQ provides the semantic layer for organizational data. Its components include an enterprise ontology defining business concepts and relationships, semantic models enabling natural language queries over structured data, a graph engine for relationship traversal, and data agents that can answer questions about structured datasets.

Work IQ: Collaboration Intelligence

Work IQ extracts intelligence from Microsoft 365 collaboration data—emails, Teams conversations, meeting transcripts, and documents. It maps expertise across the organization, understands work patterns, and enables agents to find the right human experts when automated answers aren't sufficient.

Foundry IQ: The Knowledge Bridge

Foundry IQ sits at the intersection, providing unified access to both structured data through Fabric IQ integration and collaboration knowledge through Work IQ connections. When an agent needs to answer a complex question requiring both data analysis and document context, Foundry IQ orchestrates retrieval across all three systems.

Figure 4: Microsoft IQ unified intelligence layer with Fabric IQ, Work IQ, and Foundry IQ convergence

Figure 5: Real-world synergy scenario showing coordinated retrieval across all IQ components

5. Permission Model and Enterprise Governance

Security cannot be an afterthought in enterprise AI. Foundry IQ implements a four-layer permission model ensuring that users only access information they're authorized to see—regardless of how sophisticated the AI queries become.

Layer 1: Identity Authentication validates user identity through Entra ID, establishing the security principal for all subsequent authorization decisions.

Layer 2: Source-Level Authorization inherits permissions from source systems. If a user can't access a SharePoint site directly, they can't access its content through Foundry IQ.

Layer 3: Knowledge Base Roles provides additional scoping through Owner, Contributor, and Reader roles at the knowledge base level.

Layer 4: Document-Level Filtering evaluates ACLs in real-time, filtering results to only documents the user can access.

Figure 6: Four-layer permission model ensuring comprehensive access control

Comprehensive audit logging tracks every query and retrieval operation, supporting HIPAA, GDPR, SOC 2, and FINRA compliance requirements. Organizations maintain complete visibility into how knowledge is accessed and used.

6. Enterprise Use Cases

Foundry IQ's value becomes concrete when examining specific industry applications.

Financial Services

Investment banks and asset managers use Foundry IQ to unify regulatory compliance documentation, risk assessment models, trade surveillance data, and AML enforcement records. Agents can answer complex questions spanning multiple regulatory frameworks while maintaining strict audit trails.

Healthcare

Healthcare organizations integrate clinical decision support guidelines, patient record summaries, pharmaceutical research databases, and compliance documentation. The permission model proves especially valuable given HIPAA requirements.

Manufacturing

Industrial companies unify equipment maintenance histories, quality control specifications, supply chain documentation, and safety compliance records. Field technicians access relevant knowledge through agents without needing to know which system contains specific information.

Legal

Law firms and corporate legal departments integrate contract repositories, case law databases, due diligence files, and regulatory compliance documentation. Matter-specific permissions ensure ethical walls are maintained.

Figure 7: Enterprise use cases spanning financial services, healthcare, manufacturing, retail, legal, and energy

7. Performance and Cost Analysis

Enterprise architects need concrete numbers to plan deployments effectively.

Latency Expectations

Indexed source queries typically complete in 50-80ms. Semantic search adds 100-150ms for embedding generation and vector similarity. Federated sources vary based on underlying system performance, typically 200-500ms. Complex multi-source queries with reasoning require 400-1000ms for full orchestration.

Quality Metrics

Internal benchmarks show Precision@10 of 0.82, Recall@50 of 0.91, Mean Reciprocal Rank of 0.76, and F1 Score of 0.86—significantly outperforming competitor averages in enterprise knowledge retrieval scenarios.

Figure 8: Latency and quality metrics compared against competitor averages

Cost Structure

Pricing follows a consumption model. Indexing costs approximately $0.05 per GB of content processed. Query costs range from $0.001 to $0.002 per query depending on complexity. Azure Content Understanding for rich document analysis adds approximately $0.50 per page processed. For a typical medium enterprise with 10GB indexed content and 100K monthly queries, expect $150-250 per month—often achieving 2-4 week payback periods through productivity improvements.

Figure 9: Cost breakdown and ROI impact analysis for enterprise deployment

8. Roadmap and Future Direction

Understanding the product trajectory helps organizations plan long-term AI architecture decisions.

The current Public Preview (Q1 2026) offers single-region deployment with preview SLA commitments. General Availability planned for Q2 2026 will bring multi-region support, 99.9% SLA guarantees, and full production support. Q3 2026 will introduce advanced features including custom embedding models, real-time incremental indexing, and cross-cloud federation capabilities.

Looking further ahead, Microsoft's vision encompasses agentic retrieval with multi-hop reasoning, semantic reasoning across knowledge graphs, and autonomous content curation that identifies and prioritizes high-value knowledge sources automatically.

Figure 10: Product roadmap from public preview through GA and future capabilities

9. Implementation Strategy

Successful Foundry IQ adoption follows a phased approach aligned with organizational readiness.

Readiness Assessment

Before deployment, evaluate four dimensions: Knowledge volume and distribution across organizational sources. Agent development plans and timeline for agentic AI initiatives. Governance maturity and ability to manage enterprise-wide knowledge policies. Azure commitment level and integration with existing Microsoft investments.

Phased Implementation

Phase 1 (Proof of Concept, 4-8 weeks): Deploy for 1-2 high-value use cases, index 1-2GB of representative content, establish baseline quality metrics. Phase 2 (Pilot, 2-3 months): Expand to 3-5 use cases, index 10-50GB, involve pilot user group, measure business impact. Phase 3 (Production): Full organizational rollout, complete knowledge base indexing, continuous optimization based on usage patterns.

10. Conclusion

Foundry IQ represents Microsoft's answer to the enterprise knowledge challenge that has plagued AI initiatives. By providing a unified, permission-aware, agent-native knowledge layer, it removes one of the most significant barriers to production AI deployment.

The combination of hybrid search, Azure Content Understanding, and multi-source orchestration creates a foundation for AI systems that are trustworthy (grounded in actual organizational knowledge), compliant (respecting existing permission structures), effective (30-40% faster knowledge discovery), and scalable (unified architecture across all knowledge sources).

For organizations already invested in the Microsoft ecosystem, Foundry IQ provides the knowledge infrastructure layer that makes everything else possible. The convergence with Fabric IQ and Work IQ suggests a future where enterprise intelligence truly becomes unified—where the artificial boundaries between data, documents, and collaboration dissolve into a single, coherent knowledge graph accessible to both humans and agents.

The knowledge layer is not just another component of enterprise AI architecture. It is the foundation upon which everything else is built.

The "Code Red" That Changed Everything

We thought the year was over. The artificial intelligence industry, having sprinted through a marathon of releases in 2025, seemed ready to settle into a quiet holiday season. OpenAI had released the robust GPT-5 in August and the iterative GPT-5.1 in November. Microsoft had successfully rebranded Azure AI Studio to Microsoft Foundry, consolidating its enterprise story. The roadmap seemed clear, linear, and predictable.

Then came Google’s Gemini 3.

In early December, the landscape shifted overnight. Gemini 3 didn’t just iterate; it claimed supremacy, topping critical leaderboards in reasoning and coding, and challenging the perceived dominance of the GPT architecture. The industry buzz was palpable—developers were looking at the benchmarks, enterprise architects were reconsidering their loyalty, and the narrative of "OpenAI dominance" was facing its first genuine existential threat.

The response from OpenAI was swift, decisive, and arguably unprecedented in its urgency. Sources report a "Code Red" directive issued by leadership—a mandate to pause non-essential projects, shelve flashy consumer features like advanced voice modes or ad integrations, and focus every available resource on one thing: reclaiming the frontier. The result is GPT-5.2, released on December 11, 2025.

This is not a standard point release. It is a strategic counter-offensive designed to solve the reliability and reasoning deficits that have plagued Large Language Models (LLMs) in complex, real-world workflows. It represents a pivot from "AI as a Chatbot" to "AI as an Agent." For those of us in the Microsoft ecosystem, the impact is immediate and profound. From the IDEs of Visual Studio Code to the orchestration layers of Microsoft Foundry, the tools we use every day have just received a massive, instantaneous engine upgrade.

As a Microsoft MVP, I have spent the last few days dissecting this release—analyzing the token economics, stress-testing the new "Thinking" models in VS Code, and evaluating the integration within Microsoft Foundry. This report is an exhaustive guide to what GPT-5.2 means for you, your code, and your enterprise. We aren't just looking at the specs; we are looking at the second and third-order effects of a release that has fundamentally altered the trajectory of AI development for 2026.

Part 1: The Architecture of GPT-5.2

To understand why GPT-5.2 is significant, we must first abandon the idea of a "monolithic" model. The era where a single "GPT-4" or "GPT-5" served every query is over. The "Code Red" directive has crystallized a tiered architecture that acknowledges a fundamental truth in AI engineering: not all queries require the same depth of compute, and treating them as if they do is economically and computationally inefficient.

1.1 The Omni-Model Strategy: Instant, Thinking, and Pro

GPT-5.2 is not a single model; it is a coordinated family of models, each optimized for a specific point on the latency-cost-intelligence curve. This segmentation is critical for enterprise architects who need to balance budget with performance.

GPT-5.2 Instant: The Velocity Layer

For the past two years, "latency" has been the silent killer of AI adoption. Users accustomed to instant search results found the token-by-token generation of LLMs agonizingly slow for simple tasks. GPT-5.2 Instant is the answer. It is designed to replace the default operational tier of previous generations.

Unlike the "Nano" or "Mini" models of the past, which achieved speed by sacrificing significant reasoning capability, "Instant" retains the "warmer," more conversational tone introduced in GPT-5.1 but optimizes the inference path for high throughput. It is the "reflexive" brain of the system—perfect for informational queries, simple SQL generation, content summarization, and real-time customer support. In my testing, the time-to-first-token (TTFT) is imperceptible, making the interaction feel more like a database lookup than a generative process.

GPT-5.2 Thinking: The Reasoning Engine

This is the heart of the release. The "Thinking" variant integrates Chain-of-Thought (CoT) processing directly into the inference pipeline, but it does so in a way that is fundamental to the model's architecture rather than just a prompting trick.

When you ask GPT-5.2 Thinking to perform a complex task—say, "Analyze this financial statement and project Q4 earnings based on these three variables"—it engages in a hidden "reasoning" phase. It generates "reasoning tokens" that are used internally to verify logic, plan multi-step execution, and critique intermediate results. These tokens are generally not visible to the user (though they contribute to the billing, which we will discuss later), but they result in a final output that has been "fact-checked" by the model itself.

Internal metrics suggest that GPT-5.2 Thinking solves harder work tasks more effectively than any previous iteration, with specific optimizations for data structure manipulation and technical writing. It is the "workhorse" for the professional.

GPT-5.2 Pro: The Frontier of Trust

Positioned as the direct competitor to Gemini 3 Pro and Claude Opus 4.5, GPT-5.2 Pro is the "Trustworthy" model. It is designed for high-stakes scenarios where accuracy is paramount and latency is secondary—legal drafting, complex architectural planning, or medical research analysis.

The "Pro" designation implies a higher degree of safety and adherence to constraints. In early testing, it shows fewer major errors in complex domains. This is the model you use when a hallucination could break a downstream workflow or cause a compliance violation.

1.2 The 400k Context Window and "Compaction"

One of the most staggering specifications of GPT-5.2 is the 400,000-token context window. To put this in perspective, this is roughly 300,000 words—enough to hold several novels, a massive codebase, or a year's worth of corporate documentation in a single prompt.

However, a large context window is useless if the model "forgets" information in the middle—a phenomenon known as the "Lost in the Middle" problem. This is where GPT-5.2 introduces a critical innovation: Compaction.

Compaction is an architectural feature that allows the model to summarize and "prune" its own context history effectively. As the conversation or task progresses, the model identifies which parts of the context are no longer immediately relevant and "compresses" them into a denser representation. This allows it to maintain coherence over millions of tokens of interaction by retaining only the relevant state.

For developers, this is a game-changer. It means you can have a "long-running task"—such as an AI agent autonomously refactoring a legacy codebase over a 24-hour period—without the model crashing or losing the thread of the original intent. It transforms the context window from a "short-term memory" buffer into a persistent working state.

1.3 The Output Revolution: 128k Tokens

Perhaps even more important than the input window is the 128,000-token output limit. Previous models were often capped at 4,096 or 8,192 output tokens. This limitation was a massive bottleneck for generating long-form content. If you asked an AI to "write a complete module for this application," it would often cut off halfway through, requiring the user to prompt "continue."

With 128k output tokens, GPT-5.2 can generate comprehensive whitepapers, entire software libraries, or massive datasets in a single pass. This capability is essential for the "Agentic" workflows Microsoft is pushing, where an agent needs to produce a complete, functional artifact without human hand-holding.

Part 2: Microsoft Foundry - The Enterprise Control Plane

While the model architecture is fascinating, for the enterprise, the platform is what matters. The release of GPT-5.2 coincides with the aggressive maturation of Microsoft Foundry (formerly Azure AI Foundry). This is not just a rebrand; it is a declaration of intent. Microsoft is positioning Foundry as the "factory floor" where raw AI models are forged into business solutions.

2.1 Immediate Availability and the "First-Party" Experience

In the past, there was often a lag between an OpenAI release and its availability on Azure. With GPT-5.2, the integration is instantaneous. The models (Instant, Thinking, and Pro) are available in the Foundry Model Catalog right now.

This "zero-day" availability is crucial for Microsoft's strategy. It prevents enterprise customers from drifting to OpenAI's direct API for the "latest and greatest." By offering GPT-5.2 immediately within the secure, compliant perimeter of Azure, Microsoft ensures that the "Code Red" innovation is accessible to regulated industries—banks, healthcare providers, and governments—without compromising on data residency or security.

2.2 Token Economics: The Price of Thought

The pricing structure for GPT-5.2 in Microsoft Foundry reveals a strategic effort to commoditize baseline intelligence while monetizing high-value reasoning.

• Standard Pricing: The baseline pricing for GPT-5.2 (Instant/Standard) is aggressively set at $1.25 per 1 million input tokens and $10.00 per 1 million output tokens. This is significantly cheaper than the early GPT-4 era, reflecting the efficiency gains in inference optimization. It signals that "standard" intelligence is becoming a utility—cheap, abundant, and everywhere.
• Pro Pricing: The "Pro" tier commands a significant premium, priced at $15.00 per 1 million input tokens and $120.00 per 1 million output tokens. This 10x differential is a clear signal: "Pro" is not for everyday chat. It is for high-value, low-volume tasks where the cost of an error outweighs the cost of compute.
• Reasoning Effort Parameter: A new API parameter available in Foundry allows developers to control the reasoning_effort (low, medium, high, or none). Setting this to "none" forces the model into the lower-latency Instant path. Setting it to "high" engages the deep thinking capabilities. This gives developers granular control over their "compute budget," allowing them to spend more on difficult queries and save on simple ones—a concept I call "Latency Arbitrage."

2.3 Foundry Agent Service and Foundry IQ

Foundry is not just hosting models; it is orchestrating Agents. The "Foundry Agent Service" allows developers to build autonomous loops where GPT-5.2 can take actions, call tools, and make decisions.

Critical to this is Foundry IQ, a retrieval engine powered by Azure AI Search. One of the biggest challenges with RAG (Retrieval-Augmented Generation) has been the "dumb retrieval" problem—fetching irrelevant documents that confuse the model.

GPT-5.2’s "Thinking" capability revolutionizes RAG. When connected to Foundry IQ, the model doesn't just blindly ingest the retrieved documents. It "reasons" over them. It can evaluate the relevance of a document, detect contradictions between sources, and synthesize a coherent answer even from messy corporate data (SharePoint, OneLake, SQL Server). The high reasoning density of the model acts as a filter, significantly reducing hallucinations.

2.4 Safety and Data Zones

For the enterprise, the "Code Red" speed of release might sound alarming. Does speed come at the cost of safety? Microsoft addresses this with Data Zones. Foundry allows customers to pin their GPT-5.2 deployments to specific geographic zones (e.g., EU Data Zone or US Data Zone), ensuring that data never leaves the regulatory boundary.

Furthermore, Microsoft applies its "Content Safety" filters at the gateway level. Even if the raw model has the capability to generate harmful content, the Foundry safety layer intercepts the prompt and the completion, checking for jailbreaks, PII (Personally Identifiable Information), and hate speech before the data ever touches the model or the user. This "defense in depth" is why enterprises choose Foundry over direct API access.

Part 3: The Developer Experience - VS Code & GitHub Copilot

If Microsoft Foundry is the backend, Visual Studio Code is the frontend. This is where the rubber meets the road for millions of developers. The integration of GPT-5.2 into GitHub Copilot represents the most significant shift in the developer "inner loop" since the introduction of autocomplete.

3.1 From "Chat" to "Agent"

The headline feature for developers is the shift from "Chat" to "Agent." In the latest VS Code update, the Copilot interface has evolved. Users can now select "Agent" from the model picker, powered by the GPT-5.2 reasoning engine.

This is not just a semantic change. A "Chat" interaction is stateless and passive: you ask a question, it gives an answer. An "Agent" interaction is stateful and active.

• Autonomous Refactoring: You can now give high-level instructions like, "Refactor this entire class to use the Repository pattern, update all unit tests to match, and verify that I haven't broken the dependency injection."
• Execution: The GPT-5.2 Agent breaks this down into steps. It plans the file changes. It executes the edits. It runs the tests (if you allow it). It reads the error logs, self-corrects, and tries again. This loop is only possible because of the high reliability of GPT-5.2’s reasoning; previous models would get lost in the middle of such a multi-step task.

3.2 "Vibe Coding" and the Natural Language Interface

The community has coined the term "Vibe Coding" for the workflow enabled by these high-reasoning models. It refers to writing code using natural language prompts that describe the intent and the vibe of the application, relying on the model to handle the implementation details.

With GPT-5.2, "Vibe Coding" moves from a hobbyist experiment to a professional workflow. Because the model has a 400k context window, it can "see" your entire project structure. It understands your naming conventions, your architectural patterns, and your specific libraries. When you say, "Make it look more modern," it knows what "modern" means in the context of your specific CSS framework because it has read your configuration files.

3.3 Agent Sessions: Managing the Workflow

To manage this new autonomy, VS Code has introduced "Agent Sessions". This UI paradigm treats an AI interaction not as a fleeting chat but as a persistent process.

• Background Work: You can start a session and let it run in the background while you work on a different file. The agent will notify you when it has completed its task or if it needs human input.
• Local vs. Cloud: Developers have the choice to run lighter agent tasks locally (for privacy and speed) or offload heavy "Thinking" tasks to the Cloud (using GPT-5.2 Pro via GitHub Copilot).
• Handoff: If a local agent gets stuck, you can "handoff" the context to the cloud-based GPT-5.2 agent, seamlessly escalating the problem to a smarter brain.

3.4 The GPT-5.1-Codex-Max Synergy

It’s important to note the synergy with GPT-5.1-Codex-Max. While GPT-5.2 is the general-purpose reasoning engine, Codex-Max (released just prior) was fine-tuned specifically for long-context coding and the "compaction" technique. GitHub Copilot appears to use a hybrid approach, routing raw logic problems to GPT-5.2 and syntax/API-heavy tasks to Codex-Max. This "mixture of experts" approach ensures that developers get the best of both worlds: the reasoning of a philosopher and the technical precision of a compiler.

Part 4: Benchmarks and the Battle for Supremacy

The "Code Red" was triggered by metrics. Gemini 3 was winning. So, where does GPT-5.2 stand?

4.1 Reasoning and Logic: GDPval & SWE-bench

OpenAI claims that GPT-5.2 Thinking achieves "expert-level" scores on a new benchmark called GDPval, which evaluates professional tasks like legal drafting and spreadsheet creation. The model reportedly beats or ties human professionals in 70.9% of comparisons. This is a massive leap from the ~38% success rate of GPT-5.1.

In the coding domain, the SWE-bench Verified scores are the gold standard. GPT-5.1-Codex-Max scored 74.9%, significantly higher than the ~52% of GPT-4o. GPT-5.2 is expected to match or exceed this, particularly in "Thinking" mode where it can self-correct logic errors before outputting code. This ability to "backtrack" and fix its own mistakes is what allows it to solve problems that stumped previous models.

4.2 The Hallucination Drop

For enterprise adoption, the most critical metric is often the hallucination rate. On HealthBench (medical accuracy), GPT-5 Thinking reportedly drops the error rate to 1.6%, compared to over 15% for GPT-4o.

This isn't just a marginal improvement; it's a threshold crossing. At 15% error, a model is a toy. At 1.6% error, it is a tool. This reliability is what enables the model to be trusted with autonomous tasks in Foundry and VS Code. It is the difference between "drafting an email" and "triggering a bank transfer."

4.3 GPT-5.2 vs. Gemini 3 vs. Claude

• vs. Gemini 3: Google’s model still holds advantages in native multimodality (processing video and audio natively in real-time) and raw context size (1M+ tokens). However, GPT-5.2 counters this with superior reasoning density. While Gemini might "read" a longer book, GPT-5.2 is claimed to understand the nuance of a complex argument better. OpenAI is betting that for business tasks, depth of thought matters more than width of context.
• vs. Claude: Anthropic’s Claude models have historically led in coding capability and "warm" tone. GPT-5.2 targets this directly. It adopts the "warm" conversational style of GPT-5.1 while boosting the coding accuracy to rival Claude’s "Sonnet" and "Opus" tiers. The integration with VS Code gives GPT-5.2 a massive distribution advantage over Claude, which largely lives in the browser or via API.

Part 5: Strategic Implications and Future Outlook

The release of GPT-5.2 is a watershed moment. It signals the end of the "hype cycle" and the beginning of the "deployment cycle."

5.1 The Commoditization of Intelligence

With GPT-5.2 Instant offering highly capable inference at $1.25 per million tokens, raw "intelligence" is becoming a commodity. The value capture in the industry is moving from the model itself to the orchestration—which is why Microsoft Foundry is so critical. The platform that can best ground these models in data, secure them, and integrate them into apps will win the enterprise. The model is just the engine; Foundry is the car.

5.2 The Rise of "Latency Arbitrage"

We are moving toward a world where enterprises will optimize their AI spend based on time. A customer service bot might use "Instant" (0 seconds reasoning, cheap) for greetings and password resets, but switch to "Thinking" (10 seconds reasoning, expensive) for handling complex refunds or complaints. This granularity allows businesses to optimize user experience and cost in real-time, treating compute as a dynamic resource.

5.3 The Death of "Prompt Engineering"?

With the "Thinking" models, the need for complex "chain-of-thought" prompting (where the user has to trick the model into being smart by saying "think step by step") is diminishing. The model now does this automatically. The skill set for developers is shifting from "Prompt Engineering" (formatting text) to "Agent Engineering" (designing workflows, tools, and guardrails).

5.4 Conclusion: The Green Light

For the developer and the enterprise architect, the message from the "Code Red" release is clear: The tools have changed. The friction of managing dumb models is giving way to the challenge of managing smart agents.

We are no longer just chatting with AI; we are managing it as it works alongside us. With GPT-5.2, the "Thinking" model is no longer a research curiosity—it is a production-grade utility available on Azure today. The "Code Red" is over. The "Agent Era" has begun.

For those of us building on the Microsoft stack, there has never been a more exciting—or more demanding—time to be writing code.

Detailed Comparisons

Technical Specifications of the GPT-5.2 Family

Comparative Analysis of Frontier Models

12-Month Total Cost of Ownership (TCO) Comparison

Deep Dive: How to Provision GPT-5.2 in Microsoft Foundry

For the architects reading this, here is your quick-start guide to getting GPT-5.2 running in your Azure environment today.

1. Access the Portal: Log in to the new Microsoft Foundry portal (formerly ai.azure.com).
2. Model Catalog: Navigate to the "Model Catalog" tab. You will see a "New Arrivals" banner highlighting the GPT-5.2 family.

Select Variant:

• Choose gpt-5.2 for the standard alias that routes to the balanced model.
• Choose gpt-5.2-thinking if you want to force the reasoning engine.
• Choose gpt-5.2-pro if you are deploying for a high-compliance use case (note: check your quota, as Pro requires higher TPM limits).

1. Deployment: Click "Deploy". You can choose "Standard" (Pay-as-you-go) or "Provisioned" (PTU) if you need guaranteed throughput for a production app.
2. Data Zones: During deployment, ensure you select the correct "Data Zone" (e.g., "Europe Data Zone") if you have residency requirements. This ensures your data—and the model's "thoughts"—never leave the geofence.

Code Update: Update your application code. If you are using the Azure OpenAI SDK, simply change the deployment_name variable.

• Tip: Experiment with the new reasoning_effort parameter in your API calls. Start with medium and adjust based on your latency tolerance.

Deep Dive: The "Agent" Workflow in VS Code

For developers, here is how to execute your first "Agentic" refactor:

1. Update Extensions: Ensure your "GitHub Copilot" and "GitHub Copilot Chat" extensions are on the latest December 2025 build.
2. Open the Chat Pane: Click the Copilot icon in the sidebar.
3. Switch Mode: At the top of the chat window, click the model picker dropdown and select "Agent" (this engages the GPT-5.2 backend).
4. Set Scope: Use the @workspace command to give the agent visibility into your whole project.

Prompt with Intent: Instead of code, write intent.

• Example: "@workspace Analyze the auth module. We are currently using a deprecated hashing algorithm. Plan a migration to Argon2, create the necessary utility functions, and update the login handler. Don't forget to update the requirements.txt file."

1. Review the Plan: The Agent will output a step-by-step plan. It might say: "1. Install Argon2. 2. Create hash_utils.py. 3. Modify login.py. 4. Run tests."
2. Execute: Click "Approve" or "Run." Watch as the agent opens files, writes code, and saves changes in real-time.
3. Verify: The agent will report back when finished. Run your test suite to confirm.

This workflow is fundamentally different from the "ask and copy-paste" loop of 2024. It is collaborative, autonomous, and powered by the reasoning density of GPT-5.2.

Final Word: The speed of innovation in this space is dizzying. But with GPT-5.2, we finally have a model that feels less like a magic trick and more like a reliable colleague. It thinks before it speaks. It remembers what you told it. And thanks to Microsoft Foundry, it is ready for business.

Welcome to the Agent Era.

Microsoft Ignite 2025 brought us something bigger than just another product update. The rebranding of Azure AI Foundry to Microsoft Foundry marks a fundamental shift in how Microsoft thinks about enterprise AI. This isn't just a name change—it's a strategic repositioning that places autonomous agents at the center of the platform, rather than models alone.

Let me walk you through the most significant updates and what they actually mean for those of us building intelligent applications.

The Rebrand That Actually Matters

When Microsoft drops "Azure" from a product name, pay attention. The move from Azure AI Foundry to Microsoft Foundry signals that agents are now being treated as first-class citizens in the Microsoft ecosystem, not just another Azure service. The platform is designed to integrate deeply with Microsoft 365, Teams, and the broader enterprise stack—positioning itself as the unified layer for agentic AI across your organization.

What makes this interesting is the timing. We're at an inflection point where proof-of-concept AI projects need to become production systems. Microsoft is betting that enterprises want a fully managed platform that handles the complexity of multi-agent orchestration, governance, and scaling. That's a smart bet, because building this infrastructure yourself is genuinely hard.

A Portal Redesigned for Agent Development

The new Foundry portal is a complete architectural reimagining. Instead of project-based workflows, everything is now organized around four core pillars: Agents, Tools, Knowledge, and Governance. This agent-centric approach makes sense when you consider that most of us start with the question "what do I want my agent to do?" rather than "what project should I create?"

The performance improvements are noticeable too. The previous portal could feel sluggish when navigating between sections. Microsoft claims significant speed improvements in this release, and from what I've seen, they've delivered on that promise. The new visual hierarchy and streamlined navigation make common workflows—like creating an agent, binding tools, and monitoring performance—much more intuitive.

The standout feature is the new Operate section, which gives you centralized management of all AI assets with real-time monitoring dashboards. This is exactly what production environments need: visibility into what your agents are doing, how they're performing, and where problems might be emerging.

Model Choice Without Compromise

Here's where things get really interesting. Microsoft Foundry is now the only cloud platform where you can access both OpenAI and Anthropic models in a single integrated environment. This is huge. You're no longer locked into a single model provider's ecosystem, which means you can choose the right model for each specific task.

The addition of Claude Opus 4.1, Sonnet 4.5, and Haiku 4.5 brings genuine competition to the platform. Claude models excel at complex reasoning tasks and have impressive context windows—sometimes you need that instead of GPT's capabilities. Cohere's integration fills another gap entirely, bringing specialized models for retrieval-augmented generation and enterprise-scale classification workflows.

With over 11,000 models now available across OpenAI, Anthropic, xAI, Meta, Mistral, and others, you have unprecedented flexibility. The strategic implications are clear: Microsoft wants to be the enterprise AI platform regardless of which models you prefer. That's differentiation that matters in a competitive market.

Foundry IQ: RAG That Actually Works

Traditional retrieval-augmented generation has always had limitations. Single-index patterns break down when you need to ground agents in multiple data sources simultaneously. Foundry IQ solves this by treating knowledge as a fully managed system rather than a collection of individual indexes.

What makes Foundry IQ compelling is its intelligence layer. Instead of simple semantic search, you get query planning and decomposition, iterative search refinement, and synthesis across results. These are agentic retrieval patterns—the system can reason about what information it needs and how to find it, rather than just returning similar documents.

The multi-source integration is particularly valuable. Your agents can pull context from Azure data services, Microsoft 365 SharePoint, Fabric data warehouses, and even public web sources through a single knowledge base. The system handles the complexity of different data formats and structures, with built-in support for text documents, images, PDFs, and structured data.

The Microsoft Purview integration for compliance and permission-aware retrieval addresses a real enterprise concern: how do you ground agents in company data without exposing information users shouldn't see? Foundry IQ handles this at the retrieval layer, which is the right place to solve this problem.

Agent Service: Production Infrastructure That Scales

The enhanced Foundry Agent Service is where the rubber meets the road for production deployments. Hosted agents eliminate infrastructure management entirely—you get automated scaling, high availability, built-in monitoring, and a serverless pricing model. This is critical for teams that want to focus on building agent capabilities rather than managing Kubernetes clusters.

The multi-agent workflow support is sophisticated. You can compose complex orchestrations directly within Foundry without needing Logic Apps or external workflow engines. Agent-to-agent communication, handoffs between specialized agents, and both parallel and sequential orchestration patterns are all supported natively. This unified orchestration plane includes policy enforcement, which means you maintain governance even in complex multi-agent scenarios.

Agent memory systems have been significantly enhanced. Short-term conversation memory, long-term semantic memory, and knowledge graph integration give agents the context they need to maintain coherent interactions over time. The memory persistence and retrieval mechanisms include governance controls, so you can manage what agents remember and for how long.

Model Context Protocol and the Tool Ecosystem

Microsoft's rebranding of its tool ecosystem as "Foundry Tools" creates a unified approach to agent capabilities. The Model Context Protocol integration is particularly clever—it provides a standard way for third-party tools to integrate with agents, creating an extensible ecosystem without requiring platform modifications.

The first-party tools cover essential operations: file handling, code execution, image generation and analysis, web search through Bing, and even browser automation and computer use capabilities in preview. These foundational tools give agents real-world capabilities beyond text generation.

The tool registry and centralized discovery make it easy to find and integrate capabilities. Tool versioning, lifecycle management, and usage analytics help you understand how agents are utilizing tools in production. Permission-based access through role-based access control means you can restrict which agents can use which tools based on organizational policies.

Enterprise Governance Without the Friction

The Foundry Control Plane addresses a question enterprises always ask: how do we maintain control at scale? The framework provides fine-grained role-based access control for agents, tools, models, and data. You can create and enforce organizational policies around model selection, tool usage restrictions, data access, and cost governance.

The compliance and audit capabilities generate comprehensive logs and compliance reports. Permission enforcement across deployments means policies are consistently applied regardless of how or where agents are deployed. Integration with Microsoft Purview ensures data governance is handled across the entire stack.

Perhaps most interesting is the new security model where agents receive managed identities through Entra IDs. Agents can authenticate with Azure services, receive fine-grained permissions, and leave audit trails of their actions. You can even apply conditional access policies to agent operations. This treats agents as genuine security principals in your environment, which is the right architectural approach.

Developer Experience That Gets Out of Your Way

The updated Python and C# SDKs bring multi-agent capabilities, streaming tool deltas, and improved performance. The new project endpoint pattern simplifies initialization and reduces boilerplate code. When you're building multiple agents, these small improvements in developer ergonomics compound quickly.

The Visual Studio Code integration is tight. Native Foundry support with streamlined scaffolding and deployment means you can build and test agents without leaving your editor. Pre-built templates and code snippets accelerate the initial development phase, getting you to working prototypes faster.

For existing Azure OpenAI users, the migration path is well thought out. You can upgrade while maintaining existing API endpoints and preserving all state—fine-tuning jobs, batch operations, and stored completions all carry over. The upgrade gives you access to the broader model catalog and new capabilities without forcing a complete rebuild.

What This Means for Enterprise AI

Microsoft is making a clear statement: agents are the new platform abstraction layer, similar to how microservices replaced monolithic architectures. By unifying agents, models, data, and governance in a single platform, Microsoft Foundry positions itself as the enterprise standard for agentic AI deployment.

The strategic investments tell the story. Up to five billion dollars in Anthropic, with Anthropic committing thirty billion in Azure compute purchases. These aren't small bets—they're long-term commitments to making Foundry the definitive platform for enterprise agents.

For organizations planning agentic deployments, Microsoft Foundry offers something genuinely valuable: a comprehensive platform that eliminates the complexity typically associated with multi-agent systems. You get model choice, production-ready infrastructure, enterprise governance, and a unified developer experience. That's a compelling package that addresses real pain points teams face when moving from prototype to production.

The November 2025 updates aren't just incremental improvements. They represent a maturation of the platform into something enterprises can confidently build on. Whether that confidence is warranted will depend on how these capabilities perform in production environments over the coming months. But the foundation Microsoft has built here is solid, and the strategic direction is clear.

The real announcements from the Book of News, no hype, no filler

Let me be direct: Day 1 of Ignite 2025 was architect-heavy. Not in a theoretical way—in a "Microsoft is shipping serious, production-grade infrastructure for agents" way.

Here's what happened, organized for people who actually build things.

The Foundational Shift: Microsoft Agent 365 Is Live

What it is: The control plane for managing agents at enterprise scale. Think of it as Active Directory for your AI workforce.

Why it matters: IT leaders have been asking one question for months: "We want AI, but how do we keep it from becoming chaos?" Agent 365 is Microsoft's answer.

What you get:

• Agent Registry — Complete visibility into every agent in your organization (including shadow agents)
• Access Control — Limit agent permissions the same way you limit user permissions
• Real-time Monitoring — See agent behavior and impact in a dashboard
• Security Integration — Works with Defender, Entra, and Purview to protect agents and data

Available now via the Frontier program.

My read: This was the governance bottleneck. Now you have the infrastructure to actually operate agents at scale.

Azure AI Foundry: The Agent Factory Gets Real

This is where the architecture actually lives

I need to be clear about something: This is the section that matters if you're building AI systems.

Foundry has been the place to experiment with agents. Starting yesterday, it becomes the operating system and factory for production agentic AI.

3.1.1: Unified MCP Tools — The Integration Problem is Solved

The reality: Enterprises have Systems. SAP, Salesforce, custom APIs, internal databases. Getting agents to talk to all of them without custom integration work was a nightmare.

Foundry solves this with a unified MCP tool catalog (preview):

What's new:

• Unified tool discovery — Find, connect, and manage MCP tools from a single interface in Foundry (public or private)
• Deep business integration — Logic Apps connectors expose 1,400+ systems (SAP, Salesforce, HubSpot, etc.) as MCP tools. Agents can now act on real business data in real time
• Pre-built AI services as MCP servers — Out of the box: transcription, translation, voice, intelligent document processing. No custom work
• Custom tool extensibility — Expose any API as a secure MCP tool via API Management. Your existing Logic Apps? They become agent capabilities

Why this matters to me as an architect:

This is the connective tissue. You've already invested in Logic Apps, Power Automate, existing integrations. Now all that becomes a capability layer for agents. You're not rebuilding; you're exposing.

3.1.2: Model Router (GA) — Let the Platform Choose the Model

This is available now. Production-ready.

The problem it solves: Which model should I use? GPT-4 for reasoning? Something faster for simple tasks? It depends on complexity, cost, latency, data residency requirements. Managing that per-request is chaos.

The solution: Model Router automatically selects the best model for the job.

What's new:

• Dynamically picks from 12 models: GPT-4.1, GPT-5, gpt-oss-120b, DeepSeek-v3.1, Llama variants, Grok 4, and more
• Optimizes for cost, performance, and complexity
• Delivers up to 40% faster responses and 50% lower costs in early customer deployments
• No code changes needed. Works transparently

The pattern: This moves model optimization from your dev team to the platform. As you scale to hundreds of agents, this becomes critical.

3.1.3: Foundry Agent Service — From Prototype to Production

This is the runtime. (Preview)

Foundry Agent Service turns Foundry from a design environment into a fully managed, enterprise-grade runtime for agents.

What's new:

Hosted Agents — Deploy agents built with Microsoft Agent Framework, LangGraph, CrewAI, OpenAI Agents SDK. No container management. No infrastructure headaches. Foundry handles autoscaling, observability, identity.

Multi-Agent Workflows (Preview) — Coordinate specialized agents across complex business processes. Use a visual designer or code-first API. Example: onboarding workflow with multiple agents handling different steps, with built-in recovery from failures.

Memory (Coming soon, preview later this year) — Agents retain context, preferences, conversation history across sessions. Secure, persistent, integrated into the runtime. This is huge—it's the difference between stateless chatbots and actual intelligent systems.

Microsoft Agent Framework — New open-source SDK unifying Semantic Kernel and AutoGen. Same runtime as Foundry Agent Service. Includes durable execution—agents automatically recover from timeouts and system faults. This is resilience built in.

Microsoft 365 and Agent 365 Integration — Deploy agents directly from Foundry to M365 productivity apps. They inherit security governance from Agent 365 automatically.

My assessment: This closes the gap between local prototyping and production deployment. You can build agents in your local dev environment, test them, then push to Foundry Agent Service with confidence. Foundry handles the rest.

3.1.4: Universal Context Layers — The Intelligence Layer

If Foundry Agent Service is the body, this is the brain.

Microsoft is unifying three intelligence layers:

Work IQ — Context from Microsoft 365 (your documents, emails, meetings, organizational knowledge). Agents understand what users are doing.

Fabric IQ (Preview) — Extends Power BI's semantic layer to operational data. Creates a live, connected semantic model of your entire enterprise. All data unified under one business logic. Agents can reason over consistent, governed data.

Foundry IQ (Preview) — Next-generation RAG built on Azure AI Search. A managed knowledge system for agents. Agents connect to one knowledge base that spans Azure services, SharePoint, Fabric, and the web. It automates RAG pipelines, performs agentic retrieval (query planning, iterative search, reflection, synthesis). Integration with Purview for governance.

Why this matters:

Good agents aren't just API-calling robots. They're decision makers that need context. These three layers give agents the information they need to reason intelligently, all while respecting governance and permissions.

I've built RAG systems. Half fail because you're pulling from the wrong sources or hallucinating context. Foundry IQ is attempting to solve that systematically—RAG as a managed service designed specifically for agents.

3.1.5: Foundry Control Plane — Operating Agents at Scale

This is governance for developers. (Preview)

Extends Agent 365 into the Foundry developer experience. You get:

Fleetwide Visibility — Observe and control 100% of your agents across Foundry, Entra, Copilot Studio, external platforms. See what they're doing in real time.

Behavioral Guardrails — Define policies that govern agent inputs, outputs, tools, responses. Prevent unsafe or misaligned behavior.

Lifecycle Management — Monitor agent health, performance, cost. Apply policies in real time.

Observability (GA) — Real-time tracing, continuous monitoring, evaluations. Integrated quality, risk, and safety evaluators. Red teaming capabilities.

Identity and Access — Entra Agent ID assigns each agent a verifiable identity. Ownership, lineage, access control.

Security — Defender for runtime threat detection. Purview for data protection.

Cost Management — AI Gateway provides centralized usage limits and cost controls.

Integrations coming: Palo Alto Networks and Zenity for extended governance across multicloud.

My read: This is what separates hobby agents from enterprise agents. You need visibility, governance, and control across the entire fleet. This layer provides it.

The Building Blocks: Agents You Can Actually Use (Today)

Sales Development Agent (Frontier preview)

A fully autonomous agent that researches prospects, qualifies leads, engages them with personalized outreach, then hands off qualified leads to your sales team.

Real scenario: 2 AM prospect research. No hallucinations. No fake emails. Just legitimate lead qualification happening while your team sleeps.

Workforce Insights Agent

Real-time org visibility. Leaders see tenure, roles, location, performance signals. Data-driven workforce decisions without waiting for monthly reports.

People Agent

Helps employees find colleagues by role, skill, expertise. "Who in my company knows about machine learning?" Suggests connections based on interaction history.

Learning Agent

Personalized microlearning. Tailored tips and courses. Configurable to team goals.

Teams Admin Agent (Preview)

Automates meeting monitoring, user provisioning, other admin tasks. IT admins stop doing repetitive work.

SharePoint Admin Agent (Preview)

Finds inactive sites, overshared content, permission sprawl. Applies policies automatically. Saves time, reduces risk, optimizes storage costs.

The pattern: These solve real work problems. Not theoretical. Actual pain that exists today.

Microsoft 365 Copilot: Office Apps Get Agent Capabilities

Word, Excel, PowerPoint Agents (Frontier)

Type a prompt in Copilot Chat. Get a fully formatted document, spreadsheet, or presentation.

Word Agent: Pulls from Work IQ (files, emails, meetings, org knowledge) to create strategic plans, policy documents, technical papers. Context-aware, not generic.

Excel Agent: Turns data into charts, summaries, insights. Builds forecasts, project plans, decision tools.

PowerPoint Agent: Creates presentations with storytelling and visual structure. Executive decks, strategic updates, market overviews.

Agent Mode (Enhanced and Expanded)

Now available in PowerPoint (Frontier preview). Enhanced in Excel and Word (Frontier). Already GA in Word for Copilot licensed users.

Copilot iteratively creates, edits, and formats—right in the app. Changes sync in real time.

Copilot in Outlook: Actually Useful on Mobile

Voice on iOS/Android — Summarize emails, draft replies, triage inbox. Hands-free. Actually works.

One-tap prompts — "Triage my inbox," "What needs my reply?" with guided workflow.

Schedule meetings from chat (GA) — "Schedule a meeting with Sarah and Michael next Tuesday." Copilot finds available times, books rooms, drafts agendas. All from chat.

Work IQ Gets Smarter

Conversational memory (Frontier) — Copilot remembers context across sessions. No more repeating yourself.

Metadata reasoning in SharePoint (GA) — Copilot understands structured metadata in document libraries. More accurate answers when searching org content.

New: Copilot Pages

Create interactive pages directly from Copilot Chat. Write code on pages, create interactive reports, prototype ideas. Share with team. Or convert to PowerPoint.

Power Platform Gets the Agent Treatment

New Power Apps Maker Workspace (Preview)

All in one place: planning, data modeling, app building. AI-powered.

Chat with Copilot to generate a multipage business app. Refine with point-and-click. Changes sync in real time.

Power Apps MCP Server (Preview)

Agents can now call the logic and data inside your Power Apps without custom integration work.

Translation: Your existing Power Apps become capabilities agents can consume.

Dataverse MCP Server (GA)

Dataverse becomes a standardized interface for agents. Whether you're building in Copilot Studio or GitHub Copilot in VS Code, agents interact with your data the same way.

Plus: Dataverse SDK for Python (preview) for building agentic workflows in Python.

Copilot Studio: Better Governance

Agent Evaluations (Preview) — Automated tests that grade agent performance. Catch regressions, compare versions, measure quality objectively.

Computer Use (Preview) — Agents can automate tasks across apps by interacting with UIs directly. Using hosted browser or cloud-managed PCs.

Entra Agent ID — Every agent gets a unique identity. Discover shadow agents, assign access controls, manage the fleet.

Dynamics 365 ERP: Moving from Static to Dynamic

ERP MCP Server Evolution (Preview)

Was: Fixed catalog of tools.
Now: Dynamic, configurable framework that adapts as business needs change.

Developers register new actions/APIs dynamically. No code rewrites. Agents connect directly to live business logic.

ERP Analytics MCP Server (Preview)

Governed access to ERP analytics data. Agents can reason over consistent, trusted business metrics and dimensions. Closes the loop between operational data and business performance.

Security: The Immune System for Agent Swarms

Agent 365 Security Integration

Defender, Entra, Purview all integrated. Protect agents from threats. Control their access. Protect the data they touch.

Entra Agent ID (Preview)

Every agent gets a cryptographically verifiable identity. Zero Trust for agents.

Purview Updates

DLP for Copilot Prompts (Preview) — If a prompt contains sensitive data, Purview blocks the response. Sensitive info doesn't get used for grounding.

AI Observability (Preview) — Full visibility into all agents. Security teams can manage risk proactively.

Security Copilot Agents

12 new agents embedded into Defender, Entra, Intune, Purview (preview). Automate threat hunting, risk management, compliance.

Windows and Edge: Making the Endpoint Agent-Native

Windows: MCP on Windows (Preview)

Agents can connect to line-of-business apps, File Explorer, System Settings. All under policy control.

Built-in Agent Connectors (Preview)

File Explorer: Agents can securely access local files. Natural language file search.

System Settings: Agents can modify device settings (Bluetooth, network, etc.).

Agent Workspace (Private preview)

Isolated, policy-controlled environment where agents run tasks without disrupting the user's main session.

Ask Copilot on Taskbar

New composer for OS-level AI interaction. Invoke Copilot from anywhere.

Edge for Business: Copilot Mode (Private preview)

Browser becomes a proactive AI partner.

Agent Mode — Multi-step actions on IT-approved websites.

Intelligent new tab page — Search, chat, files, personalized prompts in one box.

Daily Briefing — Curated meetings, tasks, priorities.

New for SMBs: Microsoft 365 Copilot Business

For companies under 300 people. $21/user/month.

Includes email summaries, document drafting, data analysis, meeting notes, plus custom agents.

Launch: December 2025.

Why it matters: Copilot pricing that doesn't require enterprise licensing complexity. This opens entire markets.

What I'm Actually Thinking About

This is not hype. This is a structural shift.

Foundry Agent Service closing the gap — You can build agents locally, test them, deploy to production infrastructure in Foundry. That's the missing piece that was holding adoption back.

MCP as the connective tissue — Your existing integrations (Logic Apps, Power Apps, Dataverse, ERP systems) become agent capabilities. That's not a small thing.

Agent 365 + Foundry Control Plane creating operational structure — Agents are no longer one-off experiments. They're managed, governed assets.

Foundry IQ as managed RAG — I've shipped RAG systems. The problem is always ground truth and hallucination. Foundry IQ is Microsoft's attempt to solve that as a platform service.

Security isn't an afterthought — Entra Agent ID, DLP for prompts, Purview integration, Defender for agents. The immune system is being built before the swarm gets too large.

Windows and Edge becoming agent-aware endpoints — Agent Workspace, MCP on Windows, computer use—the endpoint becomes an execution surface for agents, not just a screen.

The Unspoken Reality

There's a lot in preview. Foundry Agent Service, Agent Workspace, Computer Use, Memory, Fabric IQ, Foundry IQ, Foundry Control Plane—most of the interesting stuff isn't GA yet.

Don't expect this to be production-ready for most enterprises until mid-2026.

But Frontier program access is now. If you're serious about agents, you should be in it, testing these capabilities, understanding what's actually possible before your competitors do.

What You Should Actually Do

If you're building AI systems in Microsoft Cloud:

Get access to Foundry Agent Service. Understand the deployment model, the memory system, multi-agent workflows. This is the future runtime.

Map your existing integrations to MCP. Logic Apps, Power Automate, custom APIs. Start thinking about how these become agent capabilities.

Understand the governance story. Agent 365, Foundry Control Plane, Entra Agent ID, Defender for agents. You can't go to production without this figured out.

Start with one domain. Not "build 100 agents." Pick one area (operations, customer service, internal analytics) and pilot properly. Learn how agents behave at scale before you roll out organization-wide.

Invest in observability from day one. Agents are harder to debug than traditional code. You need proper logging, monitoring, audit trails before you're in production.

Final Thought

Microsoft is positioning Foundry as the engine for a new era of enterprise automation. Not "automation as a feature." Automation as infrastructure.

The architecture is sound. The platform is getting serious. But the real question isn't "Is this technically possible?"

It's: "Are you organized to govern and operate a fleet of intelligent agents at scale?"

Because that's where we're headed. And Ignite 2025 just handed you the blueprint.

The question is whether you'll start building now, or catch up later.

Full Book of News: https://news.microsoft.com/ignite-2025-book-of-news/

Want deeper dives? Look for the breakout sessions and on-demand videos in the Book of News for each announcement.

Introduction: Why Power Platform Licensing Can Seem Complicated

For newcomers and even experienced users, Microsoft Power Platform licensing can appear complex at first glance. With multiple products, various purchasing models, and specific use rights, it's easy to feel overwhelmed.

The purpose of this article is to provide a clear, easy-to-understand summary of the core licensing models, based exclusively on the official "Power Platform Licensing Guide" from November 2025. It is intended for business professionals, IT managers, and consultants looking for a practical overview without reading the full guide.

1. The Big Picture: What's Included in the Power Platform?

Microsoft Power Platform is a suite of low-code tools that allows businesses to create custom applications, automate workflows, and build external websites. This licensing guide focuses on the core components: Power Apps, Power Automate, Power Pages, and the underlying data platform, Microsoft Dataverse.

Crucially, as mentioned in the source document, licensing for Power BI and Microsoft Copilot Studio is covered in separate, dedicated guides. Therefore, this article will focus only on the components detailed in the main Power Platform Licensing Guide.

2. The Core Licensing Models: Understanding the Building Blocks

Understanding how licenses are acquired is key to navigating the platform. The following are the fundamental concepts for licensing Power Platform.

• Subscription Licenses: This is the primary way to buy, with plans typically billed annually. The main types are Per User, Per App/Flow, and Capacity-based.
• Pay-As-You-Go (PAYG): A flexible alternative where you pay for actual monthly usage. It is available for Power Apps, Power Pages, and Dataverse capacity.
• Add-on Licenses: These licenses extend the capabilities of base licenses. Clear examples are the Power Automate unattended RPA add-on and Dataverse capacity add-ons.
• "Seeded" Licenses (Included Rights): Select Microsoft 365, Office 365, Dynamics 365, and Windows licenses include limited Power Platform capabilities. It is important to note that these rights are often restricted to the context of the primary application, a concept known as "within app context."

3. Power Apps: From a Single App to Unlimited Use

Power Apps offers licensing schemes designed to fit different needs, from access to a single application to unlimited use across the organization.

Power Apps Premium vs. Power Apps per app

The Power Apps per app license is assigned to a user for a specific application in a specific environment. These licenses are stackable; a user might need several per app licenses to access multiple applications without requiring a Power Apps Premium license.

Note the significant difference in accrued Dataverse capacity—a key consideration for data-heavy applications. Each Power Apps Premium license contributes five times more database capacity to the tenant pool than a per app license.

Power Apps Pay-As-You-Go

The Power Apps per app meter allows organizations to pay based on the number of unique active users who open an app each month ($10 per active user/app/month), offering maximum flexibility.

Included Rights (Power Apps Basic)

Select Microsoft 365/Office 365 and Dynamics 365 licenses include limited Power Apps rights. The crucial rule here is "within app context." This means the apps and flows must relate to the data and context of the primary application (e.g., Dynamics 365).

4. Power Automate: Automating Tasks, Processes, and More

Power Automate presents the most diverse range of licensing options, which can be logically grouped for clarity.

Licenses for Users

• Power Automate Premium ($15 per user/month): This is the primary user license. It allows a user to create unlimited cloud flows (DPA) and run attended desktop flows (RPA). It also includes Process Mining capabilities.
• Power Automate per user ($15 per user/month): This license is for users who need to create unlimited cloud flows but do not require RPA or Process Mining.

Licenses for Processes & Bots

• Power Automate Process ($150 per bot/month): This licenses a single automation "bot" that can run unattended RPA or a business process accessible by unlimited users. It is licensed per bot, per environment.
• Power Automate per flow ($100 per flow/month): This model licenses a specific top-level flow to serve unlimited users within an organization. It requires a minimum purchase of 5 licenses, as it is designed for critical business processes that serve many users, justifying the initial investment.

Specialized & Add-on Licenses

• Power Automate Hosted Process ($215 per bot/month): A superset of the Process license that includes a Microsoft-hosted virtual machine for unattended RPA, eliminating the need for customer infrastructure.
• Power Automate unattended RPA add-on ($150 per bot/month): Adds an unattended bot to a qualifying Power Automate Premium or Power Automate per flow license.
• Power Automate Process Mining ($5,000 per 100 GB/month): A capacity-based add-on to the Power Automate Premium license for advanced process analysis and optimization.

Included Rights (Windows, M365, D365)

Limited Power Automate rights are included with Windows (for personal, attended desktop automation), Microsoft 365, and Dynamics 365. For the latter two, the "within app context" limitation applies again.

5. Power Pages: Licensing Your External Websites

Power Pages licensing is based on the type and volume of monthly website users.

There are two defined user types:

• Authenticated Users: Users who log in to the website via an authentication provider.
• Anonymous Users: Users who browse the website without logging in.

Capacity Pack Subscriptions

Licenses are purchased as monthly capacity packs.

• Authenticated users: 100 users per pack
• Anonymous users: 500 users per pack

The official guide indicates tiered pricing discounts for higher volumes. For example, while the base capacity pack for authenticated users (Tier 1) is $200 for 100 users, purchasing at Tier 3 (over 100,000 users) reduces the cost to $50 per pack.

Pay-As-You-Go Meters

As an alternative, PAYG meters allow you to pay for the actual number of unique authenticated and anonymous users who access the site each month.

Included Rights

The Power Apps Premium and Power Apps per app licenses include rights to access and run Power Pages websites. Additionally, select Dynamics 365 Enterprise licenses also include these rights if they are in the same environment.

6. Understanding Dataverse Capacity

Dataverse: The Foundation for Your Data

Dataverse is the fundamental data platform for Power Platform, and its capacity is a key part of licensing. There are three types of capacity:

• Database: Stores and manages table definitions and data.
• File: Stores attachments to notes or emails, such as documents, image files, videos, and PDF files.
• Log: Records changes to table and column data over time for auditing, compliance, and governance purposes.

Capacity is allocated at the tenant level as follows:

1. Default Capacity: A tenant receives a one-time base amount of capacity with its first Power Platform or Dynamics 365 subscription. For example, the first Power Apps Premium license provides a default of 20 GB of Database and 20 GB of File capacity.
2. Accrued Capacity: Additional capacity is added for each subsequent license purchased. For example, for every Power Apps Premium license, the tenant gets an additional 250 MB of Database and 2 GB of File capacity.

If more capacity is needed, it can be purchased via Dataverse capacity add-ons or consumed using pay-as-you-go meters.

7. Critical Rules and Common "Gotchas"

This section contains essential tips to avoid common licensing mistakes.

1. Multiplexing: Using hardware or software to pool connections, reroute information, or indirectly access the service does not reduce the number of licenses required. Every user who inputs or views data, whether directly or indirectly, must have an appropriate license.
2. "Within App Context" is Key: This rule is fundamental for included (seeded) licenses. The guide's example is clear: a flow connected to a Power App's SQL database is in context. However, a separate flow that updates an unrelated Oracle database is out of context and requires a full Power Automate license.
3. External Users Must Be Licensed: Non-employees, contractors, and agents who access Power Platform services must have appropriate licenses, just like internal users.
4. Unattended vs. Attended RPA: In short, an attended bot runs with user intervention (requires a Power Automate Premium license), while an unattended bot runs on its own (requires a Power Automate Process license or an unattended RPA add-on).

Conclusion: Your Path to Correct Licensing

In summary, the main licensing paths are:

• Power Apps/Automate Premium for users needing broad and unlimited capabilities.
• Per App/Flow/Process for licensing specific solutions or scenarios.
• Pay-As-You-Go for ultimate flexibility and for starting with small projects.

While this guide simplifies the key concepts, the official Microsoft Power Platform Licensing Guide is the definitive source of truth. Always consult the latest version of the official guide, which can be found on the Microsoft website, for detailed terms and conditions.

En su obra fundamental, "AI Engineering", Chip Huyen define con precisión este nuevo paradigma, sentando las bases teóricas de una práctica que ya está redefiniendo el desarrollo de software. La intención que tengo con el artíulo de hoy es la de analizar cómo el ecosistema de Azure no solo implementa los principios de Huyen, sino que los extiende, creando una plataforma industrializada que aborda los desafíos de escala, seguridad y autonomía que la teoría apenas comienza a explorar. Analizaremos cómo Azure AI Foundry y el Microsoft Agent Framework proporcionan una guía práctica y tangible para que arquitectos y líderes técnicos construyan la próxima generación de aplicaciones inteligentes.

Para ello, es imprescindible comprender primero el cambio de paradigma que desplaza el foco desde el MLOps tradicional hacia la nueva era de la Ingeniería de IA.

Este post está profundamente basado en la magistral obra de Chip Huyen, AI Engineering: Building Applications with Foundation Models. No es una exageración: este libro es una lectura obligada. Es la guía más completa y práctica que ofrece el conocimiento fundamental necesario para construir productos de IA que realmente funcionan y escalan a nivel empresarial, siendo un manual vital para el diseño de sistemas de principio a fin. Te lo recomiendo al 100%, y puedes conseguir tu copia aquí: [AI Engineering: Building Applications with Foundation Models]. Y sí, tengo que dejarlo claro: no me han pagado por esta publicidad (aunque sigo esperando pacientemente mis floating point operations gratuitos de la editorial O'Reilly). Mi entusiasmo es puramente profesional.

De MLOps a la Ingeniería de IA: Un Cambio de Paradigma Fundamental

Para construir soluciones AI-native efectivas, es estratégicamente crucial comprender la diferencia entre el MLOps tradicional, centrado en el ciclo de vida de modelos entrenados desde cero, y la emergente Ingeniería de IA, orientada a la adaptación de foundation models preexistentes. Chip Huyen establece tres distinciones clave que marcan este cambio de paradigma.

• Adaptación de modelos vs. Entrenamiento desde cero: El epicentro del trabajo de ingeniería se ha desplazado. En el ML tradicional, el esfuerzo se concentraba en el modeling y el training de modelos específicos para una tarea. Hoy, con la Ingeniería de IA, el foco está en la model adaptation: tomar un foundation model potente y de propósito general y adaptarlo a un caso de uso concreto mediante técnicas como el prompt engineering, RAG o fine-tuning.
• Escala y eficiencia: La Ingeniería de IA opera con modelos de un orden de magnitud superior a los de la era anterior. Estos modelos consumen una cantidad ingente de recursos computacionales, lo que impone una presión mucho mayor sobre la optimización de la inference. La eficiencia en el serving no es un añadido, sino un pilar fundamental del diseño.
• Enfoque en el producto y la experiencia de usuario: Mientras que el MLOps tradicional a menudo trataba el modelo como el núcleo del producto, la Ingeniería de IA sitúa la experiencia de usuario y la interfaz de producto en el centro. Dado que la interacción se produce a través del lenguaje natural y las respuestas son abiertas, la forma en que se presenta la información, se gestionan los errores y se guía al usuario se convierte en una parte crítica e inseparable de la propia solución de IA.

Para visualizar mejor estas diferencias, la siguiente tabla contrasta ambos enfoques:

Esta nueva centralidad en la adaptación, la eficiencia de la inference y la experiencia de producto exige un nuevo tipo de plataforma , una que vaya más allá de los pipelines de training para orquestar flujos de prompt engineering, RAG y serving de forma nativa, un desafío que Azure AI Foundry aborda de manera directa. Este cambio de paradigma está directamente impulsado por la llegada de una nueva clase de artefactos tecnológicos: los foundation models.

Foundation Models: El Corazón del Nuevo Ciclo de Desarrollo

Los foundation models son, como los define Chip Huyen, el "key catalyst" que ha impulsado la explosión de la Ingeniería de IA. Estos modelos, que incluyen tanto los Large Language Models (LLMs) como los Large Multimodal Models (LMMs), se caracterizan por dos aspectos fundamentales: son de propósito general y se entrenan mediante self-supervision sobre cantidades masivas de datos, lo que les permite aprender patrones complejos del lenguaje y del mundo sin necesidad de etiquetado manual.

Como señala Huyen, los foundation models marcan la transición de modelos específicos para una tarea a modelos de propósito general. Es precisamente por esta razón que el enfoque de la ingeniería se desplaza de la construcción de modelos a su adaptación, haciendo que el ciclo de desarrollo se centre en ajustar su comportamiento a tareas específicas. Huyen identifica tres técnicas de adaptación fundamentales que todo ingeniero de IA debe dominar:

1. Prompt Engineering: Es la forma más directa, económica y común de adaptar un modelo. Consiste en diseñar cuidadosamente las instrucciones (prompts) que se le proporcionan al modelo para guiar su respuesta hacia el resultado deseado.
2. Retrieval-Augmented Generation (RAG): Esta técnica permite superar las limitaciones del conocimiento interno del modelo conectándolo a bases de datos externas. El modelo utiliza esta información recuperada para "aumentar" su contexto y generar respuestas más precisas y fundamentadas en datos específicos y actualizados.
3. Finetuning: Implica un entrenamiento adicional del foundation model sobre un dataset más pequeño y específico de un dominio. Este proceso ajusta los pesos del modelo para especializar su comportamiento y mejorar su rendimiento en tareas muy concretas.

Este nuevo ciclo de vida —que consiste en construir, probar, iterar y desplegar (Build, Test, Iterate, Deploy) soluciones basadas en estas técnicas— exige una plataforma integrada que facilite y acelere cada una de sus fases.

Azure AI Foundry: La Plataforma Integral para la Ingeniería de IA

Industrializar el desarrollo de aplicaciones basadas en foundation models requiere una plataforma unificada que orqueste todo el ciclo de vida, desde la experimentación inicial hasta el despliegue y la monitorización en producción. Azure AI Foundry es la respuesta de Microsoft a este desafío, una plataforma diseñada para materializar los principios de la Ingeniería de IA a escala empresarial.

Veamos cómo sus componentes clave implementan los conceptos de Huyen:

Prompt Flow: Orquestando la Iteración Rápida

El prompt engineering y la creación de flujos complejos, como los de RAG, requieren una experimentación sistemática. Huyen subraya que la evaluación debe ser "una parte integral de cada paso del camino". Prompt Flow, una herramienta visual dentro de Azure AI Foundry, no es solo un constructor de flujos, sino una herramienta crítica para implementar esta evaluación sistemática. Facilita el diseño de flujos que combinan prompts, código Python y llamadas a herramientas, permitiendo evaluar variantes, comparar resultados y optimizar el rendimiento de forma ágil y estructurada antes del despliegue.

Azure AI Search: Potenciando el RAG a Escala Empresarial

Huyen identifica la mitigación de las alucinaciones como un desafío central. El patrón RAG es la principal estrategia para grounding o anclar las respuestas del modelo en hechos verificables. Para ser efectivo, este patrón necesita una implementación robusta, y Azure AI Search es precisamente eso: un servicio de búsqueda y recuperación de información de nivel empresarial que actúa como la base del conocimiento para los foundation models.

Ejemplo práctico: Imagina una aseguradora que necesita un chatbot para que sus agentes respondan preguntas sobre pólizas complejas. Un flujo RAG implementado con Azure AI Search podría:

1. Recibir la pregunta del agente: "¿Cuál es la cobertura para daños por agua en la póliza Premium Plus?"
2. Utilizar Azure AI Search para buscar en la base de conocimiento interna (PDFs de pólizas, manuales) los fragmentos más relevantes sobre "daños por agua" y "Póliza Premium Plus".
3. Inyectar esos fragmentos como contexto en el prompt enviado a un modelo como GPT-5.
4. El modelo genera una respuesta precisa y fundamentada exclusivamente en la documentación oficial de la empresa.

En este escenario, Azure AI Search no es solo un motor de búsqueda; es el mecanismo de grounding que garantiza la fiabilidad y veracidad de la respuesta, transformando un LLM de propósito general en un experto de dominio fiable.

Azure Container Apps y Azure Functions: Despliegue y Serving Flexible

Uno de los pilares de la Ingeniería de IA, según Huyen, es la gestión eficiente de la inference a gran escala. Las arquitecturas monolíticas no son adecuadas para la naturaleza a menudo variable de las cargas de trabajo de IA. Herramientas como Azure Container Apps y Azure Functions resuelven este desafío, permitiendo desplegar los puntos de inference como microservicios o funciones sin servidor. Esto proporciona una elasticidad y una eficiencia de costes superiores, escalando los recursos solo cuando son necesarios y simplificando enormemente la operativa del serving.

La orquestación de flujos es un pilar fundamental, pero la verdadera frontera de la ingeniería de IA reside en dotar a estos sistemas de mayor autonomía.

Microsoft Agent Framework: De los Prompts a los Sistemas Autónomos

Mientras que un sistema RAG recupera información para responder preguntas, el siguiente nivel de sofisticación en la IA lo representan los agentes, que no solo recuperan información, sino que actúan sobre ella. Chip Huyen los define de forma concisa como "AIs that can plan and use tools". Un agente es un sistema capaz de descomponer un objetivo complejo en una secuencia de pasos, seleccionar las herramientas adecuadas para cada paso y ejecutarlas de forma autónoma.

El Microsoft Agent Framework proporciona la tecnología para construir estos sistemas componibles y autónomos. Permite definir un conjunto de herramientas (APIs, bases de datos, funciones) y dotar a un LLM de la capacidad de orquestar su uso para alcanzar un objetivo. Este paradigma de agentes es la máxima expresión del enfoque en el producto que Huyen defiende. La "inteligencia" ya no reside en una única respuesta del modelo, sino en la capacidad del sistema para comprender una intención compleja del usuario y ejecutar una cadena de valor de múltiples pasos para satisfacerla de forma autónoma.

Ejemplo práctico: Pensemos en un agente de soporte técnico diseñado para resolver una incidencia de un cliente. Ante la solicitud "Mi pedido no ha llegado", el agente, impulsado por el Microsoft Agent Framework, podría ejecutar el siguiente plan de forma autónoma:

1. Utilizar la herramienta CRM_lookup para obtener los detalles del pedido del cliente a partir de su email.
2. Utilizar la herramienta database_query para consultar el estado del envío en la base de datos de logística con el ID del pedido.
3. Utilizar la herramienta notification_service para enviar una actualización proactiva al cliente por email, informándole del estado exacto y la fecha de entrega estimada.

Este nivel de autonomía nos obliga a pensar en la arquitectura de una forma holística e integrada.

Arquitectura Práctica AI-Native en Azure

Diseñar aplicaciones AI-native requiere abandonar los patrones de la arquitectura de software tradicional y adoptar un enfoque por capas centrado en la inteligencia. Una arquitectura moderna en Azure puede conceptualizarse de la siguiente manera:

La Capa de Datos y Conocimiento

Es el fundamento de cualquier sistema de IA robusto. Aquí reside el contexto que "aterriza" (grounding) las respuestas del modelo en la realidad de la empresa. Está fundamentada en servicios como Azure AI Search para datos no estructurados y otras bases de datos (SQL, NoSQL) para información estructurada. Esta capa alimenta el patrón RAG y proporciona los datos sobre los que operan los agentes.

La Capa de Modelo e Inteligencia

Es el cerebro del sistema. Azure AI Foundry se utiliza para orquestar los flujos de prompt engineering y RAG, adaptar los modelos mediante fine-tuning y desplegarlos de forma eficiente. Sobre esta capa, el Microsoft Agent Framework implementa la lógica de negocio, el razonamiento y la orquestación de herramientas, permitiendo al sistema planificar y ejecutar acciones complejas.

La Capa de Experiencia y Producto

Esta es la capa que interactúa con el usuario final. Como subraya Huyen, su diseño es crítico. No se trata solo de una interfaz de chat, sino de todo el conjunto de interacciones que guían al usuario, gestionan las expectativas y presentan los resultados de la IA de forma clara y útil. Puede ser una aplicación web, una extensión de Microsoft 365 o una API consumida por otro servicio.

Para ser verdaderamente robusta, una arquitectura completa debe incorporar mecanismos de evaluación y mejora continua.

Evaluación, Observabilidad y Seguridad: El Cierre del Ciclo

Chip Huyen afirma que la evaluación es "one of the hardest, if not the hardest, challenges of AI engineering" debido a la naturaleza abierta y probabilística de los foundation models. No hay una única respuesta correcta, lo que hace que la validación sea un desafío complejo y multifacético. Para superar esto, es fundamental establecer feedback loops (bucles de retroalimentación) que permitan una mejora continua del sistema. Huyen nos recuerda el "desafío de la última milla": "Puede que lleve un fin de semana construir una demo, pero meses, e incluso años, construir un producto".

Esta necesidad teórica se traduce en herramientas prácticas en Azure. Servicios como Application Insights son cruciales para la observabilidad y para navegar esa difícil "última milla". Permiten monitorizar en producción métricas clave de rendimiento como la latencia de las respuestas, el coste por inferencia y, fundamentalmente, la calidad de las generaciones (por ejemplo, a través de puntuaciones de relevancia o coherencia). Estos datos son vitales para detectar derivas en el comportamiento del modelo y para identificar oportunidades de mejora, transformando un prototipo prometedor en una aplicación fiable y de grado de producción.

Finalmente, en sistemas donde los agentes pueden ejecutar acciones, la seguridad y la trazabilidad son primordiales. Es indispensable registrar cada acción realizada por un agente, junto con su razonamiento, para permitir auditorías y garantizar un comportamiento seguro y predecible.

Conclusión: El Ingeniero de IA como Arquitecto del Futuro

Este recorrido nos ha llevado desde los conceptos fundamentales de la Ingeniería de IA, definidos por Chip Huyen, hasta su implementación práctica en el ecosistema de Microsoft Azure. Hemos visto cómo la disciplina ha evolucionado desde el MLOps tradicional hacia un paradigma centrado en la adaptación de foundation models, y cómo plataformas como Azure AI Foundry y marcos como el Microsoft Agent Framework proporcionan las herramientas necesarias para construir, desplegar y operar estas soluciones a escala.

La visión del Ingeniero de IA moderno se aleja de la del científico de datos que entrena modelos en un laboratorio. Se asemeja más a la de un arquitecto de sistemas inteligentes complejos, un profesional que integra de forma experta los datos, los modelos de IA y la experiencia de producto para crear soluciones coherentes y de alto valor.

Plataformas como Azure AI Foundry y  Microsoft Agent Framework representan una arquitectura de opinión para la ingeniería de IA. Dominar este ecosistema no es solo aprender a usar herramientas, sino adoptar una filosofía probada en batalla para construir el futuro de la IA empresarial. Es una filosofía que anticipa y resuelve la próxima generación de desafíos de ingeniería, posicionando a los arquitectos que la dominen en la vanguardia de la innovación tecnológica, listos para construir el software del mañana.

Has desplegado un LLM de última generación. En las demos, es brillante. Responde a preguntas complejas, genera código y escribe textos con una fluidez impresionante. Pero al conectarlo a tus procesos de negocio, la realidad se te viene encima: no conoce tus productos, no entiende tu jerga interna y, desde luego, no tiene ni idea de quién fue el cliente estrella del último trimestre. Es un genio amnésico dentro de tu propia empresa.

Este es el abismo que separa a una IA genérica de un verdadero activo empresarial. Y para cruzarlo, nos encontramos con una bifurcación crítica, una decisión que definirá la personalidad y la capacidad de nuestra IA: ¿debemos entrenarla para que adquiera una nueva habilidad (Fine-Tuning) o debemos darle acceso a nuestra biblioteca de conocimiento para que pueda consultar información en tiempo real (RAG)?

Cuidado, porque la respuesta no es trivial y la intuición a menudo nos lleva por el camino equivocado. No se trata de elegir una tecnología "mejor", sino de aplicar el patrón de diseño correcto para el problema correcto. Una mala elección aquí no solo dispara los costes y la complejidad, sino que puede resultar en una solución que, en el mejor de los casos, es decepcionante. En este artículo vamos a desmitificar esta elección, analizando desde la arquitectura del software cuándo y por qué debemos optar por un camino u otro.

Patrón 1: Fine-Tuning para la Especialización del Comportamiento

Un arquitecto no elige el Fine-Tuning para "añadirle datos" a un modelo. Ese es el principal error conceptual. Elegimos Fine-Tuning cuando el objetivo es modificar el comportamiento intrínseco del modelo, para enseñarle una habilidad o un estilo de razonamiento que no se puede describir eficazmente en un prompt. Se trata de reescribir parte de su ADN neuronal.

El objetivo no es inyectar conocimiento, sino especializar la habilidad.

Caso de Uso Concreto: Automatización de Informes de Sostenibilidad (ESG)

Imaginemos una consultora que genera informes de Sostenibilidad, Medio Ambiente y Gobernanza (ESG) para empresas del IBEX 35. Estos informes no son un simple resumen de datos; siguen una estructura narrativa muy específica, utilizan una terminología regulatoria precisa y deben adoptar un tono formal y cauteloso.

• El Problema: Un modelo base, incluso con RAG, puede recuperar los datos correctos (emisiones de CO2, políticas de diversidad), pero fallará estrepitosamente en la generación del texto final. Producirá un texto genérico, probablemente con un estilo americano, y no respetará la sutil estructura y el lenguaje que exigen los reguladores europeos.

La Solución Arquitectónica (Fine-Tuning):

Curación del Dataset: El trabajo más arduo. Se crea un dataset de alta calidad con cientos (o miles) de pares prompt/completion.

• Prompt: Podría ser una estructura de datos JSON con los KPIs del cliente: {"empresa": "ACME Corp", "emisiones_scope1": 45000, "brecha_salarial": 0.08, "iniciativas_comunidad": ["..."]}.
• Completion: El párrafo exacto, redactado por un experto humano, tal y como debería aparecer en el informe final, con el tono y la estructura perfectos.

1. Selección del Modelo: No siempre necesitamos el modelo más grande. Para una tarea tan específica, un modelo más pequeño y eficiente como Phi-3-medium, ajustado con precisión, puede superar a un GPT-5 genérico en esta tarea concreta, con menor latencia y a una fracción del coste de inferencia.
2. Proceso en Azure AI Foundry: Se inicia un trabajo de Fine-Tuning, donde el modelo base aprende los patrones de conexión entre los datos de entrada y la prosa de salida deseada. El resultado es un nuevo endpoint de modelo, un activo especializado para la empresa.

Decisión del Arquitecto: Optamos por Fine-Tuning porque el "qué" (los datos) es variable, pero el "cómo" (la estructura, el tono, la jerga) es un patrón de comportamiento estable y complejo que queremos internalizar en el modelo. El coste computacional inicial se justifica porque reduce drásticamente la complejidad del prompt en producción y garantiza una consistencia que RAG por sí solo no puede ofrecer.

Patrón 2: RAG para la Inyección de Conocimiento Contextual y Dinámico

RAG es el patrón de elección cuando el modelo tiene el comportamiento de razonamiento adecuado, pero carece del contexto específico y actualizado para responder. La filosofía aquí es la separación de responsabilidades: el LLM es un motor de razonamiento universal, y la base de conocimiento empresarial es un sistema desacoplado y dinámico.

El objetivo no es cambiar al modelo, sino informarlo en tiempo real.

Caso de Uso Concreto: Asistente de Diagnóstico para Técnicos de Mantenimiento

Pensemos en una empresa que fabrica maquinaria industrial compleja (ej. turbinas eólicas). Sus técnicos de campo se enfrentan a códigos de error y necesitan acceder a manuales de reparación, historiales de mantenimiento y boletines de servicio. Esta base de conocimiento es masiva (cientos de miles de páginas en PDFs), se actualiza constantemente y es absolutamente propietaria.

• El Problema: Ningún modelo pre-entrenado conoce el significado del "código de error 27B en una turbina modelo V-112". Un Fine-Tuning sería inviable y absurdo, ya que la información cambia con cada nuevo boletín de servicio.

La Solución Arquitectónica (RAG):

Pipeline de Ingesta de Conocimiento:

• Origen de Datos: Un Azure Blob Storage donde se depositan los manuales en PDF, esquemas, etc.
• Pre-procesamiento: Un servicio como Azure AI Document Intelligence es crucial aquí. No podemos tratar un PDF técnico como texto plano. Necesitamos extraer tablas, entender diagramas y respetar la estructura del documento antes de procesarlo.
• Chunking (Troceado): Es una decisión de diseño crítica. ¿Troceamos por tamaño fijo? ¿O usamos un troceado semántico que intente mantener párrafos o secciones completas? Para manuales técnicos, el troceado semántico suele dar mejores resultados.

Capa de Indexación y Búsqueda (El Corazón de RAG):

• Vectorización (Embedding): Cada "chunk" se convierte en un vector numérico usando un modelo como text-embedding-3-small.
• Vector Store: Azure AI Search actúa como nuestro almacén vectorial. Implementamos una estrategia de búsqueda híbrida. Esto es clave. La búsqueda vectorial encontrará párrafos semánticamente similares a "el motor se sobrecalienta", pero la búsqueda por palabras clave (keyword search) es indispensable para encontrar referencias exactas a "código de error 27B" o "número de pieza 84A-C3".

Orquestación en Tiempo de Ejecución (Runtime):

• Prompt Flow: Aquí se diseña el flujo lógico.
• El prompt del técnico ("Tengo un error 27B en una V-112, ¿causas probables?") se vectoriza.
• Se realiza la consulta híbrida contra Azure AI Search, recuperando los 5 "chunks" más relevantes.
• Se construye un prompt final que incluye la pregunta original y el contexto recuperado: "Basándote ESTRICTAMENTE en los siguientes documentos recuperados, responde a la pregunta del usuario. Documentos: [...]. Pregunta: [...]".
• Este prompt se envía a un modelo potente en razonamiento como GPT-5, que no inventa nada, sino que sintetiza la respuesta a partir del contexto proporcionado.

Decisión del Arquitecto: RAG es la única opción viable. Desacopla la base de conocimiento (que puede crecer y cambiar a diario) del modelo de lenguaje. La solución es más auditable y fiable, ya que cada respuesta puede ser trazada hasta los documentos fuente recuperados, eliminando casi por completo el riesgo de alucinaciones. El coste es por consulta (OPEX), pero evitamos el coste masivo y la rigidez de un reentrenamiento constante.

El Framework de Decisión del Arquitecto: Conocimiento vs. Comportamiento

Para tomar la decisión correcta, debemos analizar dos ejes principales:

La Arquitectura Híbrida: El Patrón Definitivo

Los casos de uso más avanzados no se conforman con una u otra. Implementan una arquitectura híbrida que combina lo mejor de ambos mundos.

Volvamos al asistente de informes ESG. Nuestra arquitectura ideal sería:

1. Un modelo base ajustado (Fine-Tuned): Este modelo ya es un experto en generar la narrativa, la estructura y el tono de un informe ESG. Su habilidad principal es la redacción especializada.
2. Un sistema RAG conectado: Este sistema se conecta a las bases de datos internas de la consultora y a las fuentes de datos del cliente.

Cuando se solicita un nuevo informe, el orquestador (Prompt Flow) primero utiliza RAG para recuperar los KPIs y datos numéricos actualizados del cliente. Luego, alimenta estos datos en el modelo ajustado (fine-tuned), que no solo los resume, sino que los teje dentro de la narrativa compleja y el formato predefinido que ha aprendido, produciendo un borrador de informe de altísima calidad.

Esta separación es la clave de una buena arquitectura de software: un componente especializado en el conocimiento (RAG) y otro en la habilidad (Fine-Tuning), trabajando en conjunto.

La elección entre Fine-Tuning y RAG no es una preferencia, es una decisión de diseño basada en un análisis riguroso de los requisitos del negocio. Como arquitectos, nuestro trabajo es entender la naturaleza del problema (si es de conocimiento o de comportamiento) y diseñar una solución robusta, escalable y fiable utilizando las herramientas a nuestra disposición. El verdadero valor no reside en el modelo, sino en la arquitectura que lo rodea.

Hace apenas unos días Microsoft lanzó en "public preview" su nuevo Agent Framework, y sinceramente… esto marca un antes y un después para cualquiera que esté construyendo soluciones con IA.

En mi opinión no es "hype" o "purpurina". Es un movimiento estratégico muy bien medido. Vamos por partes

De los flujos y hacks… a los agentes de verdad

Hasta ahora, montar un sistema con varios agentes era un pequeño infierno: piezas sueltas, librerías experimentales y mucha cinta adhesiva para que todo no se rompiese en producción.

Microsoft empezó a poner orden con Semantic Kernel y AutoGen: uno para integrar LLMs con lógica de negocio, el otro para probar ideas de agentes colaborativos. Potentes, sí, pero había que elegir entre innovar rápido o tener algo estable. No podías tenerlo todo.

Qué es exactamente Microsoft Agent Framework

Es la base abierta para construir agentes de IA y flujos multiagente en serio, sobre .NET y Python.

Microsoft ha juntado lo mejor de sus dos “inventos” anteriores y le ha añadido algo que hasta ahora no teníamos: gobernanza y escalabilidad de verdad desde el minuto uno.

Algunas cosas que trae de serie:

1. Agentes individuales que pueden llamar modelos, usar herramientas MCP e integrarse en procesos reales.

2. Flujos complejos en forma de grafos, con control de estado y colaboración con humanos si hace falta.

3. Observabilidad y cumplimiento integrados, sin tener que montar 40 dashboards aparte.

Por qué esto importa (de verdad)

Si alguna vez has intentado llevar algo de IA a producción en una empresa, sabes de qué hablo:

Cada pieza es de su padre y de su madre, nada encaja bien y la trazabilidad brilla por su ausencia.

Con Agent Framework:

Puedes conectar APIs, sistemas internos y externos, todo con estándares abiertos.

Lo que prototipas localmente se puede escalar a Azure AI Foundry sin rehacer medio sistema.

Y puedes hacerlo con la tranquilidad que esperan los equipos de seguridad y compliance.

Esto va más allá del buzzword “agentic”

Este lanzamiento no es una moda pasajera: es el golpe sobre la mesa de Microsoft para liderar la nueva etapa de la IA empresarial.

Básicamente, ya no tienes que elegir entre “moverte rápido” o “cumplir normas”: puedes hacer las dos cosas a la vez.

Además, al ser abierto, empuja a toda la industria hacia un estándar común. Se acabó el “cada uno con su framework”. Esto acelera todo.

Un vistazo rápido a cómo se posiciona

Lo relevante no es solo la potencia técnica. Es que Microsoft ha cerrado el círculo: desarrollo → observabilidad → cumplimiento, todo conectado.

Azure AI Foundry + Agent Framework = combo ganador

Piensa en Foundry como la fábrica, y en Agent Framework como el motor.
Prototipas en local, y cuando está listo, lo subes a Foundry para tener despliegue seguro, compliance y escalabilidad real.

Sin fricciones. Sin rehacer nada.

Creo que Microsoft ha puesto una base seria para construir agentes empresariales de verdad.

Esto no es solo para frikis de la IA (🙋‍♂️), es para toda empresa que quiera llevar estos sistemas a producción sin morir en el intento.

Prepárate, porque esto va a cambiar cómo diseñamos software en los próximos años.

Y sí, el código ya está aquí. Así que… no digas que no te avisé 😉

https://github.com/microsoft/agent-framework

En el mundo enterprise, la IA generativa ha pasado de “demo bonita” a plataforma de producto. Hablamos de catálogos de modelos, RAGs listos para producción, agentes con tool-calling, guardrails, observabilidad y gobernanza real. En el centro del ring: Azure AI Foundry. Pero el combate es serio: AWS Bedrock, Google Vertex AI, IBM watsonx, Databricks Mosaic AI, Snowflake Cortex AI, Oracle OCI Generative AI y NVIDIA NeMo/NIM compiten de verdad.

Con este post pretendo explicar qué ofrece cada plataforma, ventajas/inconvenientes, qué modelos traen, y cuándo elegir cada una.

El contendiente a vencer: Azure AI Foundry

Qué es

Plataforma unificada para diseñar, probar, desplegar y operar aplicaciones generativas y agentes en Azure. Integra identidad (Entra ID), secretos (Key Vault), datos (FABRIC, BBDDs), búsqueda (Azure AI Search) y Content Safety.

Modelos

Acceso prioritario a la familia OpenAI (GPTs, DALL·E, GPT-OSS, etc) y catálogo creciente de terceros y open-weights (Llama, Mistral, Cohere, Stability, etc.), todos bajo una API/SDK.

Piezas clave

• Playgrounds y prompting guiado con historial/versionado.
• RAG “Use your data”: indexado, chunking, grounding y conectores listos.
• Agentes gestionados: tool-calling, memoria, orquestación multi-paso, telemetría.
• Guardrails (Content Safety, Prompt Shields) y evaluación continua (trazas, A/B, canary).
• SDKs (Python/JS/.NET/Java) + integración con VS Code, DevOps/GitHub e IaC.

Ventajas

• Time-to-value altísimo si vives en Microsoft 365 / Dynamics.
• Seguridad y cumplimiento “que simplifica auditorías".
• Catálogo amplio sin cambios de mentalidad ni de runtime.

Inconvenientes

• Coste de plataforma alto si no aprovechas su integración end-to-end.
• Dependencia fuerte del ecosistema Microsoft (lo cual es feature o bug según tu caso).

Ideal para

Organizaciones Azure-first que quieren copilotos y agentes pegados a M365/Teams/SharePoint/FABRIC/Dynamics con RAG y guardrails listos desde el día 1 (aunque tambien es perfectamente válido para cualquier otro ecosistema).

Los (verdaderos) rivales

1) Google Vertex AI — “Gemini + datos = velocidad real”

Qué es

Plataforma unificada de IA de Google con modelos propios (familia Gemini, multimodal y contexto largo) y Model Garden con terceros.

Modelos

Gemini (texto, código, visión), más Llama, Mistral, Claude, AI21 según región.

Piezas clave

• Generative AI Studio y Agent Builder (agentes con herramientas y grounding).
• RAG con Vertex AI Search/Grounding y acople nativo a BigQuery/GCS (Google Cloud).
• MLOps serio: pipelines, drift, versiones y monitorización.

Ventajas

• Multimodal fuerte y contexto largo (ideal para documentos brutos, código, imágenes).
• Si tus datos viven en BigQuery, el RAG es plug-and-play (latencia y gobernanza a favor).

Inconvenientes

• Si no eres GCP-first, hay fricción (identidad/red/operación).
• Disponibilidad de algunos modelos varía por región/proyecto.

Ideal para

Equipos data-driven en GCP que quieren agentes y RAG sobre BigQuery sin mover datos.

2) AWS Bedrock — “Marketplace de modelos”

Qué es

Capa serverless con catálogo multivendor y tooling para agentes/RAG integrada en AWS.

Modelos

Anthropic Claude, Meta Llama, Mistral, Cohere, AI21 Jurassic, Stability (SD) y Amazon Titan.

Piezas clave

• Agents (acción sobre APIs/Lambda, memoria, planificador).
• Flows (orquestación visual end-to-end).
• Knowledge Bases (RAG administrado con conectores a S3/Kendra).
• Evaluations y guardrails con telemetría en CloudWatch.

Ventajas

• Variedad real de modelos sin reescribir la plataforma.
• Cero GPUs que gestionar: escalado, throttling y throughput gestionados.

Inconvenientes

• Si necesitas un modelo fuera del catálogo, toca integrar por tu cuenta.
• El “lego AWS” exige disciplina (IAM, redes, políticas). Algo mas "lioso que Azure", aunque conceptualmente hay que hacer lo mismo (cuestión de gustos).

Ideal para

AWS-first que quieren iterar con varios modelos y desplegar agentes con acción sobre Lambda/Step Functions sin pelearse con infraestructura.

3) IBM watsonx.ai — “Gobernanza y soberanía por diseño”

Qué es

Suite enterprise: watsonx.ai (modelos), watsonx.data (lakehouse) y watsonx.governance (riesgo, sesgos, lineage). Cloud o on-prem/air-gapped (OpenShift/Cloud Pak).

Modelos

Granite (IBM) y open-weights (Llama, StarCoder, etc.). BYO-model real.

Piezas clave

• Entrenamiento/afinación con propiedad intelectual de tu lado.
• Governance exhaustivo (políticas, explicabilidad, auditoría).
• Integración con datos gobernados (watsonx.data).

Ventajas

• Cumplimiento y soberanía en sectores muy sensibles (banca, sector público, salud).
• Control fino de ciclo de vida de modelos propios.

Inconvenientes

• Menos “plug-and-play” que un hyperscaler tipo AWS o Azure.
• Modelos base más pequeños que los tope de gama generalistas.

Ideal para

Entornos hiper-regulados y on-prem donde la prioridad es gobernar y explicar cada decisión del modelo.

4) Databricks Mosaic AI — “GenAI pegado al lakehouse”

Qué es

Capa de RAG/Agentes/Evaluación/Serving dentro del lakehouse.

Modelos

DBRX (open-weights, MoE) y ecosistema abierto.

Piezas clave

• Vector Search, Model Serving, Agent Framework.
• Evaluate/Traces (observabilidad y AI-judging integrados).

Ventajas

• Ciclo build-measure-fix-redeploy rapidísimo.
• Menos movimiento de datos, menos latencia.

Inconvenientes

No es un hub multivendor tan ancho como un hyperscaler.

Ideal para

Equipos con ETL/BI/ML en Databricks que quieren GenAI sobre el mismo runtime.

5) Snowflake Cortex AI — “IA dentro del warehouse”

Qué es

Funciones LLM serverless y agentes dentro del Data Cloud.

Modelos

Snowflake Arctic (LLM + embeddings, open-weights) y operadores nativos.

Piezas clave

• Cortex Analyst (NL→SQL), AISQL, Cortex Search, Cortex Agents.

Ventajas

• Gobernanza y latencia al mantener el cómputo cerca de la tabla.
• Ideal para analítica aumentada y self-service con IA.

Inconvenientes

• Menos amplitud de modelos/plantillas de agente “generalistas”.

Ideal para

Snowflake-first que quieren IA sin sacar datos del warehouse.

6) Oracle OCI Generative AI — “Multi-modelo para empresas Oracle”

Qué es

Oferta generativa enterprise para clientes OCI con Cohere, Llama y acuerdos para ampliar catálogo.

Ventajas

• Integración nativa con datos y apps de Oracle.
• Contratos enterprise y soporte al estilo Oracle.

Inconvenientes

• Catálogo y tooling de agentes menos maduros que los tres grandes.

Ideal para

Ecosistemas Oracle que buscan GenAI sin fricción en su stack.

7) NVIDIA NeMo / NIM — “Control total, cloud-agnostic y on-prem”

Qué es

NeMo (curación, afinación, evaluación, guardrails, observabilidad) + NIM (microservicios de inferencia). Pensado para on-prem/multi-cloud/edge con tus GPUs.

Modelos

Open-weights (Llama/Nemotron y otros) y toolkits para personalizar/servir.

Ventajas

• Soberanía, rendimiento y evitar lock-in.
• Ruta clara de PoC → plataforma propia.

Inconvenientes

• Requiere equipo de ingeniería de plataforma y MLOps.

Ideal para

Quien quiere su plataforma de agentes/LLM con control fino de coste, latencia y privacidad.

Comparativa rápida

Nota: SAP Generative AI Hub (sobre AI Core) y Salesforce Einstein 1 juegan en verticales (ERP/CRM). Si ya vives ahí, considera su trust layer y conectores nativos.

Decisiones prácticas

• Azure-first / Copilotos M365 → Azure AI Foundry.
• AWS-first / Probar varios modelos → Bedrock (Agents + Flows + KB).
• Datos en BigQuery / Workspace → Vertex AI (Agent Builder + Grounding).
• Regulado / Air-gapped / On-prem → IBM watsonx o NVIDIA NeMo/NIM.
• Lakehouse-centric → Databricks Mosaic AI (Evaluate/Traces).
• Warehouse-centric → Snowflake Cortex AI (AISQL/Analyst).
• Ecosistema Oracle → OCI GenAI.

Antipatrones (transversal a cualquier plataforma)

Montar un LLM sin observabilidad: sin traces, eval loops ni A/B, vuelas a ciegas.

Hacer RAG moviendo datos por comodidad: acércate al dato; ahorras latencia y dolores de cumplimiento.

Ignorar guardrails (entrada/herramientas/salida): cuando llegue prompt injection, te acordarás.

Casarte con un vendor sin plan de salida: fija abstracciones de modelo, prompt templates y vector DB portables.

Conclusión

No hay una “mejor” plataforma universal: hay una adecuada a tu contexto.

Azure AI Foundry si priorizas integración Microsoft, seguridad y velocidad.

AWS Bedrock si quieres variedad de modelos y agentes con acción sobre tu nube.

Google Vertex AI si buscas multimodalidad avanzada y datos en GCP.

IBM watsonx / NVIDIA NeMo si la palabra clave es soberanía.

Databricks/Snowflake si tu ventaja está en llevar la IA al dato (no al revés).

El 2025 va de agentes con RAG y guardrails, observables, gobernados y portables. Elige pista (Azure, AWS, GCP, lakehouse o warehouse) y diseña para medir, iterar y migrar. Lo demás (incluido el “modelo de moda” de turno) es intercambiable si la arquitectura está bien hecha.

Con el auge de la inteligencia artificial generativa, han surgido numerosas plataformas y conceptos que pueden generar confusión entre profesionales y empresas. Como apasionado por la tecnología, quiero aclarar qué es Azure AI Foundry, una plataforma que Microsoft ha creado para facilitar el desarrollo de soluciones avanzadas en IA generativa.

¿Qué es Azure AI Foundry?

Azure AI Foundry es una plataforma integral diseñada para facilitar el desarrollo, personalización y administración de aplicaciones y agentes de IA generativa en un único entorno en la nube. Está pensada tanto para usuarios con poca experiencia en programación, gracias a herramientas low-code, como para desarrolladores avanzados, mediante un robusto SDK que se integra perfectamente con herramientas populares como Visual Studio Code y GitHub.

Componentes detallados de Azure AI Foundry

Catálogo de modelos: Selección, personalización y despliegue de modelos avanzados

Azure AI Foundry cuenta con un catálogo de modelos avanzados que incluyen opciones como GPT-4o de OpenAI, Hugging Face, Meta (Llama) y Cohere. Puedes utilizar modelos en modalidad MaaS (Model-as-a-Service), consumiéndolos directamente como APIs, o bien optar por modelos open-weight auto-hospedados que te permiten alojar y personalizar los modelos con técnicas avanzadas como el fine-tuning mediante tus propios datasets empresariales.

Ejemplo de uso: Una empresa financiera puede utilizar GPT-4o para generar informes personalizados a clientes, entrenándolo con datos históricos específicos de sus carteras de inversión para ofrecer respuestas más precisas.

Azure AI Search: Búsqueda híbrida y enriquecimiento de datos corporativos

Azure AI Search es fundamental para conectar soluciones de IA generativa con el conocimiento interno de tu empresa. Este servicio ofrece búsqueda híbrida (tradicional y vectorial) permitiendo indexar contenidos diversos (documentos PDF, bases de datos, SharePoint). Adicionalmente, integra pipelines de enriquecimiento cognitivo para extraer automáticamente información estructurada de datos no estructurados, enriqueciendo así las respuestas generadas por tus modelos con datos precisos y actualizados.

Ejemplo de uso: Un agente interno podría responder a preguntas frecuentes sobre políticas de la empresa consultando automáticamente manuales internos y bases de datos actualizadas, ofreciendo respuestas precisas con referencias a documentos específicos.

Azure AI Agent Service: Orquestación avanzada de agentes inteligentes

Este servicio permite crear agentes inteligentes capaces no solo de responder, sino también de ejecutar acciones complejas mediante una lógica avanzada. Internamente emplea frameworks como Semantic Kernel y AutoGen para que los agentes puedan razonar, tomar decisiones dinámicas e interactuar con múltiples APIs y conectores externos (más de 1.400 disponibles vía Azure Logic Apps). Además, incluye un SDK dedicado que permite desarrollar agentes personalizados mediante código en Python o C#, facilitando su integración en pipelines CI/CD.

Ejemplo de uso: Un agente de atención al cliente podría detectar automáticamente quejas sobre productos, verificar inventarios en tiempo real mediante una API, y generar automáticamente pedidos de reposición o reembolso al cliente.

Gobernanza y seguridad en generación de contenidos

Azure AI Foundry ofrece herramientas avanzadas para evaluar constantemente el rendimiento y la precisión de los modelos. Puedes ejecutar pruebas A/B, comparar respuestas entre diferentes modelos y ajustar continuamente tus soluciones basándote en métricas claras y dashboards interactivos. Esto permite una mejora continua en el desempeño y efectividad de tus soluciones de IA.

Ejemplo de uso: Una empresa de soporte técnico podría probar simultáneamente dos modelos de lenguaje diferentes para evaluar cuál resuelve mejor y más rápido las consultas frecuentes de los clientes.

Azure AI Content Safety: ética y seguridad integradas

Este servicio asegura que todo contenido generado por tus soluciones cumpla con altos estándares éticos y de seguridad. Azure AI Content Safety implementa filtros avanzados capaces de detectar y mitigar contenidos inapropiados o sensibles, adaptándose a las políticas específicas de tu organización, garantizando la responsabilidad y el cumplimiento normativo.

Ejemplo de uso: Un chatbot interno para recursos humanos puede usar Content Safety para evitar la generación o difusión de información sensible o datos personales protegidos.

Observabilidad y gobernanza: control total

La plataforma proporciona herramientas exhaustivas para supervisar el desempeño y comportamiento de soluciones de IA, integrándose estrechamente con Azure Monitor para ofrecer alertas proactivas, métricas clave en tiempo real y análisis avanzados. Además, permite rastrear detalladamente las decisiones de los agentes, configurar roles, permisos y cuotas de uso mediante integración nativa con Entra ID, asegurando así un control robusto y cumplimiento riguroso de políticas internas y externas.

Ejemplo de uso: Un departamento IT puede configurar alertas automáticas para detectar incrementos anormales en el uso de recursos por parte de un agente específico y actuar rápidamente en caso de anomalías.

Ejemplos prácticos en acción

Copiloto interno: un asistente inteligente integrado en Microsoft Teams que proporciona respuestas rápidas y precisas basadas en documentación interna actualizada.

Automatización de atención al cliente: agentes capaces de responder consultas frecuentes, verificar inventarios y gestionar automáticamente pedidos.

Asesor financiero automatizado: agentes analíticos que generan informes personalizados basados en análisis de datos financieros en tiempo real.

Copilotos especializados: asistentes específicos para departamentos como recursos humanos, legal o IT, integrados naturalmente en las herramientas cotidianas de trabajo.

¿Por qué elegir Azure AI Foundry?

Azure AI Foundry no es simplemente otra plataforma más en el mercado saturado de la inteligencia artificial. Lo que la hace especial y diferente es cómo encaja de forma natural en el ecosistema completo de Azure, funcionando como una pieza más en el engranaje tecnológico que probablemente tu empresa ya esté usando. Mientras otras plataformas te obligan a encajar piezas sueltas, AI Foundry ya trae todo perfectamente integrado.

Más allá de la integración técnica, AI Foundry ofrece simplicidad sin sacrificar potencia. Te permite conectar rápidamente tus datos empresariales con los modelos de inteligencia artificial más avanzados, sin perderte en complicaciones técnicas o problemas de compatibilidad. Y si ya utilizas Copilot Studio, Azure AI Foundry es una extensión ideal, porque no solo complementa sus capacidades, sino que las potencia aún más, creando asistentes inteligentes que de verdad entienden y facilitan tu trabajo diario.

Al final, elegir Azure AI Foundry no es solo optar por una tecnología avanzada: es apostar por un enfoque claro, coherente y sostenible a largo plazo. Es decidir que la inteligencia artificial en tu empresa no sea un experimento puntual, sino una pieza clave de tu estrategia digital y de negocio. ¿Quieres solo resolver problemas puntuales o construir una base sólida sobre la que innovar durante años? Si buscas lo segundo, Azure AI Foundry es, sin duda, la elección correcta.

¿Qué es MCP y por qué surge?

El Protocolo de Contexto de Modelo (Model Context Protocol, MCP por sus siglas en inglés) es un estándar abierto creado para conectar asistentes de IA con las fuentes de datos y herramientas que contienen el contexto que necesitan.

Nació a finales de 2024 de la mano de Anthropic como respuesta a un problema creciente: incluso los modelos de lenguaje más avanzados suelen estar aislados de los datos reales, atrapados detrás de silos de información y sistemas incompatibles. Cada nueva integración (por ejemplo, conectar un chatbot a una base de datos, o a un servicio corporativo) requería hasta entonces una solución a medida, lo que dificultaba escalar y mantener sistemas de IA realmente conectados.

MCP busca estandarizar estas conexiones de forma universal, sustituyendo integraciones fragmentadas por un único protocolo común. Anthropic lo ha comparado con un “puerto USB‑C para aplicaciones de IA”, ya que brinda una forma unificada de enchufar modelos de IA a diversas fuentes de datos y herramientas externas. En esencia, MCP facilita que un modelo (por ejemplo, un asistente tipo chat o un sistema de auto-completar código) pueda obtener información actualizada, relevante y específica desde los sistemas donde reside (archivos, bases de datos, APIs, etc.), mejorando así la calidad y pertinencia de sus respuestas.

Arquitectura técnica: ¿Cómo funciona MCP?

MCP sigue una arquitectura cliente-servidor modular. En esta arquitectura intervienen tres roles principales:

• Host MCP – la aplicación de IA o entorno donde corre el modelo (por ejemplo, Claude Desktop, un IDE de programación con asistente de código, u otras herramientas de IA). El host es quien inicia la conexión para acceder a datos mediante MCP.
• Cliente MCP – es el componente dentro del host que se encarga de la comunicación con los servidores. Cada cliente mantiene una conexión 1:1 con un servidor MCP específico. En la práctica suele ser una librería (SDK) integrada en la app de IA que habla el protocolo MCP.
• Servidor MCP – es un programa ligero que expone una fuente de datos o servicio externo a través del protocolo MCP. Un servidor MCP actúa como adaptador: conecta con una fuente (un sistema de ficheros local, una API web, una base de datos, etc.) y la presenta de forma estandarizada al cliente MCP.

Estos elementos permiten conexiones de muchos a muchos: un host puede conectarse a múltiples servidores MCP a la vez, y a su vez un mismo servidor MCP podría ser consultado por distintos hosts o aplicaciones, siempre mediante clientes MCP adecuados. Los servidores MCP pueden acceder tanto a datos locales (por ejemplo archivos del ordenador, servicios internos) como a servicios remotos vía red (APIs web, plataformas cloud), siempre aplicando controles de seguridad y permisos que configure el desarrollador.

Representación conceptual de la arquitectura MCP a modo de hub USB. Los hosts (p. ej. asistentes como Claude o entornos IDE) se conectan mediante un cliente MCP (librería, ilustrado como client.py) a múltiples servidores MCP, que a su vez “enchufan” diversas fuentes de datos. En este esquema, los rectángulos con logos (Slack, Gmail, Calendar) representan servicios remotos expuestos a través de servidores MCP, mientras que el conector con el icono de una carpeta (Finder) representa un datos locales accesibles por otro servidor MCP. MCP actúa como el puerto común que estandariza la comunicación entre los modelos de IA (hosts) y las herramientas externas (servers), evitando tener que crear integraciones ad-hoc para cada herramienta.

Primitivas del protocolo: Recursos, Herramientas y Prompts

La especificación de MCP define varias primitivas o tipos de interacción estándar entre clientes y servidores. Las tres más importantes son Recursos (Resources), Herramientas (Tools) y Prompts, las cuales permiten cubrir distintos casos de uso de intercambio de información:

• Recursos: representan datos o contenido estático que un servidor MCP pone a disposición del cliente. Pueden ser desde el contenido de un archivo, registros de una base de datos, resultados de una API, hasta una imagen o un log de sistema. Cada recurso se identifica con un URI (por ejemplo, file://ruta/al/archivo.txt o postgres://servidor/consulta) y puede ser de tipo texto o binario. Los recursos sirven para enriquecer el contexto del modelo – por ejemplo, proporcionando el texto de un documento relevante para que el asistente lo tenga en cuenta al responder. Cabe señalar que, en la mayoría de implementaciones actuales, el uso de recursos está controlado por la aplicación (no por el modelo en automático): típicamente el usuario o desarrollador debe indicar qué recursos quiere inyectar al contexto antes de que el modelo los use. Esto evita que el sistema acceda indiscriminadamente a datos sin supervisión; si se desea un acceso más autónomo por parte de la IA, MCP ofrece las Herramientas como alternativa (ver más abajo).
• Herramientas: permiten exponer funcionalidades ejecutables o acciones a través de MCP. Es decir, no solo datos estáticos, sino operaciones que el modelo puede pedir que se realicen, como realizar una búsqueda, consultar una API, ejecutar una consulta SQL o incluso controlar un dispositivo. Una herramienta en MCP se define con un nombre, una descripción y un esquema de parámetros de entrada, y el servidor MCP implementa la lógica de qué hacer cuando se invoca. Las herramientas están diseñadas para ser invocadas de forma controlada por el modelo (con la aprobación del usuario/humano en el bucle). En otras palabras, el asistente de IA puede decidir llamar a una herramienta durante su generación de respuesta (por ejemplo, “llamar a la herramienta de Búsqueda web con la pregunta X”), el cliente MCP envía esa solicitud al servidor correspondiente, el servidor ejecuta la acción (por ejemplo, hace la búsqueda en la web) y devuelve el resultado para que el modelo lo incorpore a su respuesta final. MCP estandariza este ciclo mediante endpoints genéricos de listado de herramientas disponibles y llamada a una herramienta específica. Un punto clave es que las herramientas pueden cambiar el estado o interactuar con el mundo real (a diferencia de los recursos que solo son lectura), por lo que su uso suele requerir confirmación y auditoría.
• Prompts: en MCP, un “prompt” hace referencia a plantillas de solicitud o instrucciones predefinidas que el servidor ofrece para uso del modelo o del usuario. Son básicamente prompt templates reutilizables que estandarizan interacciones comunes. Por ejemplo, un servidor MCP podría proveer un prompt llamado “Analizar código” que instruye al asistente a analizar un fragmento de código en busca de errores, posiblemente aceptando como argumento el lenguaje de programación. Los prompts pueden aceptar parámetros dinámicos, incluir contexto de algunos recursos automáticamente, encadenar múltiples interacciones (p. ej. pasos de una tarea) y servir como flujos de trabajo guiados. A diferencia de las herramientas, los prompts están pensados para ser iniciados por el usuario o la aplicación (son user-controlled): por ejemplo, podrían aparecer como opciones en la interfaz (un botón o un comando rápido) que el usuario selecciona para que el asistente ejecute esa plantilla de interacción. Esto brinda consistencia en tareas repetitivas y mejores prácticas a la hora de pedirle cosas al modelo.

Además de estos, MCP define otras construcciones, como Sampling (una forma de solicitar al servidor que el propio modelo genere texto, útil para ciertos agentes colaborativos), y Roots (puntos de entrada a recursos del sistema), entre otras. También estandariza el formato de los mensajes (basado en JSON-RPC 2.0) y puede funcionar sobre distintos transportes de red (HTTP, WebSockets, Server-Sent Events, etc.), manteniendo independencia de la capa física de comunicación.

En conjunto, la arquitectura MCP proporciona una “capa intermedia” (middleware) universal para que modelos de lenguaje y herramientas externas se comuniquen de forma estructurada. El desarrollador solo debe implementar un servidor MCP por cada sistema que quiera exponer, o usar alguno de los servidores ya disponibles, y cualquier modelo/herramienta compatible con MCP podrá conectarse siguiendo el mismo lenguaje común.

Ejemplo práctico de MCP en acción

Para ilustrar cómo se usa MCP en la práctica, imaginemos un par de escenarios concretos:

• Asistente de programación en un IDE: Supongamos que estamos usando un entorno de desarrollo integrado (IDE) con un asistente de código impulsado por IA. Sin MCP, este asistente estaría limitado al contexto del archivo abierto o a lo que uno le copie/pegue. Con MCP, el IDE puede conectar un servidor MCP de Git/GitHub: éste expone operaciones como buscar en el repositorio, obtener el contenido de un archivo o revisar el historial de commits. Así, cuando el desarrollador hace una pregunta (“¿Dónde se define la función X?”), el asistente puede invocar la herramienta correspondiente (por ejemplo, “buscar referencia de X en el repositorio”) y obtener la respuesta en tiempo real del servidor Git, incorporándola a su explicación. De hecho, varias herramientas de desarrollo ya están adoptando MCP para enriquecer sus asistentes: compañías como Zed, Replit, Codeium o Sourcegraph han trabajado con MCP para que sus plataformas permitan a los agentes de IA recuperar información de contexto relevante del código y producir código más ajustado con menos intentos.
• Agente de conocimiento empresarial (chatbot interno): Pensemos ahora en un asistente tipo chat dentro de una empresa, que deba consultar información de Slack y documentos de Google Drive para responder preguntas. Con MCP, es posible desplegar fácilmente un servidor MCP de Slack y un servidor MCP de Google Drive (de hecho, existen implementaciones abiertas de referencia para ambos). El servidor de Slack expondrá, por ejemplo, los canales y mensajes (con las debidas restricciones de acceso) permitiendo al asistente buscar mensajes relevantes o resumir conversaciones. El servidor de Google Drive hará lo propio con los archivos y carpetas, permitiendo búsquedas de texto y lectura de documentos. Todo ello de forma unificada: el asistente puede listar qué recursos ofrece Slack (canales, hilos) o qué herramientas tiene Drive (buscar archivos por nombre, por contenido, etc.), y utilizarlos según convenga. Por ejemplo: un usuario podría preguntarle al asistente “¿Qué se decidió en la última reunión sobre el proyecto X?” y el asistente, vía MCP, podría buscar en Slack el canal o hilo de la reunión correspondiente, obtener un resumen de los mensajes (recurso) y devolvérselo al usuario. Todo sin programación específica para Slack o Drive, ya que ambos cumplen el estándar MCP. De hecho, ya hay servidores MCP oficiales para Slack (gestión de canales y mensajes), Google Drive (acceso a ficheros y búsquedas), entre muchos otros sistemas populares, listos para usar.

El desarrollador o integrador no tiene que escribir código personalizado para cada API, sino simplemente conectar (o habilitar) el servidor MCP adecuado. El modelo de IA, por su parte, no necesita conocimiento preprogramado de cada sistema; interactúa con todos mediante las mismas operaciones genéricas de MCP (listar recursos, llamar herramientas, etc.). Así se logra que la IA mantenga el contexto relevante a medida que salta entre distintas fuentes de información, en lugar de quedarse “ciega” fuera de su entrenamiento fijo.

MCP desde Microsoft Copilot Studio

Una de las adopciones recientes de MCP es su integración en Microsoft Copilot Studio, la plataforma de Microsoft para crear y gestionar agentes de IA personalizados. En marzo de 2025, Microsoft anunció soporte nativo de MCP en Copilot Studio, lo que permite a los makers (desarrolladores o administradores) conectar servidores MCP a sus agentes con solo unos clics. En Copilot Studio, esto se traduce en que al editar un agente (por ejemplo, un asistente para Recursos Humanos), podemos añadir “acciones” basadas en MCP desde la interfaz. Basta con seleccionar “Add an action” y buscar el conector MCP deseado (ya sea uno personalizado o alguno de los disponibles en el marketplace). Por ejemplo, podríamos agregar una acción “Buscar respuesta en la base de conocimientos interna” conectando un servidor MCP que indexa la documentación corporativa. Una vez conectado, cada herramienta que exponga el servidor MCP aparecerá como una acción disponible en el agente – heredando automáticamente el nombre, descripción, entradas y salidas definidas por ese servidor. El creador del agente no tiene que redefinir nada manualmente; si mañana se agrega una nueva herramienta en el servidor MCP, aparecerá automáticamente para usarse en Copilot, y si se retira o modifica alguna, también se reflejará sin intervención. Esto reduce drásticamente el esfuerzo de mantenimiento, evitando errores por acciones desactualizadas.

Otro aspecto importante es que Copilot Studio integra estos servidores MCP a través de su infraestructura de conectores empresariales, lo que significa que respetan las políticas de seguridad y gobierno de datos corporativas. Por ejemplo, se pueden conectar con redes virtuales aisladas, aplicar controles de Prevención de Pérdida de Datos (DLP) y emplear métodos de autenticación robustos para acceder a sistemas internos. En la práctica, esto habilita acceso en tiempo real a datos para los agentes de Copilot, pero con las garantías de cumplimiento que las empresas requieren.

Copilot Studio + MCP permite a las empresas orquestar agentes de IA mucho más potentes sin lidiar con integraciones a medida: simplemente enchufando las fuentes de conocimiento que necesiten a través de servidores MCP. Microsoft destaca que esto proporciona flexibilidad (los agentes pueden ampliarse dinámicamente con nuevas capacidades) y acelera el desarrollo al reutilizar la creciente librería de conectores MCP disponibles.

MCP desde Azure AI Foundry

Otro entorno donde MCP está ganando terreno es Azure AI Foundry, la plataforma de Azure para construir, alojar y ejecutar aplicaciones de IA. En particular, el servicio Azure AI Agents dentro de Foundry –que permite crear y escalar agentes de IA con capacidad de conectar a múltiples fuentes– ahora soporta MCP de forma nativa.

¿Qué implica esto? Básicamente, Azure AI Foundry permite exponer sus agentes como servidores MCP. Un agente de Azure (que podría combinar varias habilidades, como realizar búsquedas con Bing, consultar datos de Azure Cognitive Search, leer archivos de SharePoint, etc.) se puede “publicar” vía MCP, de modo que cualquier cliente compatible pueda interactuar con él. Por ejemplo, Anthropic Claude Desktop es un cliente MCP compatible (como vimos antes), y Microsoft proporciona una guía de integración donde un agente de Azure se conecta con Claude a través de MCP. En ese caso, Claude –funcionando en el PC de un usuario– podría invocar herramientas expuestas por un agente alojado en Azure (como hacer una búsqueda web en tiempo real via Bing, o buscar en un índice interno de la empresa) y obtener la respuesta, todo mediante llamadas MCP seguras a Azure. Esto combina lo mejor de ambos mundos: los modelos avanzados de Anthropic consumiendo las capacidades y datos en vivo de Azure.

Desde la perspectiva del desarrollador en Azure Foundry, usar MCP implica unos pocos pasos: se configura/entrena el agente en Azure AI Agents, luego se habilita un servidor MCP que “enchufa” ese agente al exterior, y finalmente se conecta un cliente (sea una aplicación propia, un bot, o una herramienta de terceros) a ese endpoint MCP. Azure AI Agent Service, al ser totalmente gestionado, se encarga de la infraestructura, autenticación y escalado, por lo que el enfoque MCP encaja con facilidad: MCP actúa como lenguaje común para que los modelos utilicen agentes con acceso a conocimiento y herramientas. Microsoft indica que con Azure + MCP se pueden lograr capacidades como: consultas con fuentes web en vivo vía Bing, búsqueda en datos internos privados con Azure Cognitive Search, e incluso integrar otras fuentes como SharePoint o Microsoft Fabric, todo accesible para el modelo de forma unificada.

En pocas palabras, Azure AI Foundry utiliza MCP para conectar agentes de IA corporativos con modelos avanzados de manera estandarizada y segura. Esto abre la puerta a integrar asistentes de IA generales con los datos específicos de cada organización, sin que haya que desarrollar APIs dedicadas para cada caso. (Como apunte adicional: aunque el ejemplo dado es con Claude, cualquier cliente compatible con MCP puede aprovechar un servidor MCP de Azure; por ejemplo, un agente creado en Foundry podría ser consumido desde Copilot Studio u otros entornos que soporten MCP, dado el carácter abierto del protocolo).

Reflexión final: relevancia e impacto de MCP

Varias voces del sector lo comparan con la aparición de HTTP en los inicios de la web: así como HTTP estandarizó cómo se comunican los navegadores con los servidores web, MCP aspira a estandarizar cómo los modelos de IA interactúan con herramientas y fuentes de datos. Esta analogía no es exagerada si pensamos en los beneficios potenciales: con un protocolo común, los desarrolladores pueden conectar cualquier nueva aplicación o base de datos a cualquier asistente de IA sin esfuerzo artesanal, y los asistentes pueden “navegar” por las distintas fuentes de información de forma transparente, tal como hoy un navegador web puede acceder a cualquier sitio vía HTTP.

Dicho lo anterior, conviene matizar que MCP no pretende reemplazar protocolos universales existentes (no va a sustituir a HTTP, gRPC u otros), sino complementarlos añadiendo una capa de abstracción específica para contexto y acciones de IA. De hecho, MCP internamente se apoya en tecnologías web probadas (usa JSON-RPC sobre HTTP/HTTPS, SSE, etc.), pero definiendo mensajes semánticos adecuados al dominio de IA. Su impacto dependerá en gran medida de su adopción: hasta ahora, el apoyo de empresas como Anthropic y Microsoft, junto a una comunidad open source activa, apunta a un crecimiento acelerado. Ya existen decenas de servers MCP para servicios populares y varias herramientas cliente integrándolo, señal de un ecosistema en ebullición.

En perspectiva, MCP busca facilitar que las capacidades de los modelos de IA estén realmente al servicio de nuestras aplicaciones y datos cotidianos. Si logra consolidarse, podríamos ver un futuro próximo en el que conectar un nuevo sistema a nuestro asistente de IA sea tan sencillo y estándar como lo es hoy en día acceder a una página web. Sin proclamarlo como “vital” o “crítico” de forma exagerada, sí podemos reconocer a MCP como una evolución natural y muy prometedora para derribar las barreras entre la inteligencia artificial y el vasto universo de información y servicios que manejamos a diario. Un lenguaje común hombre-máquina-datos, abierto y universal, que bien empleado podrá multiplicar la utilidad y alcance de la IA en prácticamente cualquier ámbito, desde el desarrollo de software hasta el marketing, la educación o la gestión empresarial.

¡Si has llegado hasta aquí es que verdaderamente eres un amante de la IA!

Si te interesa la inteligencia artificial y cómo crear agentes que complementen Copilot Studio, hoy te traigo algo que te va a encantar. En este artículo, te enseñaré cómo montar un pequeño agente en Python que recopila información turística de Tenerife, la enriquece con Azure AI Foundry, la vectoriza y la sube a Azure AI Search para que pueda ser utilizada como conocimiento en un chatbot de Copilot Studio.

Vamos a utilizar Python y Playwright para hacer webscraping, GPT-4o mini en Azure AI Foundry para mejorar las descripciones de los lugares turísticos, Azure OpenAI Embeddings para vectorizar la información y Azure Blob Storage y Azure Table Storage para almacenar los datos. Finalmente, en un segundo artículo, te enseñaré cómo indexar esta información en Azure AI Search y hacer que tu Copilot pueda entender y responder sobre ella.

Este es el tipo de cosas que enseñaremos en el Canadian Power Platform Summit en Vancouver, donde David Lorenzo y yo mostraremos cómo usar Copilot Studio junto con Azure AI Foundry para crear soluciones avanzadas. Así que, si te gusta experimentar con IA, bases de datos vectoriales y asistentes inteligentes, quédate y empecemos a construir este agente paso a paso.

Con este agente, buscamos:

• Mejorar la experiencia del usuario: Al enriquecer las descripciones turísticas, el agente ofrece información más completa y persuasiva, ayudando a los visitantes a tomar decisiones informadas.
• Automatizar procesos: Mediante el uso de webscraping y procesamiento automatizado, eliminamos la necesidad de actualizar manualmente la información.
• Facilitar búsquedas inteligentes: La vectorización y almacenamiento de los datos permiten que se puedan utilizar en motores de búsqueda avanzados como Azure AI Search, ofreciendo respuestas basadas en similitud y relevancia.
• Integrar múltiples tecnologías: El proyecto demuestra cómo combinar herramientas modernas como Playwright, Azure AI Foundry y Azure OpenAI, creando una solución para el sector turístico.

Paso 1: Configuración y Dependencias

El primer paso es preparar el entorno de desarrollo. Importamos las librerías necesarias y definimos las variables de configuración (como endpoints y claves) de forma genérica para que puedan adaptarse fácilmente a diferentes entornos. Esto permite mantener la seguridad y la flexibilidad en el despliegue.

import os
import json
import time
import math
import re
from playwright.sync_api import sync_playwright
from urllib.parse import urljoin
import requests
from azure.storage.blob import BlobServiceClient
from azure.data.tables import TableServiceClient
from azure.core.exceptions import ResourceExistsError

# Configuración de Azure AI Foundry con variables genéricas
AZURE_FOUNDRY_ENDPOINT = os.getenv("AZURE_FOUNDRY_ENDPOINT", "https://<tu_endpoint_genérico>.openai.azure.com/")
AZURE_FOUNDRY_API_KEY = os.getenv("AZURE_FOUNDRY_API_KEY", "<tu_api_key_genérica>")
AZURE_FOUNDRY_DEPLOYMENT_NAME = os.getenv("AZURE_FOUNDRY_DEPLOYMENT_NAME", "gpt-4o-mini")

Consejo: Utiliza variables de entorno o archivos de configuración para gestionar claves y endpoints de manera segura.

Paso 2: Extracción de Información mediante Webscraping

En esta etapa, empleamos Playwright para automatizar la navegación a la web turística de Tenerife y extraer datos clave de cada categoría (nombre, descripción y enlace). El objetivo es recopilar toda la información básica que posteriormente enriqueceremos.

def scrape_categories():
    print("Iniciando scraping de categorías...")
    start_time = time.time()

    with sync_playwright() as p:
        browser = p.chromium.launch(headless=True)
        page = browser.new_page()
        page.set_extra_http_headers({
            "User-Agent": "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 ..."
        })

        URL = "https://www.webtenerife.com/que-hacer/"
        page.goto(URL)
        page.wait_for_load_state("networkidle")

        elements = page.query_selector_all("div.card__col article.card")
        print(f"Categorías encontradas: {len(elements)}")

        categories = []
        for item in elements:
            try:
                category_name = item.query_selector("h6.card__title.heading").inner_text().strip()
            except:
                category_name = "Sin nombre"
            try:
                description = item.query_selector("div.card__description").inner_text().strip()
            except:
                description = "Sin descripción"
            try:
                link = item.query_selector("a").get_attribute("href")
                if not link.startswith("http"):
                    link = urljoin(URL, link)
            except:
                link = "Sin enlace"

            categories.append({
                "nombre": category_name,
                "descripcion": description,
                "link": link
            })
    print(f"Fase de scraping completada. Obtenidas {len(categories)} categorías.")
    return categories

Esta función automatiza el proceso de extracción, asegurando que se capturan todos los datos relevantes de la web.

Paso 3: Enriquecimiento de Descripciones con Azure AI Foundry

Una vez recopiladas las descripciones, se requiere enriquecerlas para ofrecer información más detallada y atractiva. Para ello, la función azure_foundry_enrich_batch se conecta a la API de Azure AI Foundry y envía un prompt específico que actúa como asistente turístico. El modelo responde con una versión mejorada de cada descripción.

def azure_foundry_enrich_batch(descriptions):
    url = f"{AZURE_FOUNDRY_ENDPOINT}openai/deployments/{AZURE_FOUNDRY_DEPLOYMENT_NAME}/chat/completions?api-version=2024-10-21"
    headers = {
        "Content-Type": "application/json",
        "api-key": AZURE_FOUNDRY_API_KEY
    }
    
    prompt_content = (
        "Actúa como un asistente turístico especializado que enriquece descripciones de lugares en Tenerife. "
        "A continuación tienes un array JSON con varias descripciones turísticas. "
        "Devuélveme SOLO un array JSON, sin ningún formato markdown, sin explicaciones adicionales, "
        "en el mismo orden y con la misma longitud, donde cada elemento sea "
        "una versión más detallada y atractiva de la descripción original. "
        f"Descripciones: {json.dumps(descriptions, ensure_ascii=False)}"
    )
    
    data = {
        "messages": [
            {"role": "system", "content": "Eres un asistente turístico especializado en Tenerife. Responde ÚNICAMENTE con JSON válido, sin markdown."},
            {"role": "user", "content": prompt_content}
        ],
        "max_tokens": 1000,
        "temperature": 0.7
    }
    
    try:
        response = requests.post(url, headers=headers, json=data, timeout=30)
        if response.status_code == 200:
            result = response.json()
            content = result["choices"][0]["message"]["content"].strip()
            json_pattern = r'\[.*\]'
            json_match = re.search(json_pattern, content, re.DOTALL)
            if json_match:
                json_content = json_match.group()
                enriched_descriptions = json.loads(json_content)
                if isinstance(enriched_descriptions, list) and len(enriched_descriptions) == len(descriptions):
                    return enriched_descriptions
            # Si no se encuentra el formato esperado, se realizan otros intentos de parseo
        else:
            error_msg = f"Error en la API: {response.status_code} - {response.text}"
            print(error_msg)
            return [error_msg for _ in descriptions]
    except Exception as e:
        error_msg = f"Excepción al llamar a la API: {e}"
        print(error_msg)
        return [error_msg for _ in descriptions]

Este paso transforma las descripciones básicas en versiones enriquecidas, haciendo el contenido más persuasivo y útil para futuros usuarios.

Paso 4: Vectorización de la Información mediante Embeddings

Para poder realizar búsquedas inteligentes y encontrar categorías similares, es fundamental transformar el texto en vectores numéricos. Usamos el modelo "text-embedding-3-small" de Azure OpenAI para generar estos embeddings, combinando el nombre y la descripción detallada de cada categoría.

def generate_embeddings(json_file_path):
    print("Iniciando generación de embeddings...")
    with open(json_file_path, 'r', encoding='utf-8') as f:
        categories = json.load(f)
    
    embedding_url = "https://<tu_endpoint_genérico>/openai/deployments/text-embedding-3-small-2/embeddings?api-version=2023-05-15"
    headers = {
        "Content-Type": "application/json",
        "api-key": "<tu_api_key_genérica_para_embeddings>"
    }
    
    embeddings_results = []
    total = len(categories)
    for idx, category in enumerate(categories):
        nombre = category.get('nombre', 'Sin nombre')
        descripcion_detallada = category.get('descripcion_detallada', '')
        texto = f"{nombre}. {descripcion_detallada}"
        
        data = {
            "input": texto,
            "encoding_format": "float"
        }
        try:
            response = requests.post(embedding_url, headers=headers, json=data, timeout=30)
            if response.status_code == 200:
                result = response.json()
                embedding = result["data"][0]["embedding"]
                embedding_result = {
                    "id": nombre,
                    "nombre": nombre,
                    "descripcion_detallada": descripcion_detallada,
                    "embedding": embedding
                }
                embeddings_results.append(embedding_result)
                print(f"[{idx+1}/{total}] Embedding generado para: {nombre}")
            else:
                print(f"Error para '{nombre}': {response.status_code}")
        except Exception as e:
            print(f"Excepción para '{nombre}': {e}")
    embeddings_file = "categorias_embeddings.json"
    with open(embeddings_file, "w", encoding="utf-8") as f:
        json.dump(embeddings_results, f, ensure_ascii=False, indent=4)
    print(f"Embeddings guardados en '{embeddings_file}'")
    return embeddings_results

La vectorización es la base para poder realizar comparaciones semánticas y ofrecer resultados de búsqueda relevantes.

Paso 5: Almacenamiento en Azure Blob y Table Storage

Una vez procesada la información, se almacena en dos orígenes de datos:

1. Azure Blob Storage: Se sube el archivo JSON con las categorías y sus embeddings, lo que permite utilizarlo fácilmente como fuente de datos.
2. Azure Table Storage: Los datos se guardan como entidades, permitiendo realizar consultas estructuradas y eliminar registros antiguos si es necesario.

Subida a Azure Blob Storage

def upload_to_blob_storage(file_path, container_name, blob_name):
    try:
        connect_str = os.getenv("AZURE_STORAGE_CONNECTION_STRING", "<tu_conexion_genérica>")
        blob_service_client = BlobServiceClient.from_connection_string(connect_str)
        try:
            container_client = blob_service_client.get_container_client(container_name)
            container_client.get_container_properties()
        except Exception:
            print(f"Creando contenedor '{container_name}'...")
            blob_service_client.create_container(container_name)
        blob_client = blob_service_client.get_blob_client(container=container_name, blob=blob_name)
        with open(file_path, "r", encoding="utf-8") as json_file:
            json_content = json_file.read()
        blob_client.upload_blob(json_content, overwrite=True, content_type="application/json")
        print(f"Archivo '{file_path}' subido exitosamente a Blob Storage")
    except Exception as e:
        print(f"Error al subir el archivo: {e}")

Guardado en Azure Table Storage

def save_to_table_storage(json_file_path, table_name):
    try:
        connect_str = os.getenv("AZURE_STORAGE_CONNECTION_STRING", "<tu_conexion_genérica>")
        table_service_client = TableServiceClient.from_connection_string(connect_str)
        try:
            table_client = table_service_client.get_table_client(table_name)
            properties = table_client.get_table_properties()
            print(f"Tabla '{table_name}' encontrada. Limpiando registros...")
            for entity in table_client.list_entities():
                table_client.delete_entity(partition_key=entity["PartitionKey"], row_key=entity["RowKey"])
        except Exception as e:
            print(f"Tabla no encontrada, creando nueva: {e}")
            table_client = table_service_client.create_table(table_name)
        
        with open(json_file_path, 'r', encoding='utf-8') as f:
            categories = json.load(f)
        
        import uuid
        for category in categories:
            unique_id = str(uuid.uuid4())
            entity = {
                "PartitionKey": "categories",
                "RowKey": unique_id,
                "id": unique_id,
                "nombre": category.get('nombre', 'Sin nombre'),
                "descripcion": category.get('descripcion', ''),
                "link": category.get('link', ''),
                "descripcion_detallada": category.get('descripcion_detallada', ''),
                "contentVector": json.dumps(category.get('embedding', []))
            }
            table_client.create_entity(entity)
        print("Datos guardados correctamente en Table Storage")
    except Exception as e:
        print(f"Error al guardar en Table Storage: {e}")

Conclusión y Próximos Pasos

En este primer artículo os muestro paso a paso cómo construir un agente inteligente que:

1. Extrae información turística a través de webscraping.
2. Enriquece las descripciones utilizando Azure AI Foundry.
3. Vectoriza el contenido para futuras búsquedas inteligentes.
4. Almacena los datos en Azure Blob y Table Storage, habilitando su uso en Azure AI Search.

El objetivo es transformar datos básicos en un conocimiento enriquecido y estructurado que, en una segunda parte, se integrará en Azure AI Search para ofrecer una experiencia de búsqueda personalizada y basada en inteligencia artificial. Este proceso no solo automatiza la recopilación y el enriquecimiento de la información, sino que también sienta las bases para soluciones en el ámbito turístico, facilitando la integración de múltiples servicios de Azure.

En el segundo artículo, profundizaremos en cómo configurar Azure AI Search y conectar estos datos con Copilot Studio para cerrar el circuito, permitiendo que los usuarios finales se beneficien de un sistema de búsqueda avanzado.

Espero que este tutorial os haya sido útil y que inspire nuevas ideas para aprovechar la potencia de Azure en la creación de soluciones. ¡Nos vemos en el próximo post!

La Generación Aumentada por Recuperación (RAG) ha sido un avance clave en el desarrollo de aplicaciones de inteligencia artificial generativa. Permite a los modelos de lenguaje acceder a información externa para enriquecer sus respuestas y mejorar su precisión. Sin embargo, la evolución de la IA está llevando a sistemas más avanzados: los agentes autónomos. Estos no solo recuperan información, sino que también pueden tomar decisiones y ejecutar acciones de manera independiente.

En este artículo, exploraremos cómo pasamos de la arquitectura RAG a la creación de agentes autónomos, sus ventajas y los desafíos que presentan.

¿Qué es RAG y cómo funciona?

RAG mejora el rendimiento de los modelos de lenguaje al permitirles acceder a información actualizada y específica en tiempo real. Su funcionamiento se basa en los siguientes pasos:

1. Ingesta y procesamiento de datos: Se recopila información de diversas fuentes (PDFs, documentos de Word, bases de datos, etc.) y se convierte en un formato que el modelo pueda interpretar.
2. Fragmentación de documentos: Se dividen los textos en secciones más pequeñas para optimizar la búsqueda y recuperación.
3. Generación de embeddings: Cada fragmento se convierte en una representación vectorial que captura su significado semántico.
4. Almacenamiento en bases de datos vectoriales: Estos embeddings se guardan en bases de datos diseñadas para realizar búsquedas eficientes.
5. Recuperación de información: Cuando un usuario hace una consulta, el sistema busca los fragmentos más relevantes y los usa como contexto adicional para el modelo de lenguaje.
6. Generación de respuesta: Con la información recuperada, el modelo genera una respuesta más precisa y contextualizada.

Limitaciones de RAG

A pesar de sus ventajas, RAG tiene algunas limitaciones que han llevado al desarrollo de soluciones más avanzadas:

• Reactividad: Solo responde a consultas, sin capacidad para actuar de forma autónoma.
• Flujo de trabajo rígido: No puede adaptarse dinámicamente a diferentes escenarios o necesidades más complejas.
• Falta de razonamiento profundo: Su función principal es recuperar información, pero no puede tomar decisiones o planificar estrategias.

Hacia los agentes autónomos

Los agentes autónomos amplían las capacidades de RAG al integrar herramientas que les permiten interactuar con su entorno, tomar decisiones y ejecutar acciones. La evolución hacia estos agentes se basa en los siguientes elementos:

1. Uso de herramientas externas

Para que un agente pueda realizar tareas más avanzadas, debe poder interactuar con sistemas externos. Algunas herramientas clave incluyen:

• Navegación web: Acceso a información en línea.
• Ejecución de código: Capacidad de interpretar y ejecutar scripts.
• Integraciones con software: Conexión con sistemas como un CRM o ERP.
• Automatización de tareas: Envío de correos electrónicos, actualización de bases de datos, entre otras funciones.

Estas herramientas permiten que un agente consulte datos en tiempo real y tome acciones basadas en la información obtenida.

2. Orquestación y planificación

Para operar de manera más avanzada, los agentes requieren una estructura que les permita dividir tareas complejas en pasos más manejables. Algunos enfoques incluyen:

• Encadenamiento de prompts: Divide una tarea en varias interacciones secuenciales.
• ReAct (Reasoning + Acting): Un modelo de razonamiento iterativo en el que el agente evalúa su estado, elige una acción y ajusta su enfoque con base en los resultados.
• Chain-of-Thought: Permite que el agente explique su proceso de razonamiento paso a paso.
• Tree-of-Thought: Expande Chain-of-Thought al considerar múltiples opciones antes de elegir la mejor respuesta.

3. Agentes con reglas y directrices

Para mejorar la confiabilidad, algunos agentes operan dentro de límites predefinidos, lo que permite mantener el control sobre sus acciones. Estos agentes pueden:

• Planificar: Evaluar su estado actual y determinar qué pasos seguir.
• Ejecutar acciones: Escoger la mejor acción disponible, ya sea ejecutar un flujo de RAG, llamar a otra herramienta o delegar a otro agente.
• Monitorear y ajustar: Revisar los resultados de sus acciones y modificar su estrategia si es necesario.

4. Agentes con autonomía total

El objetivo final es desarrollar agentes que puedan razonar, planificar y generar código o respuestas sin intervención manual. Estos agentes podrían:

• Adaptarse a diferentes contextos de manera flexible.
• Aprender de experiencias pasadas para mejorar su desempeño.
• Ejecutar tareas avanzadas sin requerir instrucciones detalladas.

¿Cómo se construye un agente autónomo?

Un agente autónomo combina varios componentes clave:

1. Modelo de lenguaje: Es el núcleo del sistema, encargado del procesamiento de la información y la toma de decisiones.
2. Herramientas externas: Permiten que el agente acceda a información actualizada y realice acciones en otros sistemas.
3. Orquestación y planificación: Define cómo el agente estructura su razonamiento y divide las tareas en pasos concretos.

Ejemplo: Un agente de reservas de vuelo

Imaginemos un asistente que ayuda a los usuarios a encontrar vuelos. Cuando alguien pregunta: “¿Cuáles son los vuelos disponibles de Nueva York a Los Ángeles el 20 de diciembre?”, el agente sigue este proceso:

1. Evalúa la consulta: Identifica la información clave (origen, destino y fecha).
2. Busca datos en línea: Usa una herramienta para consultar vuelos en tiempo real.
3. Filtra resultados: Ordena los vuelos por precio y disponibilidad.
4. Entrega una respuesta: Presenta al usuario las opciones más relevantes.

Este tipo de agente no solo recupera información, sino que también toma decisiones y optimiza el proceso.

Consideraciones clave al desarrollar agentes autónomos

Para construir un sistema eficiente, es importante tener en cuenta:

• Estrategia de fragmentación de datos: Cómo dividir la información para facilitar su recuperación.
• Optimización de bases de datos vectoriales: Garantizar búsquedas rápidas y precisas.
• Seguridad y gobernanza: Controlar el acceso a datos y evitar sesgos o riesgos éticos.
• Supervisión y mejora continua: Monitorear el desempeño del agente y ajustar su comportamiento según sea necesario.
• Gestión de costes: Optimizar los recursos de computación y almacenamiento.

*Bonus* Nueva Plataforma para Crear Agentes Autónomos: Azure AI Agent Service

Dado que la noticia es muy reciente, ya disponemos en public preview de Azure AI Agent Service. Se trata de una nueva herramienta de Microsoft diseñada para que las empresas puedan crear agentes de IA autónomos sin complicarse con infraestructuras complejas.

¿Qué hace que esta plataforma sea especial?

Más fácil de usar

• No necesitas programar desde cero. Puedes configurar un agente en pocas líneas de código, indicándole qué información debe manejar y qué tareas puede hacer.
• Funciona dentro del ecosistema de Microsoft y se integra con herramientas como Azure AI Foundry, que simplifica la personalización.

Accede a información en tiempo real

• Puede conectarse con servicios como Bing Search o Azure AI Search para obtener datos actualizados.
• También puede interactuar con documentos, hojas de cálculo y bases de datos dentro de la empresa.

Colaboración entre agentes

• Si un solo agente no puede resolver una tarea compleja, puede trabajar con otros. Por ejemplo, uno puede recopilar información mientras otro analiza los datos y elabora una respuesta.
• Usa tecnologías como AutoGen y Semantic Kernel, que permiten que varios agentes trabajen juntos de manera eficiente.

Seguro y confiable

• Microsoft se encarga de la seguridad y la privacidad de los datos, asegurando que el sistema cumpla con normativas de protección de información.
• Se puede elegir entre usar el almacenamiento gestionado por Azure o conectar almacenamiento en un Azure Blob Storage propio.

¿Por qué esto es importante para las empresas?

Gracias a Azure AI Agent Service, cualquier empresa puede incorporar agentes inteligentes para automatizar tareas, mejorar la atención al cliente o facilitar la gestión de información.

Imagina un equipo que antes tenía que procesar cientos de correos manualmente. Con un agente de IA, ahora puede filtrar, responder y clasificar automáticamente cada mensaje, ahorrando tiempo y mejorando la eficiencia.

Este tipo de soluciones acercan la inteligencia artificial a más empresas, permitiendo que la tecnología trabaje a su favor. Con herramientas como esta, la IA autónoma deja de ser solo un concepto futurista y empieza a ser una realidad accesible para todos.

Próximamente ampliaré con más información (y alguna demo) como funciona este nuevo servicio de agentes disponible en Azure AI Foundry

¡Estad atentos!

El Reconocimiento Óptico de Caracteres (OCR) se ha convertido, desde hace décadas, en un componente esencial para la digitalización de documentos y la automatización de procesos. Sin embargo, la necesidad de comprender realmente el texto —y no solo extraerlo— ha impulsado la aparición de nuevas soluciones basadas en Modelos de Lenguaje de Gran Tamaño (LLM). En la actualidad, tecnologías como Azure OpenAI han redefinido las posibilidades de la inteligencia documental, haciendo énfasis en una comprensión semántica más profunda y en la facilidad de integración con sistemas empresariales.

A lo largo de este artículo, exploraremos la evolución del OCR tradicional, sus limitaciones y cómo los LLM están potenciando un salto cualitativo. Además, veremos la importancia de la automatización inteligente dentro del ecosistema de Microsoft, con referencias a servicios como Azure AI Foundry, Document Intelligence y Power Automate, así como algunas consideraciones técnicas clave para su adopción.

1. Limitaciones Clásicas del OCR

Los sistemas de OCR extraen caracteres y palabras de imágenes o documentos escaneados. Aun con mejoras constantes, estos presentan tres grandes restricciones:

Falta de Contexto Semántico

• El OCR “lee” caracteres, pero no relaciona ni interpreta su significado dentro de un texto más amplio. En un contrato legal, por ejemplo, reconoce la palabra “penalización” pero no sabe si está ligada a un plazo o a una cláusula específica.

Dependencia de la Calidad de la Fuente

• Factores como el deterioro de la página, la iluminación o el uso de fuentes poco convencionales generan inexactitudes. Aunque existen técnicas de preprocesamiento, las tasas de error pueden aumentar considerablemente si la calidad es baja.

Limitaciones en Estructuras Complejas

• Formularios con varios campos, tablas desalineadas o documentos con diseños no estándar siguen requiriendo una configuración o entrenamiento más elaborado para extraer los datos correctamente.

2. El Potencial de los LLM y la Nueva Inteligencia Documental

Los Modelos de Lenguaje de Gran Tamaño suponen un avance notable porque no se detienen en la extracción de texto, sino que analizan y comprenden su significado. Esta evolución abre la puerta a una inteligencia documental mucho más sofisticada:

2.1 Procesamiento Semántico y Corrección de Errores

Los LLM pueden:

• Corregir de forma automática los errores provenientes del OCR, basándose en probabilidades lingüísticas y contexto.
• Identificar entidades o términos clave (nombres, fechas, cláusulas, etc.), aportando metadatos críticos para cualquier flujo de automatización.
• Relacionar partes del texto, ofreciendo una visión global y estructurada del documento.

Ejemplo Práctico
En la digitalización de historiales médicos, un modelo de lenguaje puede inferir campos incompletos (por ejemplo, un diagnóstico omitido) o corregir términos clínicos mal escaneados, gracias a su amplio conocimiento de vocabulario.

2.2 Integración Multimodal

Algunos modelos admiten análisis tanto de texto como de imágenes, lo que reduce la complejidad de los pipelines. En lugar de orquestar varias herramientas, los documentos (incluyendo diagramas, gráficos o anotaciones) pueden procesarse de forma conjunta, obteniendo así una comprensión más rica.

2.3 Mejora Constante con Retroalimentación

Otro aspecto interesante es la capacidad de los LLM para aprender de la retroalimentación continua. Con un conjunto de ejemplos corregidos o validados por usuarios, se puede ajustar el modelo a un dominio concreto (legal, financiero, etc.) y refinar su precisión con el tiempo.

3. Arquitectura Híbrida: Uniendo OCR y LLM

A pesar de las ventajas que brindan los LLM, el OCR sigue siendo el punto de partida para extraer texto de documentos escaneados. Una aproximación eficaz en entornos empresariales suele darse a través de arquitecturas híbridas:

Extracción Base con OCR

• Se emplean servicios de Microsoft enfocados en el reconocimiento de texto y la estructuración de documentos, como Document Intelligence (hay muchos otros, pero es el que mas he utilizado) que ofrecen una primera capa de datos.

Procesamiento Semántico con LLM

• Un modelo como GPT-4o (GPT-40 mini para este cometido es muy válido, además de mas barato), accesible en Azure OpenAI, analiza y enriquece los resultados, corrigiendo posibles errores y añadiendo contexto (fechas, relaciones entre cláusulas, etc.).

Orquestación y Automatización

• Herramientas como Power Automate pueden desencadenar flujos de trabajo basados en el resultado del LLM, ya sea para almacenar los datos en una base de datos, en un gestor documental como SharePoint,  generar alertas o integrar con sistemas de back-office.

Caso de Uso
En la gestión de facturas, el OCR extrae datos elementales (proveedor, importe, fecha), mientras que el LLM valida su coherencia (por ejemplo, el cálculo de impuestos) y, si encuentra discrepancias, notifica al responsable correspondiente o genera un aviso en el ERP de la compañía.

4. Desafíos y Consideraciones Técnicas

Aunque la convergencia entre OCR y LLM presenta beneficios claros, es importante tener en cuenta varios aspectos:

Costes de Procesamiento

• El uso de modelos avanzados puede implicar mayores costes de cómputo. La nube de Microsoft ofrece elasticidad, pero es fundamental optimizar las cargas de trabajo y mantener un control de la facturación.

Entrenamiento de Dominio

• Para textos legales, médicos o financieros, se requiere adaptar el LLM mediante fine-tuning, lo que exige un conjunto de datos representativo y un proceso de validación minucioso. Esto da para un artículo entero. Próximamente hablaré de cuando debemos utilizar fine-tuning en los LLM's y cuando no.

Latencia en Flujos Críticos

• El procesamiento secuencial de OCR y LLM puede elevar la latencia. En aplicaciones donde la velocidad sea prioritaria (como verificación de documentos en línea), conviene diseñar pipelines eficientes y optimizar cada etapa.

Privacidad y Cumplimiento Normativo

• Procesar documentos sensibles (sanitarios, legales, etc.) implica salvaguardar la confidencialidad. Azure AI Foundry o las opciones de despliegue privado de Azure OpenAI pueden ayudar a cumplir con regulaciones locales e internacionales.

5. Futuro de la Automatización: Hacia los Agentes de IA

La tendencia apunta a la aparición de agentes de IA capaces de realizar tareas complejas, integrando:

• Reconocimiento de imágenes (OCR) como puerta de entrada para la digitalización.
• Modelos de lenguaje que comprendan las relaciones semánticas y extraigan conclusiones.
• Acciones automatizadas desencadenadas en función de esa comprensión (generar reportes, actualizar bases de datos o incluso tomar decisiones administrativas simples).

Este nuevo paradigma posibilita sistemas más ágiles y autónomos, en los que los profesionales humanos se centran en tareas de mayor valor, mientras la IA se encarga de las labores repetitivas o de gran volumen.

6. Recomendaciones para empresas que buscan escalar

Diseño de Pipelines Híbridos y Flexibles

• Empezar con un OCR sólido y, gradualmente, incorporar capas de inteligencia semántica con LLM, ajustando la complejidad del modelo a las necesidades reales.

Uso de Servicios en la Nube de Forma Selectiva

• Servicios como Azure OpenAI permiten acceder a grandes modelos con alta disponibilidad. De igual forma, contar con opciones de despliegue en entornos privados ofrece control adicional sobre los datos.

Automatización y Orquestación

• Herramientas como Power Automate agilizan la creación de flujos de trabajo sin requerir un gran desarrollo adicional.
• Integrar validaciones y retroalimentación en estos flujos para enriquecer el modelo de forma continua.

Monitoreo y Gobernanza de Datos

• Establecer una política de calidad de datos, con mediciones de exactitud y reglas de cumplimiento. Así, se garantiza que los resultados de la IA sean fiables y auditables.

7. Conclusión

El OCR tradicional mantiene su relevancia como puerta de entrada a la digitalización de documentos, pero la auténtica transformación llega con la incorporación de Modelos de Lenguaje que comprenden y contextualizan el texto. De la mano de soluciones como Azure OpenAI, Document Intelligence o Power Automate, las organizaciones pueden construir ecosistemas automatizados más ágiles, capaces de evolucionar conforme cambian los requisitos del negocio.

El futuro se vislumbra con agentes de IA que combinen reconocimiento visual, procesamiento de lenguaje natural y capacidad de actuación autónoma. Quienes adopten este modelo híbrido—OCR más LLM— se posicionarán para optimizar costes, reducir la tasa de errores y, sobre todo, extraer el máximo valor de sus datos en un entorno cada vez más competitivo y orientado a la eficiencia.