DEV Community: Carlos José Castro Galante

Azure AI Search in 2026, how to build a RAG pipeline

Carlos José Castro Galante — Fri, 10 Jul 2026 23:15:53 +0000

Most RAG tutorials online show the same pattern: take a document, split it into chunks, generate embeddings, store them in a vector database, and when a query arrives search for the nearest vectors and send them to the LLM. It works. The problem is that in production, that pattern fails in ways that don't show up in the tutorial.

A user types "SNAT error in network configuration". The vector for that query is semantically similar to dozens of documents about NAT, networking, and general network configurations. The vector search returns conceptually relevant results, but the specific document that contains "SNAT" many times over might not be in the top five. Keyword search would have found it immediately.

Azure AI Search exists to solve exactly that kind of problem, and in 2026 the service has changed enough that much of what was written about it before is outdated.

What Azure AI Search actually is today

The service was called Azure Search, then Azure Cognitive Search, and since November 2023 it is Azure AI Search. The most recent name that appeared at Build 2026 is Foundry IQ, which is how Microsoft exposes it inside the Azure AI Foundry portal. They are not two separate services: Foundry IQ is Azure AI Search seen from the agent platform.

Internally, the service combines three search technologies. The full-text engine uses BM25, the same algorithm used by traditional search engines, which scores documents by term frequency and inverse document frequency across the corpus. The vector engine uses HNSW (Hierarchical Navigable Small World) for approximate nearest neighbor search over embeddings. And the Semantic Ranker is a transformer-based cross-encoder model adapted from Microsoft Bing that reorders the results from the other two based on actual semantic relevance.

These three components can be used separately or in combination. Most production systems use them together.

Why vector search alone is not enough

An embedding captures general meaning. It works well for conceptual questions like "how does OAuth authentication work", where the intent is semantic and there is no specific term to match. It fails when the query contains very specific terms: product codes, error numbers, technical acronyms, proper names.

The reason is technical: embedding models compress a lot of semantic information into a fixed-dimension vector. Rare or very specific terms tend to get diluted in that compression process. BM25 does not have that problem because it works with exact term frequencies.

Hybrid search runs both queries in parallel and merges results using Reciprocal Rank Fusion (RRF). RRF combines ranking lists without requiring the scores from both systems to be on the same scale, using a formula that penalizes results that appear very low in either list. The outcome consistently outperforms either search alone, especially for enterprise content that mixes descriptive text with specific identifiers.

The Semantic Ranker and what it actually does

After hybrid search returns its ranked results, the Semantic Ranker takes the top 50 and reorders them. It uses a cross-encoder model that processes the query and the document snippet together, unlike bi-encoders that generate independent embeddings for each. That difference matters because the cross-encoder can capture subtle relationships like negations and contextual dependencies that vector similarity misses.

The Semantic Ranker also generates captions (representative snippets from the document) and optionally answers (passages that directly respond to the question if it was phrased as a question). Both captions and answers are verbatim text from the index, not text generated by the model.

One relevant detail: the Semantic Ranker operates only over text, even in hybrid queries. And it only processes the top 50 results from the previous ranking, which means that if the right document is not in those 50, the ranker cannot recover it. The quality of the initial ranking matters.

A practical consideration: semantic queries have additional cost. It is not necessary to enable it for all queries. For background search or batch processing where precision is not critical, it can be skipped. For user-facing search where result quality affects the LLM response, it is worth it.

Two RAG paths in 2026

Since 2026, Azure AI Search offers two distinct approaches for building a RAG pipeline. Microsoft calls them the classic RAG pattern and agentic retrieval, and the choice between them depends on the type of queries you need to handle.

Classic RAG

The classic RAG pattern is the proven, generally available approach. You control the full pipeline: generate the search query (or use the user's question directly), run hybrid search with semantic ranking, take the top N most relevant results, and send them as context to the LLM.

This is the right path when questions are relatively straightforward, you have existing orchestration code you do not want to replace, or you need generally available features for production. The advantage is full control and predictable latency.

Agentic retrieval

Agentic retrieval adds an LLM planning layer before running the search. The system receives the user query, uses an LLM to decompose it into focused subqueries, runs all of them in parallel (each can be keyword, vector, or hybrid), applies semantic ranking to each result, and synthesizes a unified response with references.

This solves a problem, questions like "find the time-off policies for remote employees hired after 2023" do not have a single search dimension. They are multiple questions combined. A simple vector query tends to capture only part of the meaning.

The tradeoff is additional latency (the planning step adds time) and the fact that some agentic retrieval features are still in preview as of July 2026. The 2026-04-01 REST API has agentic retrieval generally available for programmatic access. The Azure portal and the Foundry portal still show agentic retrieval as preview.

Foundry IQ, the new knowledge base model

Foundry IQ is the unified knowledge layer Microsoft built on top of Azure AI Search for the Foundry agent ecosystem. The idea is to solve a problem that appears when an organization scales from one or two agents to dozens: each team ends up rebuilding its own RAG pipeline, with its own vector store, its own chunking logic, and its own access control system.

With Foundry IQ, you create a knowledge base once and expose it as a shared endpoint for multiple agents. The knowledge base can connect to SharePoint, OneLake, Azure Blob Storage, Fabric IQ, the web, and MCP servers. You do not need to separately configure the retrieval strategy for each source: the system does automatic routing.

Each knowledge base in Azure AI Search is also a standalone MCP server. Any MCP-compatible client, including Foundry Agent Service, GitHub Copilot, Claude, and Cursor, can invoke the knowledge_base_retrieve tool to query the base. The endpoint follows this pattern:

https://<service>.search.windows.net/knowledgebases/<name>/mcp?api-version=<version>

Foundry IQ automatically handles the indexing pipeline for connected sources: ingestion, chunking, vectorization, and enrichment. When you enable Azure Content Understanding on supported sources, complex documents with tables, figures, and headers get layout-aware enrichment without extra engineering work.

Access control and permissions are part of the design from the start. Foundry IQ uses Entra ID for document-level access control, which means that when an agent queries the knowledge base, it only receives documents the user who started the conversation has access to. That control travels automatically through the system without needing to implement separate security filters.

Chunking, because it matters more than it seems

Retrieval quality depends heavily on how you split documents before indexing. Chunks that are too large compress too much information into a single embedding and make precise retrieval harder. Chunks that are too small lose context and fragment information that belongs together.

The recommendation that appears consistently across benchmarks: 512-token chunks with 25% overlap, preserving sentence boundaries. Splitting in the middle of a sentence degrades both the embedding quality and the readability of the fragment when it reaches the LLM.

Azure AI Search has native vectorization integration that eliminates the need for custom chunking code. You configure the data source, define the skillset (including which embedding model to use), and the indexer handles the complete cycle: extracts text from PDFs and Office documents, splits it into chunks, generates embeddings, and stores them in the index. The indexer can be scheduled to run periodically and keep the index updated when source documents change.

For large volumes, uploads should be done in batches using the upload_documents API with between 500 and 1,000 documents per batch. Uploading one at a time at scale is not viable.

How to choose between the two approaches

Classic RAG works well for: direct questions with a single search dimension, existing pipelines you do not want to change, need for generally available features, latency-critical scenarios where every second counts.

Agentic retrieval makes sense for: complex conversational queries with multiple implicit questions, agents that need maximum possible relevance, new implementations where the additional latency is acceptable, and scenarios where prior conversation context is relevant for interpreting the current query.

Foundry IQ makes sense when you are building multiple agents that need access to the same data sources, or when you want to delegate pipeline management to Microsoft and focus on agent logic.

Microsoft's official documentation recommends starting with vector_semantic_hybrid on the Standard tier as the default starting point, and adding agentic retrieval when complex query patterns appear that classic RAG does not handle well.

Closing thoughts

Azure AI Search is not a vector store with some extra features. It is a retrieval platform with three ranking layers that work together: keyword for precision, vector for semantics, semantic ranker for contextual relevance. Understanding what each layer does and when to enable it is what separates a prototype from a system that performs well in production.

If you want to explore the official documentation and the agentic retrieval quickstarts:

👉 https://learn.microsoft.com/azure/search/?wt.mc_id=studentamb_510930

Official references

Main documentation: https://learn.microsoft.com/azure/search/
RAG overview: https://learn.microsoft.com/azure/search/retrieval-augmented-generation-overview
Agentic retrieval overview: https://learn.microsoft.com/azure/search/agentic-retrieval-overview
Semantic ranking overview: https://learn.microsoft.com/azure/search/semantic-search-overview
What's new: https://learn.microsoft.com/azure/search/whats-new
Foundry IQ announcement: https://techcommunity.microsoft.com/blog/azure-ai-foundry-blog/foundry-iq-unlocking-ubiquitous-knowledge-for-agents/4470812

FaroIQ: how I built a 9-agent pipeline for nonprofits with Azure AI Foundry

Carlos José Castro Galante — Fri, 03 Jul 2026 22:58:55 +0000

I'm Carlos, a Software Design student at the National University of Catamarca, Argentina. This post covers how I built FaroIQ during the Microsoft Agents League 2026: what decisions I made, why I made them, and what problems I ran into along the way.

Where the idea came from

Growing up in San Juan, Argentina, I watched organizations like Caritas collect donations through schools and universities, doing what they could with very little. The problem was never a lack of will. Those organizations know exactly what their communities need. What they lack is a way to turn that knowledge into something concrete: a plan with data, phases, and a budget.

When the hackathon started, I wanted to build something that solved that. Not a technology demo. Something that, if someone actually used it, would be useful to them.

The idea: the user describes their organization in plain language, and the system produces in under 90 seconds a needs analysis, a phased implementation plan, impact projections, a grant proposal ready to submit, and executes all of that in Microsoft 365 (Calendar, To Do, OneDrive, Email) automatically.

What FaroIQ is

FaroIQ is a community intelligence platform built on the three Microsoft IQ layers:

Foundry IQ: Azure AI Foundry with the gpt-oss-120b model for agent reasoning
Fabric IQ: Azure Blob Storage for session persistence and aggregated analytics
Work IQ: Microsoft 365 via Azure Logic Apps for execution

The name comes from the Spanish word for lighthouse. Not much more to explain there.

The architecture

Why a sequential pipeline instead of parallel agents

One of the first decisions was how to structure the nine agents. Two obvious options: run them in parallel to reduce total time, or run them in sequence where each one receives the output of all previous agents as context.

I went with the sequence. A coherent action plan requires each stage to build on the previous one. If the Planning agent doesn't know what needs the Analysis agent identified, or what resource capacity the Classification agent estimated, it ends up generating something generic. With context chaining, each agent receives the structured output of all previous agents plus its own system prompt and a JSON schema that defines exactly what it needs to return.

Agent	What it does
Research	Live Tavily web search for real statistics and comparable NGO programs
Intake	Classifies sector, urgency, target population, and resource capacity
Analyzer	Identifies primary needs, root causes, and existing community strengths
Planner	Generates phased action plan with milestones, quick wins, and risk factors
Evaluator	Projects beneficiaries, feasibility score, and expected outcomes
Critique	Reviews full output and triggers automatic revision if quality falls below 0.70
Execution	Builds Microsoft 365 payloads and triggers the Logic Apps
Grant	Writes a complete funding proposal
Chat	Conversational agent with full analysis as context, can re-run agents if constraints change

All agents use AsyncAzureOpenAI against the Azure AI Foundry endpoint. Each event (start, progress, completion) streams to the frontend in real time via WebSocket, so the user watches the pipeline execute rather than staring at a loading screen.

The autonomous revision loop

This was the part that took me the longest to think through properly. After the Evaluator finishes, the Critique agent scores the entire pipeline output between 0.0 and 1.0. If the score falls below 0.70, the system doesn't ask the user what to do. It injects the Critique's feedback as additional context and re-runs the Planner and Evaluator with those observations incorporated. Up to two cycles.

Setting the limit at two was pragmatic: a third cycle rarely improved the result meaningfully, and the total time was already close to 90 seconds. More than two revisions started to feel like a loop the user couldn't predict.

In the UI, the user can see the quality score, number of cycles completed, critical gaps identified, and specific recommendations. There's an expandable panel that shows exactly what the Critique detected and why it decided to revise. The system doesn't just improve itself silently, it shows its work.

Fabric IQ: why persist everything

From the start I wanted analyses to survive beyond the browser session. It makes no sense for a nonprofit to lose an analysis because they closed the tab or because the connection dropped on iOS (more on that later).

Each completed analysis is saved as structured JSON in Azure Blob Storage under the faroiq-lakehouse container. Each session has an 8-character code derived from the UUID, which lets anyone retrieve it without authentication. A second container called reports stores the rendered HTML version of the report as a permanent public URL.

The Intelligence Dashboard aggregates data across all stored sessions: sector distribution, average feasibility scores, urgency trends, cumulative beneficiary projections. Individual analyses become more useful over time as the dataset grows.

Work IQ: execution in Microsoft 365

Four Azure Logic Apps connect the system to Microsoft 365:

Calendar: creates Outlook events for each implementation phase
To Do: generates structured task lists with the organization name as prefix, for example [Caritas San Juan] Phase 1: Diagnosis
OneDrive: saves the full HTML report to /FaroIQ Reports
Email: delivers the complete analysis via Outlook

All Logic Apps calls run as async background tasks in the backend to avoid blocking the API response. If one fails, it gets logged but doesn't surface as an error to the user, because the M365 integrations are secondary to the analysis itself.

There's also a Declarative Agent manifest in /teams-plugin/appPackage/ for deployment in Microsoft 365 Copilot in enterprise environments, with a nine-step reasoning instruction set and six conversation starters in English and Spanish.

The hard parts

Design took longer than expected

I underestimated how much time the interface would take. There's a lot of information to show: the pipeline visualizer with each agent's state, the autonomous revision panel, the full report with tabs, the critique panel, the chat, the M365 integrations. Finding the right visual hierarchy so all of that makes sense without overwhelming the user took quite a few iterations.

The Three.js lighthouse background was its own challenge. Day mode and night mode render completely different scenes: cream tower with sunlight in day, dark navy with a starfield and volumetric beam at night. My first attempt tried to mutate the scene on theme change, but Three.js doesn't clean up that state cleanly. I ended up forcing a full remount via a key prop in React every time the theme changes. It's the most direct solution and it works without side effects.

Keeping agents from making up data

One requirement I set for myself from the beginning: the system couldn't return invented statistics. If a nonprofit is going to make decisions based on this analysis, the data needs to come from somewhere verifiable.

That's why the first agent does live web search with Tavily before the rest of the pipeline starts. Results get truncated to 3,000 characters to avoid blowing the token budget of the following agents, but that preserves the relevant information. The Analyzer and Planner have access to real data from the first step.

WebSocket and iOS

Keeping a WebSocket connection open for 60 to 90 seconds has problems, especially on iOS. Both Safari and Chrome on iPhone use WebKit, which has stricter connection limits than desktop or Android. The connection closes before the pipeline finishes.

I solved this in layers. First, a keepalive ping every 8 seconds to keep the connection alive. Second, the backend sends the session_id to the frontend before the pipeline starts, so the user has the session code from the very first second. If the connection drops, the pipeline keeps running on the server and the user can recover the full analysis by entering that code on the Session Lookup page. Third, an ErrorBoundary component shows the session code in any error state so it's never lost.

There's no perfect solution for iOS without refactoring all the streaming to Server-Sent Events or polling, which would have meant rewriting significant parts of the backend. The current solution covers the use case without breaking anything else.

What surprised me when I ran it the first time

I expected the pipeline to produce something useful. I didn't expect how detailed and specific the output would be when the agents had good input to work with.

The first time I ran a full analysis on a real nonprofit, the output had specific activities per phase, measurable milestones, risk factors with their mitigations, a funding proposal with theory of change and sustainability plan, and impact projections with confidence intervals. None of that was hardcoded. It came from the context chaining across the nine agents.

That's when I understood why the added complexity of the sequential approach was worth it.

Full stack

Backend: Python 3.12 · FastAPI · uvicorn · AsyncAzureOpenAI · azure-storage-blob · Tavily

Frontend: React 18 · TypeScript · Vite · Three.js · WebSocket

Infrastructure: Railway (backend, Hobby plan) · Vercel (frontend) · Azure Blob Storage · Azure Logic Apps · Azure AI Foundry

Integrations: Microsoft 365 (Calendar, To Do, OneDrive, Email) · Microsoft 365 Copilot (Declarative Agent)

Closing

I finished the hackathon with 227 commits, a production deploy, real sessions from real organizations, a README with screenshots of every feature, a demo video, and the submission delivered.

When I saw the pipeline visualizer running in real time, the expandable revision panel with the Critique agent's reasoning, the funding proposal generated in seconds, and the tasks showing up automatically in Microsoft To Do, I felt like I had built something that works end to end.

I entered the Reasoning Agents track at Microsoft Agents League 2026. I didn't win. But FaroIQ is deployed, it's free, and any nonprofit that finds it can use it today. That's reason enough to have built it.

How to build production AI agents with Azure AI Foundry Agent Service

Carlos José Castro Galante — Tue, 23 Jun 2026 23:55:48 +0000

For months, the Assistants API in Azure OpenAI was the only real option for building agents on Azure. It worked, but it had clear limits: only OpenAI models, no native multi-agent support, no direct integration with Microsoft's data ecosystem, and an architecture Microsoft was gradually moving away from.

That chapter closed in March 2026. Azure AI Foundry Agent Service reached general availability and became the official platform for building, deploying, and scaling AI agents on Azure. The classic Assistants API still works, but it has a retirement date: March 31, 2027. If you are starting a new project or thinking about migrating an existing one, Foundry Agent Service is where you should be building.

This article explains what the service is, how it is organized, what you can build with it, and which technical decisions matter most when designing an agent for production.

What an agent is and what it is not

Before getting into the service, it is worth being precise about the term because it gets used in very different ways depending on context.

An agent in the Microsoft Foundry ecosystem is an AI application that uses a model from the Foundry model catalog to reason about user requests and take autonomous actions to fulfill them. Unlike a chatbot that only generates text, an agent can call tools, access external data, and make decisions across multiple steps to complete a task. In some cases, agents do not even have a chat interface at all: they work autonomously in the background, triggered by system events, completing tasks on a user's or organization's behalf.

The three basic components of any agent are the model, which provides reasoning and language capabilities; the instructions, which define goals, constraints, and behavior; and the tools, which provide access to data or concrete actions like search, file operations, or API calls.

The two agent types in Foundry

Foundry Agent Service organizes agents into two main categories, and the choice between them determines how much code you write and how much control you have.

Prompt agents

Prompt agents are agents you define with instructions, tools, and configuration, and Foundry runs them without you having to write or maintain any application code. No compute to pay for, no containers to optimize, no infrastructure to scale. You define the agent from the Foundry portal or through the SDK, and the service handles the rest.

These are the right choice when the use case is well-defined, the tools available in Foundry cover what you need, and you do not require complex orchestration logic written by hand. For most enterprise automation, customer support, or data analysis scenarios, prompt agents are sufficient and much faster to implement.

Hosted agents

Hosted agents let you bring your own agent code, packaged as a container, and have Foundry run it with a managed endpoint, automatic scaling, identity, and built-in observability. You can write that code with Agent Framework, LangGraph, the OpenAI Agents SDK, the Anthropic Agent SDK, the GitHub Copilot SDK, or your own code.

This path makes sense when you need orchestration logic that cannot be expressed with instructions alone, very specific integrations with proprietary systems, or full control over agent behavior at each step. Hosted agents are expected to reach general availability in early July 2026.

The technical foundation: Responses API

Foundry Agent Service is built on the OpenAI Responses API. This has an important practical implication: if you already have code running against the Responses API directly, migrating it to Foundry requires minimal changes. What you gain by doing so is enterprise security, private networking, Entra ID access control, full traceability, and evaluation, layered on top of your existing agent logic.

SDKs are available for Python, JavaScript, TypeScript, Java, and .NET. The stable version is 2.0.0, released in March 2026. Starting with that version, the package bundles openai and azure-identity as direct dependencies, so you no longer need to install them separately.

import os
from azure.identity import DefaultAzureCredential
from azure.ai.projects import AIProjectClient
from azure.ai.projects.models import PromptAgentDefinition

credential = DefaultAzureCredential()
client = AIProjectClient(
    endpoint=os.environ["AZURE_AI_FOUNDRY_ENDPOINT"],
    credential=credential
)

agent = client.agents.create_agent(
    model="gpt-4o",
    name="support-agent",
    instructions="You are a technical support assistant. Answer questions using the available knowledge base.",
)

thread = client.agents.threads.create()
client.agents.messages.create(
    thread_id=thread.id,
    role="user",
    content="How do I restart the authentication service?"
)

run = client.agents.runs.create_and_process(
    thread_id=thread.id,
    agent_id=agent.id
)

messages = client.agents.messages.list(thread_id=thread.id)
for msg in messages:
    if msg.role == "assistant":
        print(msg.content[0].text.value)

Available tools

The real utility of an agent depends on which tools it can invoke. Foundry Agent Service has a wide set of built-in tools and supports external tools via MCP.

Built-in tools

File Search lets the agent search through files uploaded to the service, useful for internal knowledge bases.

Code Interpreter runs Python code in an isolated sandbox environment, ideal for data analysis and chart generation.

Bing Search lets the agent search the web to answer questions that require up-to-date information.

SharePoint is now a first-class knowledge tool, integrated directly into the service. Agents can access SharePoint documents without building a custom RAG pipeline.

Microsoft Fabric through Fabric IQ lets agents query structured data from Microsoft's data platform, including semantic models and ontologies.

Logic Apps opens access to over 1,400 Azure Logic Apps workflows as tools for agents, covering a huge range of integrations with external systems.

Deep Research runs a multi-step research process using the Azure OpenAI o3-deep-research model with Bing Search as the knowledge source.

Computer Use and Browser Automation are in preview. The first lets the agent interact with desktop application user interfaces. The second allows executing real tasks in the browser through natural language, using isolated Microsoft Playwright sessions.

MCP and Toolboxes

Model Context Protocol is the open standard Foundry adopted as the primary mechanism for connecting agents with external tools. You can add remote MCP servers directly from the portal catalog, including the Azure DevOps MCP Server in public preview. You can also expose your own tools hosted on Azure Functions through the MCP webhook endpoint.

Toolboxes, available in public preview since Build 2026, lets you define a curated set of tools once, manage them centrally in Foundry, and expose them through a single MCP-compatible endpoint. Any agent or MCP client can consume a Toolbox regardless of the framework it uses. Toolboxes include explicit versioning to control when changes take effect in production.

Multi-agent: Connected Agents

When a task is too complex for a single agent, Foundry Agent Service supports multi-agent workflows through Connected Agents, available in preview.

Connected Agents enable point-to-point interactions where an agent can call other agents as tools to delegate specialized tasks. The primary agent coordinates and the secondary agent handles the subtask, without needing an external orchestrator.

For more complex workflows, Foundry integrates with the converged runtime for Semantic Kernel and AutoGen, combining AutoGen's dynamic orchestration patterns with Semantic Kernel's modular, production-grade architecture. The result is a unified API for defining, chaining, and managing both single-agent and multi-agent workflows, with consistent behavior between local environments and the cloud.

Security for enterprise environments

An agent that accesses internal data, executes actions on production systems, and makes autonomous decisions needs very different security controls than a public chatbot.

Entra Agent ID gives each agent its own Microsoft Entra identity. This means agents authenticate as entities with their own permissions, not as the user invoking them, which allows applying the principle of least privilege at the agent level.

Private networking is supported at GA. You can bring your own virtual network (BYO VNet) for a completely isolated environment, with no public egress, container and subnet injection into your network. Private networking extends to tool connectivity, including MCP servers, Azure AI Search, and Fabric data agents.

Integrated content safety includes guardrails to reduce unsafe outputs and mitigate prompt injection risks, including Cross-Prompt Injection Attacks (XPIA).

Observability in production

Running an agent in production without visibility into what it is doing is not viable. Foundry Agent Service has built-in observability that reached general availability in March 2026.

Tracing captures the complete end-to-end execution path: requests, tool invocations, and responses, with OpenTelemetry semantics for AI workloads that include memory, state, and planning. Evaluation results link directly to the trace that produced them, so when a regression appears you can go from the score to the exact production trace that exposed it.

Built-in evaluators cover coherence, relevance, groundedness, retrieval quality, and safety, for both direct generation and RAG scenarios. Custom evaluators, in preview, let you define LLM-as-a-judge evaluation logic aligned to specific business requirements or regulatory standards.

Distribution: where agents live

An agent without a distribution channel reaches no users. Foundry supports multiple ways to publish agents.

The most direct is a REST endpoint that any application can consume. For Microsoft environments, agents can be published directly to Microsoft Teams and Microsoft 365 Copilot, with identity, permissions, and policies flowing automatically through the platform's channels. This capability was planned for general availability in June 2026.

The Entra Agent Registry centralizes the registration and discovery of agents across the organization, so teams can find and reuse existing agents rather than rebuilding them.

The A2A (agent-to-agent) protocol, in preview, enables communication between agents from different systems.

What not to use today

If you come from Azure OpenAI and use the classic Assistants API, it is deprecated and retires on March 31, 2027. The classic service is now documented under /azure/foundry-classic/agents/ on Microsoft Learn. The new service lives under /azure/foundry/agents/.

Migrating from the classic Assistants API to the new Agent Service is not trivial but it is not complex either: the official migration guide is available on Microsoft Learn.

How do I get started?

Foundry Toolkit for VS Code reached general availability at Build 2026. It lets you create agents from templates or using GitHub Copilot directly in the IDE, debug runs locally with trace visualization, connect Toolboxes, and deploy to Foundry Agent Service without leaving VS Code.

If you'd like to experiment without installing anything, the Azure AI Foundry portal at ai.azure.com lets you create, configure, debug, and test agents in no-code mode, view conversation threads, add tools, and interact with the agent directly from the interface.

If you want to explore the official documentation and quickstarts:

👉 https://learn.microsoft.com/azure/ai-foundry/agents/?wt.mc_id=studentamb_510930

Building agents on Azure no longer requires assembling infrastructure from scratch or depending on APIs that will disappear. Foundry Agent Service covers the runtime, identity, networking, tools, memory, and observability as parts of the service. What remains on the developer's side is deciding what the agent does, with which tools, and how to distribute it. Which is, in the end, the interesting part.

Azure AI Foundry, qué es y por qué reemplaza todo lo que conocías de Azure AI

Carlos José Castro Galante — Sat, 13 Jun 2026 15:04:07 +0000

Si en algún momento trabajaste con Azure OpenAI Service o Azure AI Studio y hoy entrás a la documentación de Microsoft esperando encontrar lo mismo, probablemente te perdiste. Esto es debido a que, los nombres cambiaron, los recursos se consolidaron, y lo que antes eran tres servicios separados ahora vive bajo un solo nombre: Azure AI Foundry.

Este post explica qué es Azure AI Foundry en 2026, cómo se diferencia de lo que había antes, y qué necesitás entender si estás empezando o si venís de usar Azure OpenAI directamente.

Qué es Azure AI Foundry

Azure AI Foundry es la plataforma unificada de desarrollo de IA de Microsoft. Reemplazó a Azure AI Studio a fines de 2024 y expandió su alcance más allá de los modelos de OpenAI para incluir Phi, Mistral, Llama, Cohere y muchos más.

En términos concretos, es el lugar donde Microsoft concentró todo lo que antes estaba disperso: el catálogo de modelos, las herramientas de evaluación y prompt engineering, el despliegue de endpoints, el fine-tuning, la observabilidad y la construcción de agentes. Todo bajo un solo portal en ai.azure.com y una sola capa de recursos en Azure.

El catálogo tiene más de 1900 modelos que van desde Foundation Models y Reasoning Models hasta Small Language Models, modelos multimodales, modelos de dominio específico y modelos industriales.

La diferencia con Azure OpenAI Service

Esta es la confusión más común y es importante aclararla

Azure OpenAI Service es un servicio administrado enfocado exclusivamente en dar acceso a los modelos de OpenAI como GPT-5, GPT-4o, GPT-4.1, embeddings y modelos multimodales. Corre en la infraestructura de Azure y agrega características empresariales como seguridad con Microsoft Entra ID, filtros de contenido, escalabilidad e integración con herramientas de Azure.

Azure AI Foundry es una plataforma más amplia orientada a construir, personalizar, desplegar y administrar aplicaciones de IA y agentes. Incluye Azure OpenAI como uno de sus componentes bajo Foundry Models.

La manera más simple de entenderlo: Azure OpenAI Service sigue existiendo y podés usarlo directamente para llamadas a la API sin necesitar todo el ecosistema de Foundry. Pero si estás construyendo algo más complejo, con múltiples modelos, evaluación, agentes o fine-tuning, Azure AI Foundry es donde todo eso vive hoy.

Los modelos disponibles

El catálogo incluye modelos de OpenAI, Anthropic Claude, Fireworks AI, DeepSeek, xAI, Hugging Face, Meta, Mistral AI, Cohere, Stability AI, NVIDIA y más.

Los modelos del catálogo se dividen en dos categorías principales. Los modelos vendidos directamente por Azure son hosteados y vendidos por Microsoft bajo sus propios términos de producto. Microsoft los evaluó y están profundamente integrados en el ecosistema de Azure. Los modelos de partners y comunidad son soportados por sus respectivos proveedores.

La distinción importa en la práctica porque los modelos directos de Azure vienen con SLA garantizado de Microsoft y soporte de primer nivel, mientras que los modelos de partners tienen niveles variables de soporte. Para producción en entornos empresariales, ese detalle puede ser determinante.

Qué desapareció y qué va a desaparecer

Hay dos cosas concretas que tenés que tener en cuenta si venís de Azure OpenAI.

La estructura de recursos colapsó. Antes, un despliegue de IA típico en Azure requería tres recursos separados: una cuenta de Azure OpenAI, una cuenta de Azure AI Services y un AI Hub. Eso se consolidó en un solo recurso de Foundry que hostea múltiples proyectos.

La Assistants API tiene una fecha de retiro definitiva el 26 de agosto de 2026, reemplazada por la Foundry Agent Service Responses API. Si tenés agentes construidos sobre la Assistants API, el tiempo para migrar es ahora.

Lo que podés hacer desde el portal

El portal de Azure AI Foundry en ai.azure.com te da acceso a todo sin tener que tocar código en primera instancia. Podés explorar el catálogo de modelos, comparar modelos lado a lado usando tus propios datos y prompts, hacer fine-tuning de modelos como GPT-4o, GPT-4o-mini, Llama y Phi, desplegar endpoints con un par de clics, y monitorear el comportamiento de los modelos en producción.

El Serverless API, también llamado Model as a Service o MaaS, es el tipo de despliegue más accesible para empezar. Te permite acceder a modelos hosteados en Azure sin necesidad de provisionar GPUs ni gestionar infraestructura de backend. Pagás por lo que usás.

Desde el código

El SDK oficial para trabajar con Azure AI Foundry desde código es azure-ai-projects, disponible para Python, JavaScript y TypeScript, y .NET. La versión actual es 2.2.0 y trae soporte para definiciones de agentes externos, skills, toolboxes, registro de pesos de modelos, rutinas y trabajos de optimización.

from azure.ai.projects import AIProjectClient
from azure.identity import DefaultAzureCredential

client = AIProjectClient(
    endpoint="https://tu-endpoint.services.ai.azure.com/api/projects/tu-proyecto",
    credential=DefaultAzureCredential()
)

response = client.inference.get_chat_completions(
    model="gpt-4o",
    messages=[{"role": "user", "content": "Hola, qué es Azure AI Foundry?"}]
)
print(response.choices[0].message.content)

Para llamadas directas a modelos sin toda la capa de proyectos, podés seguir usando el SDK de Azure OpenAI que ya conocés, ya que los endpoints son compatibles.

Y si estudio para la AI-103, ¿dónde encaja esto?

Si estás preparándote para la certificación AI-103, Azure AI Foundry es la plataforma central del examen. Microsoft Foundry reemplazó a Azure AI Studio como el entorno de referencia para construir aplicaciones de IA listas para producción. Entender cómo se organiza el portal, cómo se crean proyectos y cómo se despliegan modelos es conocimiento directamente evaluado.

Lo mismo aplica si venís del AI-102: la arquitectura que antes estudiabas con Azure Cognitive Services y Azure Applied AI Services ahora está reorganizada dentro de Foundry. Los servicios siguen existiendo, pero el punto de acceso y la forma de gestionarlos cambió.

Entonces, ¿cómo empiezo?

Azure AI Foundry tiene una capa gratuita en el portal que te permite explorar el catálogo y probar modelos sin necesitar una suscripción de pago. Para despliegues en producción, el modelo de Serverless API cobra por token consumido dependiendo del modelo que elijas.

Si querés explorar la documentación oficial y empezar con el portal:

👉 https://learn.microsoft.com/azure/ai-foundry/?wt.mc_id=studentamb_510930

La confusión de nombres entre Azure OpenAI, Azure AI Studio y Azure AI Foundry frenó a mucha gente en los últimos meses. La realidad es que la plataforma evolucionó hacia algo más completo y el punto de entrada hoy es uno solo: Foundry. Todo lo demás se accede desde ahí.

Azure Functions para developers que nunca usaron serverless

Carlos José Castro Galante — Sat, 16 May 2026 03:14:21 +0000

Si alguna vez escuchaste "serverless" y pensaste que era solo marketing, entendible. El nombre confunde porque los servidores siguen existiendo, simplemente dejás de encargarte de ellos. Azure Functions es el servicio serverless de Microsoft y en 2026 es uno de los más usados para construir backends event-driven, APIs livianas, pipelines de datos y, cada vez más, herramientas para agentes de IA.

Este post es para developers que nunca tocaron serverless y quieren entender qué es en la práctica, no en teoría.

Qué resuelve Azure Functions

El modelo tradicional para desplegar código en la nube implica provisionar un servidor o contenedor, configurarlo, mantenerlo activo aunque no haya tráfico, y pagar por ese tiempo aunque esté idle. Funciona bien para aplicaciones que reciben tráfico constante, pero es ineficiente para tareas que se ejecutan cuando pasa algo: llega un archivo, alguien hace un request HTTP, se cumple un horario, llega un mensaje a una cola.

Azure Functions invierte ese modelo. Escribís el código, definís qué lo dispara, y Azure se encarga de ejecutarlo cuando eso pasa. No pagás cuando no corre. No configurás servidores. No pensás en escalado porque el servicio escala solo en respuesta a la demanda.

El modelo tiene un nombre técnico más preciso: Functions as a Service (FaaS). Serverless es el paraguas más amplio, pero FaaS es lo que Azure Functions implementa concretamente.

Lenguajes soportados

Azure Functions soporta C#, Java, JavaScript, TypeScript, Python y PowerShell de forma oficial. También tiene soporte para Go y Rust, aunque con menos integración nativa. Si venís del mundo web y trabajás con JavaScript o TypeScript, podés empezar con lo que ya sabés.

Los dos conceptos que tenés que entender bien

Antes de escribir una sola línea de código, hay que tener claros dos conceptos que van a aparecer en toda la documentación.

Triggers son los eventos que hacen correr tu función. Una función tiene exactamente un trigger. Algunos ejemplos reales:

Un request HTTP llega a una URL (HTTP trigger)
Se cumple un horario definido, por ejemplo todos los días a las 3am (Timer trigger)
Llega un mensaje a una cola de Azure Storage (Queue trigger)
Se sube un archivo a un blob container (Blob trigger)
Llega un evento de Azure Event Grid o Event Hubs

Bindings son declaraciones que conectan tu función con otros servicios de Azure sin que tengas que escribir el código de esa conexión a mano. Hay bindings de entrada (leer datos) y de salida (escribir datos).

Un ejemplo concreto: tenés una función que se dispara cuando llega un archivo a Blob Storage, lee ese archivo, lo procesa, y escribe el resultado en una tabla de Cosmos DB. En lugar de escribir el SDK de Blob y el SDK de Cosmos DB dentro de la función, declarás esas conexiones como bindings y Azure se encarga de la autenticación y la inyección de los datos.

// Azure Function con HTTP trigger en JavaScript
const { app } = require("@azure/functions");

app.http("miPrimeraFuncion", {
  methods: ["GET", "POST"],
  authLevel: "anonymous",
  handler: async (request, context) => {
    context.log("Función ejecutada");
    const nombre = request.query.get("nombre") || "mundo";
    return { body: `Hola, ${nombre}` };
  },
});

Los planes de hosting y cuál elegir hoy

Esta es la parte donde más gente se pierde porque la documentación lista muchas opciones y no siempre queda claro cuándo usar cada una.

En 2026, Microsoft recomienda explícitamente el Flex Consumption plan para nuevos proyectos serverless. Es importante saberlo porque mucho material en internet todavía habla del Consumption plan clásico como si fuera la opción estándar, y eso está cambiando.

Consumption plan es el más conocido. Incluye un free grant mensual de 1 millón de ejecuciones y 400,000 GB-s por suscripción. El problema es que no tiene integración con redes virtuales, tiene un límite de ejecución de 10 minutos, y los cold starts en .NET aislado pueden llegar a entre 2 y 7 segundos. Microsoft anunció el retiro del plan Linux Consumption para septiembre de 2028.

Flex Consumption plan es el reemplazo recomendado. Tiene cold starts más rápidos, integración con virtual networks, escalado por función individual (no todas las funciones del app escalan juntas), concurrencia configurable y múltiples tamaños de instancia. El free grant es de 250,000 ejecuciones y 100,000 GB-s por mes por suscripción. Tiene SLA de 99.95%.

Premium plan elimina los cold starts completamente con instancias pre-calentadas. El costo es de alrededor de 146 dólares por mes como mínimo, lo que lo hace justificable solo cuando los cold starts afectan la experiencia de usuarios reales.

Dedicated plan corre en un App Service existente. Tiene sentido si ya tenés infraestructura pagada y querés aprovecharla, pero pierde gran parte del valor de serverless.

La decisión práctica para alguien que arranca es esta: si el proyecto es nuevo, usá Flex Consumption. Si tenés funciones existentes en el Consumption plan clásico sobre Linux, lo correcto es migrarlas antes de que el plan se retire.

Algo que tenés que saber si usás .NET

El modelo in-process de Azure Functions, donde el código corre en el mismo proceso que el host, está programado para retirarse en noviembre de 2026. El modelo que hay que usar hoy es el isolated worker model, que corre el código en un proceso separado. Esto le da más flexibilidad en versiones de .NET y mejor aislamiento, pero si encontrás documentación que habla de in-process como si fuera la opción vigente, ese material está desactualizado.

Durable Functions para cuando una ejecución no alcanza

Azure Functions tiene un límite de tiempo de ejecución. Si necesitás orquestar un flujo de trabajo más largo, como procesar miles de archivos en secuencia, coordinar múltiples llamadas a APIs externas, o manejar aprobaciones humanas que pueden tardar horas, existe Durable Functions.

Durable Functions es una extensión que permite escribir workflows con estado en un entorno serverless. El runtime maneja checkpoints, reintentos y recuperación automáticamente. Si una instancia falla en el medio de un workflow, el sistema retoma desde donde estaba.

# Ejemplo de orquestación con Durable Functions en Python
import azure.durable_functions as df

def orchestrator_function(context: df.DurableOrchestrationContext):
    resultado1 = yield context.call_activity("ProcesarDatos", "input1")
    resultado2 = yield context.call_activity("EnviarEmail", resultado1)
    return resultado2

main = df.Orchestrator.create(orchestrator_function)

Azure Functions y agentes de IA en 2026

Una tendencia real en 2026 es usar Azure Functions como infraestructura serverless para agentes de IA. El soporte para servidores MCP (Model Context Protocol) alcanzó disponibilidad general con autenticación OBO (On-Behalf-Of), lo que permite que agentes de IA accedan a herramientas y datos externos de forma segura usando identidades de Microsoft Entra ID.

En términos prácticos, esto significa que podés deployar un servidor MCP en Azure Functions y que agentes de GitHub Copilot, Microsoft 365 Copilot u otros clientes compatibles puedan invocar las herramientas que exponés, con autenticación empresarial incluida y sin gestionar infraestructura propia.

Dónde practicar sin gastar nada

La cuenta gratuita de Azure incluye créditos y el free grant del Consumption plan cubre ampliamente el uso de aprendizaje. Para el Flex Consumption plan, las primeras 250,000 ejecuciones del mes no tienen costo.

Microsoft Learn tiene un módulo oficial de introducción a Azure Functions que podés seguir en el navegador con un sandbox gratuito, sin necesitar suscripción propia:

👉 https://learn.microsoft.com/azure?wt.mc_id=studentamb_510930

La curva de entrada de Azure Functions es más suave de lo que parece. Si sabés escribir una función en cualquier lenguaje y entendés qué es un evento, ya tenés lo necesario para empezar. El resto se aprende construyendo cosas reales.

Carlos José Castro Galante es Desarrollador Full Stack y Azure AI Engineer certificado por Microsoft (AI-102, AI-900, AZ-900) e ITBA. Disponible para proyectos freelance desde Argentina.

Python para inteligencia artificial, por dónde empezar si sos developer junior

Carlos José Castro Galante — Tue, 12 May 2026 14:55:17 +0000

Python es el lenguaje más popular del mundo según el índice TIOBE de principios de 2026, con más del 21% de participación, y la razón principal de ese número es la IA. En la encuesta de Stack Overflow 2025, el uso de Python entre developers pasó del 51% al 58%, el mayor salto anual de cualquier lenguaje en los últimos años. Es que los frameworks más importantes de IA, TensorFlow, PyTorch, Scikit-learn, todos corren sobre Python.

Si sos developer junior y querés entrar al mundo de la IA, la pregunta no es si aprender Python. La pregunta es por dónde empezar sin ahogarte en librerías que no vas a necesitar todavía.

Por qué Python y no otro lenguaje

Hay razones concretas. Los frameworks de machine learning (ML) más usados en producción son Python-nativos. La comunidad es enorme, lo que significa que vas a encontrar documentación, respuestas en Stack Overflow y tutoriales para casi cualquier problema que tengas. La sintaxis es limpia y permite concentrarse en el problema antes que en el lenguaje.

Datos reales: según Stack Overflow 2025, el 84% de los developers usa o planea usar herramientas de IA en su trabajo. Python es el lenguaje que conecta esas herramientas. No hay un segundo cercano para ese rol específico.

El error más común cuando empezás

La mayoría de los artículos sobre Python para IA te tiran 15 librerías en la primera pantalla. NumPy, Pandas, Matplotlib, Scikit-learn, TensorFlow, PyTorch, Keras, Hugging Face, LangChain, y siguen. El resultado es que no sabés por dónde empezar y terminás aprendiendo el nombre de cosas sin entender cómo se conectan.

La realidad de un proyecto de machine learning es que tiene un orden. Primero vas a manipular datos, después los vas a visualizar para entender qué tenés, después vas a preparar esos datos para un modelo, y finalmente vas a entrenar y evaluar el modelo. Cada librería existe para una parte específica de ese flujo, y si aprendés en ese orden, todo tiene sentido mucho más rápido.

El flujo real y qué usar en cada parte

Fundamento matemático de los datos

NumPy es la base de casi todo el ecosistema. Es una librería para operaciones numéricas con arrays multidimensionales, y la razón por la que Python puede hacer cálculos a velocidad de C sin que vos lo notes. No necesitás dominarla en profundidad al principio, pero entender cómo funciona un array de NumPy te va a evitar mucha confusión después.

import numpy as np

datos = np.array([2, 4, 6, 8, 10])
print(datos.mean())  # 6.0
print(datos.std())   # 2.8...

Manipulación de datos

Pandas es la herramienta para trabajar con datasets reales, los que vienen en CSV, Excel o bases de datos. Te permite cargar, limpiar, filtrar y transformar datos con una API que después de un par de días ya se siente natural.

import pandas as pd

df = pd.read_csv("datos.csv")
print(df.head())
print(df.isnull().sum())  # cuántos valores faltantes hay por columna

En el mundo real, pasar del 70% al 80% del tiempo de un proyecto de ML se va en esta etapa. Datos sucios, columnas mal tipadas, valores faltantes. Pandas es donde se resuelve eso.

Visualización

Matplotlib es el motor base para gráficos en Python. No es el más bonito, pero es el más compatible con el resto del ecosistema. Seaborn está construido sobre Matplotlib y te da gráficos estadísticos con menos código. Para proyectos donde el resultado tiene que mostrarse en un dashboard o una web, Plotly es la opción más usada en 2026.

import matplotlib.pyplot as plt

plt.plot([1, 2, 3, 4], [10, 20, 15, 30])
plt.title("Mi primer gráfico")
plt.show()

Machine learning clásico

Scikit-learn es el punto de entrada correcto para cualquier junior que quiere construir su primer modelo predictivo. Tiene una API consistente que funciona igual para regresión lineal, árboles de decisión, clustering, o métricas de evaluación. Open source, con licencia BSD, y con una de las documentaciones más claras del ecosistema.

from sklearn.linear_model import LinearRegression
from sklearn.model_selection import train_test_split
from sklearn.metrics import mean_squared_error

X_train, X_test, y_train, y_test = train_test_split(X, y, test_size=0.2)
modelo = LinearRegression()
modelo.fit(X_train, y_train)
predicciones = modelo.predict(X_test)
print(mean_squared_error(y_test, predicciones))

No aprendas TensorFlow ni PyTorch antes de entender bien Scikit-learn. Esa es una de las cosas que más demora el progreso de los developers juniors.

Deep learning

Una vez que tenés claro el flujo de datos y entrenaste modelos clásicos con Scikit-learn, recién ahí tiene sentido entrar a deep learning. Las dos opciones principales son PyTorch y TensorFlow.

PyTorch en 2026 domina en investigación y está ganando terreno fuerte en producción. Su modelo de ejecución es más intuitivo para quien viene de Python porque permite inspeccionar qué pasa en cada paso. TensorFlow tiene ventajas en despliegue a escala, con herramientas como TensorFlow Serving y TFLite para móviles. Keras está integrada como la API de alto nivel de TensorFlow y reduce bastante el boilerplate.

Para un junior que arranca, PyTorch es el camino más recomendado hoy porque tiene más recursos de aprendizaje modernos y es el que más se usa en el ecosistema open source.

Modelos de lenguaje y NLP

Hugging Face Transformers es la librería estándar para trabajar con modelos de lenguaje preentrenados. Modelos como BERT, GPT y sus variantes están disponibles con pocas líneas de código. Para proyectos que necesitan procesar texto en volumen o integrar un LLM, es el punto de entrada correcto.

from transformers import pipeline

clasificador = pipeline("sentiment-analysis")
resultado = clasificador("Este artículo es muy útil")
print(resultado)

Un roadmap realista en tiempo

Si podés dedicarle entre una y dos horas por día, esta es una progresión que podrías seguir:

Semanas 1 y 2: bases de Python si no las tenés sólidas. Variables, funciones, listas, diccionarios, clases básicas. Sin esto, todo lo demás se complica.
Semanas 3 y 4: NumPy y Pandas con datasets reales. Kaggle tiene datasets gratuitos para practicar desde el primer día.
Semana 5: visualización con Matplotlib y Seaborn. No necesitás profundizar mucho, con poder graficar distribuciones y correlaciones alcanza.
Semanas 6 al 8: Scikit-learn. Regresión lineal, árboles de decisión, evaluación de modelos con train-test split y métricas como accuracy, RMSE y F1.
Semanas 9 al 12: introducción a PyTorch. Tensores, autograd, tu primera red neuronal.
Semanas 13 en adelante: proyectos propios. Un clasificador de imágenes, un modelo que predice algo que te interese, un chatbot básico. El portfolio importa más que los cursos.

Lo que no necesitás aprender todavía

LangChain, LlamaIndex, MLflow, Ray, Spark, Airflow. Son herramientas reales y muy usadas en producción, pero son para cuando ya sabés construir y evaluar modelos. Aprenderlas antes es como aprender a hacer pit stop en Fórmula 1 antes de aprender a manejar.

Dónde practicar gratis desde hoy

Kaggle tiene cursos cortos de Python, Pandas y machine learning completamente gratuitos, con entorno de notebooks en el navegador sin instalar nada. Fast.ai tiene un curso de deep learning que es probablemente el mejor recurso gratuito para pasar de Scikit-learn a PyTorch. Microsoft Learn también tiene rutas de aprendizaje sobre Python e IA que podés seguir a tu ritmo:

👉 https://learn.microsoft.com/training/browse/?filter-products=python&terms=python&wt.mc_id=studentamb_510930

El camino no es corto, pero tampoco es imposible. La clave es ir en orden y no saltar a deep learning antes de tener claro cómo funciona un pipeline de datos. Los developers que más rápido avanzan no son los que leen más, son los que construyen cosas desde el primer mes aunque sean simples.

Microsoft 365 Copilot para developers en 2026, lo que de verdad podés construir

Carlos José Castro Galante — Mon, 27 Apr 2026 01:23:07 +0000

Hace unos días publiqué algo sobre GitHub Copilot. Hoy quiero hablar del primo menos entendido pero igual de potente: Microsoft 365 Copilot. La diferencia central es que GitHub Copilot vive en tu IDE y te ayuda a escribir código, mientras que Microsoft 365 Copilot vive dentro de Word, Excel, PowerPoint, Outlook, Teams y SharePoint, y trabaja con los datos reales del negocio. Para quienes desarrollamos, eso abre una superficie de extensibilidad enorme que no termina de explicarse en los anuncios de marketing. Este post intenta dar una imagen precisa de qué podés construir hoy, qué herramientas usar y qué decisiones técnicas vas a tener que tomar.

La división fundamental, declarative agents vs custom engine agents

Microsoft tiene dos formas de extender Copilot, y elegir la correcta es la decisión más importante del proyecto.

Un declarative agent es una versión personalizada de Microsoft 365 Copilot. Vos no traés tu propio modelo ni tu propia orquestación: usás el orquestador, los modelos foundation y la infraestructura de Copilot, pero le declarás instrucciones específicas, conocimiento adicional y acciones que puede ejecutar. En la práctica, es un archivo JSON, el manifest, que le dice a Copilot cómo comportarse para un escenario concreto. No requiere hosting propio, hereda toda la seguridad y compliance de Microsoft 365, y se siente como Copilot porque corre dentro de la misma interfaz.

Un custom engine agent es lo opuesto en términos de control. Vos traés tu propio orquestador, podés elegir el modelo (Azure OpenAI, otro modelo de Foundry, lo que sea), usar frameworks como Semantic Kernel o LangChain, y desplegarlo a múltiples canales: Microsoft 365 Copilot, Teams, web, custom apps. Requiere hosting propio en Azure, lo pagás vos, y tenés que asegurar compliance y políticas de IA responsable por tu cuenta.

La regla práctica que sigo: si la pregunta es responder algo basado en datos de la organización con tono y reglas específicas, declarative agent. Si necesitás workflows multi-paso complejos, mensajes proactivos sin que el usuario haga nada, UI custom con Adaptive Cards interactivas, o usuarios sin licencia de Copilot, custom engine agent.

Lo que cambió fuerte en 2026

El primer cambio de fondo es el soporte oficial de Model Context Protocol (MCP) dentro de declarative agents. Hasta hace poco, conectar tu agente a un servicio externo significaba escribir un OpenAPI spec, configurar autenticación a mano, y rezar para que el orchestrator lo invocara. Con MCP, le pasás al Agents Toolkit la URL de tu MCP server, el toolkit descubre las tools disponibles, genera el plugin spec y conecta todo. La barrera de entrada para integrar un servicio externo bajó de "una semana de configuración" a "unos minutos".

El segundo cambio relevante es MCP Apps y OpenAI Apps SDK. Ahora podés agregar widgets de UI interactivos a tus declarative agents extendiendo acciones basadas en MCP servers. Los widgets se renderizan inline o en pantalla completa dentro de Microsoft 365 Copilot. Esto resuelve una de las grandes limitaciones históricas de los declarative agents, que eran solo texto.

El tercer cambio es el plugin Microsoft 365 Agents Toolkit para Claude Code y GitHub Copilot CLI, parte del paquete microsoft/work-iq. Te permite hacer scaffolding, configurar y desplegar un declarative agent completo (incluido MCP server, autenticación y widget) usando lenguaje natural en la terminal. Está en preview, requiere consentimiento de admin, pero cambia el dev loop radicalmente.

El cuarto detalle importante es que el TeamsFx SDK está siendo deprecado. Su deprecación completa está planeada para julio de 2026. Si arrancás un proyecto nuevo, no uses TeamsFx, usá Microsoft 365 Agents SDK directamente.

Las herramientas que vas a usar

Microsoft 365 Agents Toolkit es la extensión para Visual Studio Code y Visual Studio. Es una evolución del antes llamado Teams Toolkit. Incluye scaffolding, debugging, deployment, integración con Microsoft 365 Agents SDK, Azure AI Foundry y TypeSpec para Copilot. Si vas pro-code, este es el punto de entrada.

Microsoft 365 Agents SDK es el framework para construir custom engine agents full-stack y multicanal. Es agnóstico al modelo de IA, así que podés combinar Azure OpenAI, modelos open source de Foundry, o lo que necesites. El repositorio oficial está en github.com/microsoft/Agents.

Copilot Studio es la opción low-code. Funciona como SaaS gestionado, no necesitás manejar infraestructura, y es ideal cuando el equipo no es full developer o cuando querés iterar rápido. Soporta tanto declarative agents como custom engine agents.

Microsoft 365 Agents Playground es un entorno sandbox web para testear agentes localmente sin necesidad de un tenant de developer ni servicios de tunneling. Esto soluciona un dolor de cabeza histórico de Teams development.

El stack mental para tomar decisiones

Antes de elegir tooling, conviene responder cuatro preguntas en orden.

Primero, ¿tus usuarios tienen licencia de Microsoft 365 Copilot? Si la respuesta es no para una porción significativa, los declarative agents quedan limitados o directamente fuera de juego, y vas a custom engine agents donde el costo se mide por consumo de Azure.

Segundo, ¿necesitás un modelo específico distinto de los que usa Copilot? Si la respuesta es sí, custom engine. Si los modelos que ya trae Copilot te alcanzan, declarative simplifica todo.

Tercero, ¿el agente necesita iniciar conversaciones por su cuenta o ejecutar acciones sin que el usuario lo invoque? Si la respuesta es sí, custom engine, porque los declarative agents son siempre user-initiated.

Cuarto, ¿el agente tiene que correr fuera del ecosistema Microsoft 365? Si necesitás soporte de portales custom, web pública, canales externos, custom engine te lo permite, declarative no.

Cuando las cuatro respuestas apuntan a declarative, declarative gana sin discusión, porque es más rápido de construir, más barato, y hereda toda la seguridad de Microsoft 365 sin que vos tengas que diseñar nada.

Costos sin maquillaje

Los declarative agents no incurren costos adicionales de hosting porque corren sobre la infraestructura de Copilot. Los usuarios sin licencia de Copilot pueden acceder a custom engine agents en Microsoft 365 Copilot Chat, pero pueden incurrir cargos pay-as-you-go si el agente interactúa con datos del tenant (SharePoint o Microsoft 365 Copilot connectors), basado en los meters de Copilot Studio.

Los custom engine agents corren con tu propia orquestación y modelos, así que pagás Azure AI Services por la inferencia, Azure App Service o equivalente para hosting, y opcionalmente Azure Bot Service si los publicás en múltiples canales. El costo total varía con la complejidad de orquestación y el volumen de inferencias.

Para builders que están armando declarative agents, no necesitás una licencia de Copilot Studio si solo construís agentes. Si querés grounding en datos organizacionales, necesitás licencia o consumo metering en el tenant.

Qué stack elegir hoy según tu caso

Si arrancás de cero y tu agente vive dentro del ecosistema Microsoft 365, abrí Visual Studio Code con la extensión Microsoft 365 Agents Toolkit, elegí declarative agent, conectalo a un MCP server si necesitás integraciones externas, y desplegalo. Es el camino más rápido.

Si necesitás integrar modelos custom o lógica compleja, usá Microsoft 365 Agents SDK con TypeScript o Python, montalo en Azure App Service con Azure AI Foundry como backend de modelos, y publicalo a Microsoft 365 Copilot, Teams y los canales que precises. El SDK ya trae los componentes para state, storage, y manejo de actividades.

Si el equipo no es full developer pero el caso de uso es claro, Copilot Studio te lleva de cero a producción sin escribir tanto código. Es especialmente potente para agentes conversacionales con flujos definidos.

El detalle que casi nadie menciona

Microsoft 365 Copilot no es solo una herramienta de productividad, es una plataforma de extensibilidad. La mayoría de los artículos que leés online se quedan en la capa de usuario final, mostrando cómo Copilot resume reuniones o redacta correos. La capa de developer es donde está el trabajo serio: agentes que conectan datos de línea de negocio, automatizan workflows que antes requerían ingeniería compleja, y exponen capacidades de IA dentro del flujo natural del trabajo.

Para quienes venimos del mundo de Azure AI, esto representa una continuidad lógica. Las certificaciones AI-102 y la próxima AI-103 cubren exactamente este territorio: cómo orquestar IA en escenarios de negocio reales. Y Microsoft 365 Copilot es uno de los lugares más concretos donde esa orquestación se traduce en valor inmediato.

Si querés explorar la documentación oficial de extensibilidad de Microsoft 365 Copilot, este es el punto de entrada con todos los recursos para developers, agentes, MCP, conectores y más:

👉 https://learn.microsoft.com/microsoft-365/copilot/?wt.mc_id=studentamb_510930

GitHub Copilot in 2026 is not what you think it is anymore

Carlos José Castro Galante — Sat, 18 Apr 2026 01:31:28 +0000

If you still think of GitHub Copilot as "the thing that autocompletes your code," you're about two years behind. That's not a criticism - the product has changed faster than most people's mental models of it. This post is an attempt to give you an accurate picture of what Copilot actually is right now, what the research says about its impact, and where the real limits are.

What it does under the hood

Every time Copilot generates a suggestion, it builds a prompt from whatever context it can gather: the code around your cursor, other open tabs, your repo's URL, any custom instruction files you've set up, and - if you've configured them - indexed repository content or attached data from MCP servers. That prompt goes over TLS to GitHub's Copilot proxy, which handles authentication, content filtering, public-code-match checks, and rate limiting. Then it routes to whatever model you've selected.

Inline completions use a Fill-in-the-Middle (FIM) approach, meaning the model sees both the code before and after the cursor rather than just a prefix. GitHub ran A/B tests on this and found it lifted accepted completions by around 10%. In 2024 they also swapped out the original completion backend for a custom-trained model that reduced latency by 35%, delivered 12% higher acceptance rates, and tripled throughput.

The feature surface in 2026

Copilot has expanded from one feature (inline completions) to something that looks more like a platform.

Next Edit Suggestions - available since April 2025 in VS Code, Xcode, and Eclipse - predicts where in the file you're going to edit next, not just what comes after the cursor. It's a subtle difference but it changes how you move through a codebase.

Copilot Edits / multi-file edit mode reached GA in February 2025. It uses a dual-model architecture: one model proposes the changes, a speculative-decoding endpoint applies them fast. You describe what you want at the level of a task, and it touches as many files as needed.

Agent mode is what changed the product's identity. It's available in VS Code, Visual Studio, JetBrains, Eclipse, and Xcode. In agent mode, Copilot picks the files to touch, proposes terminal commands, runs them, reads the output, and iterates. It keeps going until the task is done or it gets stuck. When GitHub announced it with Claude 3.7 Sonnet in April 2025, it posted a 56% pass rate on SWE-bench Verified.

The cloud agent (launched GA in September 2025) is the async version. You assign a GitHub issue to Copilot from the web or CLI, and it runs inside a sandboxed GitHub Actions environment, pushes commits to a draft PR, runs your tests, and requests your review when done. You don't have to be at your desk.

The Copilot CLI reached GA in February 2026. It's a separate install (npm, Homebrew, or WinGet) that brings a Plan mode, a fully autonomous Autopilot mode, parallel specialized sub-agents (Explore, Task, Code Review, Plan), repository memory across sessions, hooks, plugins, and a built-in GitHub MCP server.

Copilot code review reached GA in April 2025 and was rearchitected at GitHub Universe 2025 to combine LLM reasoning with deterministic engines like ESLint and CodeQL. In December 2025 it was extended so that PRs from unlicensed contributors in an org can still be reviewed, billed to the org.

Copilot Spaces (GA September 2025) are curated bundles of files, issues, PRs, and docs that act as grounding context for any Copilot surface.

On customization: you can set a .github/copilot-instructions.md at the repo level, personal or org-level instructions, and since Universe 2025 an AGENTS.md file that defines custom agents with their own tool sets and behavior per project. MCP has become the primary extension mechanism - servers get invoked automatically based on intent rather than requiring explicit calls.

Where it runs

Inline completions are supported in VS Code, Visual Studio, JetBrains IDEs, Eclipse, Xcode, Vim/Neovim, and Azure Data Studio. Chat runs in VS Code, Visual Studio, JetBrains, Eclipse, Xcode, GitHub.com, GitHub Mobile, Windows Terminal, and Raycast. Agent mode is in VS Code, Visual Studio, JetBrains, Eclipse, and Xcode. Vim/Neovim gets completions only - no chat. The CLI is cross-platform but not available on the Free tier.

Plans and pricing, without the marketing

There are five tiers. The Free plan launched in December 2024 with 2,000 completions and 50 premium requests per month. The Student plan is free for verified GitHub Education users and gives unlimited completions with 300 premium requests. Pro is $10/month (or $100/year) with unlimited completions and 300 premium requests - it includes agent mode, the cloud agent, the CLI, and MCP. Pro+ is $39/month with 1,500 premium requests and access to every available model, including preview models as they ship. Business is $19/user/month (300 premium requests per user, admin controls, audit logs, IP indemnity). Enterprise is $39/user/month (1,000 premium requests per user, organization-codebase indexing, a fine-tuned private completion model, and Bing-grounded web search in GitHub.com chat).

Overages on every paid plan cost $0.04 per additional premium request. Base-model usage - inline completions, chat with the included models - doesn't count against the premium budget.

One practical note: Copilot is not available on GitHub Enterprise Server, only on GitHub Enterprise Cloud. That surprises a lot of enterprise architects.

What the productivity data actually says

I want to be careful here because the numbers that circulate online are often decontextualized.

The most cited study is Peng et al. (2022, arXiv:2302.06590). Ninety-five developers on Upwork were randomly split and asked to implement an HTTP server in JavaScript. The Copilot group finished in 1 hour 11 minutes on average; the control group took 2 hours 41 minutes. That's a 55.8% speedup, statistically significant (P=0.0017). Less experienced developers, older developers, and those with higher baseline workloads benefited most. The task was narrow and the sample was controlled, so this number describes one context, not all development work.

The GitHub × Accenture randomized controlled trial is the strongest enterprise evidence. Across roughly 450 Accenture developers, Copilot produced an 8.69% increase in pull requests per developer, a 15% increase in PR merge rate, and an 84% increase in successful builds. About 30% of Copilot suggestions were accepted, and 88% of accepted characters were retained. Accenture has since rolled Copilot out to more than 12,000 developers.

A ZoomInfo field study (arXiv:2501.13282) covering 400+ developers through a four-phase rollout found a 33% full-suggestion acceptance rate, a 20% line-of-code acceptance rate, and 72% developer satisfaction.

The numbers I'd avoid citing without sourcing are the "46% of code written by Copilot" and "15 million users" figures - they come from press announcements rather than controlled studies. The Forrester ROI figures are real but behind a paywall; if you want to cite them, get the original study.

The direction things are going

At GitHub Universe 2025, GitHub announced Agent HQ, a control plane that orchestrates agents from Anthropic, OpenAI, Google, Cognition, and xAI across GitHub, VS Code, CLI, and Mobile under a single Copilot subscription. The framing was explicit: Copilot is positioning itself as the interface for all coding agents, not just the home for GitHub's own.

The economic model is also shifting. Every paid tier includes unlimited use of a base model with a monthly premium-request budget for frontier calls. As frontier models become cheaper, more of them will probably move into the base tier. For now, the budget disciplines how much you use the most powerful models per month.

If there's one sentence that captures where Copilot is in 2026: it's not a product anymore, it's an orchestration layer. Completions, chat, edits, in-IDE agents, the CLI, and the cloud agent are points on a continuum from "suggest what comes next" to "go do this task and tell me when you're done." The underlying model changes constantly. What stays stable is the interface - and increasingly, the agents you define yourself.

If you want to dive deeper into Copilot's learning resources, Microsoft Learn has a full set of modules and learning paths covering everything from setup to agent mode and responsible AI:

👉 https://learn.microsoft.com/copilot?wt.mc_id=studentamb_510930

Carlos José Castro Galante is a Full Stack Developer and Azure AI Engineer certified by Microsoft (AI-102, AI-900, AZ-900) and ITBA. Available for freelance projects from Argentina.

Cómo preparé y aprobé la certificación Azure AI Engineer Associate (AI-102)

Carlos José Castro Galante — Fri, 10 Apr 2026 22:21:55 +0000

Por Carlos José Castro Galante - Full Stack Developer & Azure AI Engineer | Argentina

Obtener la certificación Microsoft Certified: Azure AI Engineer Associate (AI-102) fue uno de los pasos más importantes en mi carrera como desarrollador. En este artículo te cuento exactamente cómo lo hice: desde cómo conseguí el voucher hasta el día del examen, con total honestidad sobre lo que funcionó y lo que me costó más de lo esperado. Y al final te cuento algo que cambia completamente el panorama para quien esté pensando en certificarse hoy.

Un poco de contexto

Antes de rendir el AI-102, ya tenía la AZ-900 (Azure Fundamentals), y eso marcó una diferencia enorme. Mi recomendación siempre va a ser la misma: si vas a certificarte en Azure, empezá por la AZ-900. No es un requisito formal, pero sí es la base conceptual de toda la plataforma. Sin ella, muchos conceptos del AI-102 se vuelven confusos innecesariamente, y terminás aprendiendo dos cosas a la vez en lugar de una.

La AZ-900 me dio el mapa general de Azure: qué es una suscripción, cómo funciona el portal, qué son los recursos y los grupos de recursos, cómo se organiza la plataforma en términos generales. Con esa base, cuando llegué al AI-102 pude enfocarme en profundizar en inteligencia artificial en lugar de estar aprendiendo Azure desde cero al mismo tiempo.

Cómo conseguí el voucher

El voucher para el examen lo obtuve a través del Bootcamp de Azure AI-102 de Código Facilito. Para quienes no lo conocen, Código Facilito es una plataforma latinoamericana de educación tecnológica que organiza bootcamps enfocados en preparación para certificaciones Microsoft. El programa incluye clases en vivo, material de estudio y, al completarlo, el voucher para rendir el examen oficial.

Esto es relevante porque el examen de Microsoft tiene un costo en dólares que puede ser significativo desde Argentina. Poder acceder al voucher a través de un bootcamp es una vía muy concreta para reducir esa barrera de entrada, y es algo que genuinamente agradezco haber encontrado.

Cuánto tiempo estudié y cómo lo organicé

Me dediqué dos meses de preparación antes de rendir. Fui bastante sistemático con el material, aunque no seguí un horario rígido, sino que avancé a mi ritmo tratando de entender bien cada tema antes de pasar al siguiente.

El material de Código Facilito fue la columna vertebral del estudio. Las clases del bootcamp cubren el temario del examen de forma estructurada y orientada a lo que Microsoft realmente evalúa, lo cual ahorra mucho tiempo de no saber por dónde empezar.

Microsoft Learn es indispensable y completamente gratuito. Tiene rutas de aprendizaje específicas para el AI-102 con módulos interactivos, ejercicios en sandbox y preguntas de práctica. Si tuviera que elegir solo un recurso, sería este.

También usé videos en YouTube para reforzar conceptos específicos, especialmente para ver demostraciones prácticas de servicios como Azure OpenAI, Azure Cognitive Search o Language Studio. Ver los servicios en acción muchas veces explica en cinco minutos lo que un documento tarda páginas en describir.

Y acá quiero hacer una aclaración importante: practicar vale más que solo leer. El AI-102 no es un examen que se aprueba memorizando definiciones. Las preguntas son de escenarios reales, y Microsoft tiene un banco de preguntas enormemente amplio y muy aleatorio, lo que significa que nunca sabés exactamente qué combinación de preguntas te va a tocar. La única forma de estar preparado para eso es haber practicado lo suficiente como para entender los conceptos de verdad, no solo haberlos leído. Entrar al portal de Azure, crear recursos, probar los servicios, romper cosas y entender por qué fallaron, eso es lo que realmente te prepara.

El temario del AI-102: qué cubre el examen

El examen abarca un abanico amplio de servicios de IA en Azure. Los grandes bloques son los siguientes.

Soluciones de visión por computadora con Azure Computer Vision, Azure Custom Vision y Face API. Conceptos como análisis de imágenes, detección de objetos, OCR y reconocimiento facial.

Procesamiento de lenguaje natural (NLP) con Azure AI Language, análisis de sentimientos, extracción de entidades, clasificación de texto y traducción con Azure Translator.

Minería de conocimiento con Azure Cognitive Search, indexación de documentos, enriquecimiento con IA y skillsets.

Inteligencia artificial conversacional con Azure Bot Service y QnA Maker, ahora integrado en Language Studio, junto con el diseño de flujos conversacionales.

Azure OpenAI, que incluye modelos de lenguaje grande, integración de GPT en aplicaciones, prompts y embeddings. Este bloque fue incorporado más recientemente al examen y tiene un peso cada vez más importante.

Responsabilidad en IA, porque Microsoft no solo evalúa lo técnico. Hay preguntas conceptuales sobre principios éticos, fairness, transparencia y privacidad en sistemas de IA. Es un bloque que no hay que subestimar.

Los temas que más me costaron

Siendo completamente honesto, hubo dos bloques que me llevaron más tiempo que el resto.

El primero fue Azure Cognitive Search. La arquitectura de indexación, los skillsets de enriquecimiento y cómo se conectan todos los componentes entre sí (datasource, indexer, index, skillset) no es intuitiva la primera vez que la ves. Tuve que releerlo varias veces y hacer ejercicios prácticos en el portal hasta que empezó a tener sentido como sistema.

El segundo fue Azure OpenAI, no por dificultad técnica sino porque el servicio evolucionó muy rápido y parte del material disponible en internet estaba desactualizado al momento de estudiar. Acá confiar en la documentación oficial de Microsoft Learn fue fundamental, porque es lo que Microsoft actualiza primero.

Rendir en inglés o en español

Elegí rendir el examen en inglés y lo recomiendo. Las traducciones al español de los exámenes de Microsoft no siempre son precisas, algunos términos técnicos pierden matiz o se traducen de forma que genera confusión innecesaria. Si tenés un nivel de inglés técnico suficiente para leer documentación, rendilo en inglés. Vale la pena.

Lo aprobé al primer intento

Sí, lo aprobé al primer intento. No lo digo para presumir sino para que quede claro que con dos meses de preparación consistente y los recursos correctos es completamente alcanzable, incluso desde Argentina y sin acceso a laboratorios empresariales de Azure. La clave estuvo en combinar teoría con práctica real desde el principio, no esperar a "terminar de estudiar" para tocar el portal.

Recursos que recomiendo

Código Facilito para el bootcamp y el voucher: codigofacilito.com

Microsoft Learn, ruta AI-102: learn.microsoft.com/es-es/credentials/certifications/azure-ai-engineer

Portal de Azure con una cuenta gratuita para practicar. Muchas preguntas del examen son de escenarios prácticos y nada reemplaza haber usado los servicios de primera mano.

YouTube para ver demostraciones de Language Studio, Vision Studio y Azure OpenAI Studio. Ver los servicios en acción complementa muy bien la lectura de documentación.

Lo que viene: el AI-102 se retira el 30 de junio de 2026

Y acá viene la parte que más importa si estás leyendo esto en 2026: el AI-102 se retira definitivamente el 30 de junio de 2026. A partir de esa fecha no vas a poder rendirlo, repetirlo ni renovarlo. Es una fecha dura, sin excepciones.

Microsoft lo confirmó oficialmente en su página de Microsoft Learn: "This certification, related exam, and renewal assessments will retire on June 30, 2026. You will no longer be able to earn or renew this certification after this date."

Si ya tenés la certificación, no te preocupes: no se revoca ni se invalida. Sigue en tu transcript hasta su fecha de expiración natural. Pero si necesitás renovarla, tenés que hacerlo antes del 30 de junio, después de esa fecha la opción desaparece.

Y si estás pensando en rendirlo recién ahora, siendo honesto: la ventana es muy corta y el mismo Microsoft recomienda prepararse para el nuevo examen en lugar del AI-102. Los materiales de entrenamiento oficiales del AI-102 ya se retiraron en abril de 2026, lo que complica bastante el estudio desde cero.

El reemplazo: AI-103, Azure AI App and Agent Developer

El sucesor del AI-102 se llama AI-103: Azure AI App and Agent Developer Associate, y ya tiene disponible su versión beta desde abril de 2026. La disponibilidad general se espera para junio de 2026, casi en simultáneo con el retiro del AI-102.

Este cambio no es solo un número nuevo. Es un giro de fondo en lo que Microsoft espera de un AI Engineer hoy. Ya no alcanza con conocer los servicios de Azure o tener base en datos: el nuevo estándar exige saber cómo orquestar la inteligencia artificial en escenarios reales y en contextos de negocio. Agentes autónomos, flujos de razonamiento en múltiples pasos, integración de modelos generativos en aplicaciones productivas, orquestación multi-agente, todo eso es lo que el AI-103 evalúa.

La plataforma central del nuevo examen es Microsoft Foundry, y el enfoque es desarrollo de aplicaciones de IA listas para producción, no solo conocimiento de los servicios. Es un salto de saber usar la IA a saber construir con ella a escala.

Este cambio no me sorprende. La industria viene moviéndose exactamente en esa dirección y tiene mucho sentido que Microsoft actualice sus certificaciones para reflejarlo. Quien quiera mantenerse relevante en el ecosistema de Azure AI va a necesitar adaptarse a este nuevo estándar más temprano que tarde.

Para cerrar

El AI-102 fue una certificación que valió cada hora de estudio. Me obligó a conocer en profundidad el ecosistema de IA de Azure, y eso se traduce en proyectos reales. Pero el mundo de la IA se mueve rápido, y Microsoft se está moviendo con él.

Si estás empezando a prepararte hoy, mi consejo es claro: mirá directamente el AI-103. Asegurate de tener la AZ-900 como base, familiarizate con Microsoft Foundry y Azure AI Foundry, y enfocá tu estudio en escenarios agénticos y generativos. Es hacia donde va todo.

Cualquier duda podés escribirme en carlosjcastrog.com o encontrarme en LinkedIn.

Carlos José Castro Galante es Desarrollador Full Stack y Azure AI Engineer certificado por Microsoft (AI-102, AI-900, AZ-900) e ITBA. Disponible para proyectos freelance desde Argentina.

Building a Real Burger E-commerce Taught Me More Than Any Tutorial Ever Did

Carlos José Castro Galante — Fri, 03 Apr 2026 18:52:00 +0000

When I started this project, I thought I knew exactly what I was doing.

A small burger place needed a digital menu, a way to take orders, and eventually accept payments. Nothing too ambitious. I had built interfaces before, worked with APIs, handled state.

It felt like something I could finish quickly.

That assumption didn’t last long.

What looked like a simple menu turned into a constant series of small decisions that actually mattered. Not the kind you solve with a library or a tutorial, but the kind that come from dealing with real users and real constraints.

The first thing that changed my perspective was the data.

At the beginning, I treated products like static items. Name, price, image. Render a card and move on.

But that model breaks almost immediately in a real scenario.

Some burgers had multiple sizes. Others didn’t. Some had temporary discounts. Drinks were fixed. Combos mixed different rules. And then there was stock, which isn’t something you can fake if someone is actually trying to buy.

The UI started getting messy, not because of styling, but because the data didn’t reflect reality.

I had to step back and stop thinking in terms of components. The real problem wasn’t how things looked, but how things were defined.

Once I restructured the data to describe behavior instead of just content, everything became easier to reason about. The UI stopped fighting back.

Then came the cart.

This is where things quietly fall apart if you’re not careful.

Adding a product is easy. But a product with variations, custom notes, and dynamic pricing is not just “an item” anymore.

At one point, too much of that logic lived inside components. It worked, but it was fragile. Every small change had side effects somewhere else.

I moved that logic into a centralized context, not because it was trendy, but because I needed control.

After that, the components became predictable again. They stopped being responsible for decisions and went back to doing what they should do: represent state.

That shift made the whole app feel stable.

The WhatsApp integration was another moment where expectations didn’t match reality.

Technically, sending a message is trivial. It’s just a link.

But what arrives on the other end matters more than how you send it.

If the message is messy, incomplete, or hard to read, the business suffers. Orders get misunderstood. Time is lost. Mistakes happen.

So instead of thinking about the integration itself, I focused on the output.

I built a formatter that turns the cart into something structured and readable. Clear product names, quantities, totals, user info, delivery details.

Now the message actually works for the person receiving it.

That changed more than I expected.

At some point I started looking into payments, specifically Mercado Pago.

That’s when I realized something I had been ignoring.

Payments don’t fix a bad flow.

If the process is confusing, adding a payment button just makes things worse. People don’t complete what they don’t understand.

So I paused that part and focused on making the ordering experience feel natural first. Clear steps, no surprises, no friction that didn’t need to exist.

Only after that does it make sense to introduce payments.

What this project really did was change how I approach building things.

I stopped thinking in terms of “features” and started thinking in terms of behavior.

I stopped assuming that a clean UI means a simple system.

And more importantly, I stopped relying on ideal scenarios.

Real users don’t follow perfect paths. They make unexpected choices, skip steps, change their minds. If your system can’t handle that, it doesn’t matter how good your code looks.

I didn’t build something revolutionary.

But I built something that works in a real environment, with real constraints, and that forced me to make better decisions than any tutorial ever did.

And that, at least for me, was the part that actually mattered.

About me

I’m Carlos José Castro Galante, a software developer focused on building real-world applications that combine frontend, automation, and practical AI.

Python Data Analysis Project: Building a Learning Radar for Educational Insights

Carlos José Castro Galante — Tue, 31 Mar 2026 20:50:17 +0000

If you are learning Python and data science, one of the best ways to grow is by building real world projects. In this article I will show how I built a complete data analysis project using Python to extract insights from online education data.

This is not a typical beginner project. The goal was to create something useful, scalable, and portfolio ready.

The result is Learning Radar, a data driven system designed to analyze course reviews and help understand what really makes an online course valuable.

Why build a data analysis project like this
Most Python data science tutorials focus on small datasets and simple examples. In real scenarios, data is messy, large, and comes from different sources.

This project focuses on:

Working with large datasets
Cleaning and transforming real data
Performing exploratory data analysis
Creating meaningful data visualizations
Generating insights that solve real problems

It is designed to reflect real data science workflows.

Project goal
The main objective was to analyze thousands of course reviews and answer key questions such as:

What factors influence course ratings
How difficulty impacts student satisfaction
Which categories perform better
What patterns exist in user feedback

Instead of just analyzing data, I focused on building an educational intelligence tool.

Dataset and data sources
To meet the requirement of working with more than 50000 rows, I combined multiple public datasets related to online courses.

The final dataset includes:

Course title
Category
Rating
Review text
Difficulty level
Engagement indicators

Combining datasets allowed me to create a richer and more useful analysis.

Data cleaning and preprocessing in Python

Data cleaning is one of the most important steps in any data science project.

I used Python and Pandas to:

Remove missing values
Normalize column names
Convert data types
Clean text data from reviews
Remove duplicates

I also created new features to improve analysis:

Review length
Rating groups
Difficulty mapping

This step ensures accuracy and consistency in the results.

Exploratory Data Analysis with Pandas

Exploratory Data Analysis is where the real insights begin.

Using Pandas, I explored:

Distribution of ratings
Average rating by category
Relationship between difficulty and rating
Patterns in review behavior

This step helps understand the structure of the data and identify trends.

Key insights from the analysis
Some interesting findings from this project:

Courses with medium difficulty often receive better ratings
Very long reviews usually reflect strong opinions
Some categories consistently perform better
High engagement does not always correlate with high ratings

These insights can help students choose better courses and help educators improve content.

Project structure and best practices

To make the project scalable and professional, I organized it as follows:

notebooks for analysis
data folder for datasets
src for reusable code
assets for visualizations
README for documentation

This structure follows good software engineering practices and improves maintainability.

Technologies used

Python
Pandas
NumPy
Matplotlib
Seaborn
Jupyter Notebook

These tools are widely used in data science and provide a strong foundation for analysis.

Challenges faced
Working with large datasets introduced several challenges:

Memory optimization
Data consistency across sources
Cleaning unstructured text data

These were solved by optimizing data types, validating merges, and applying systematic preprocessing.

Future improvements

This project can be extended in many ways:

Sentiment analysis using Natural Language Processing
Machine learning models to predict course success
Interactive dashboards using Streamlit
Automated data pipelines

The long term goal is to transform this into a full educational analytics platform.