Crear agentes de IA sobre la base de sus servicios y API existentes de .NET
Los equipos de C# pueden exponer servicios .NET existentes como herramientas gestionadas para agentes de IA a través de llamadas a funciones, con las reglas de contexto, seguridad y observabilidad necesarias.
Fuentes: AI Agents Are Changing C# Development: 10 Things Every .NET Developer Should Know
La mayoría de los equipos .NET ya cuentan con las partes más complejas de un agente de IA: servicios tipados, API HTTP, autenticación, bases de datos y tareas en segundo plano. Lo nuevo es un modelo de lenguaje que puede decidir cuáles de estas capacidades invocar y en qué orden, para alcanzar un objetivo descrito por el usuario en lenguaje sencillo. Esta guía explica las ideas que necesita un desarrollador en C# para integrar un agente en una aplicación existente sin perder el control sobre lo que realmente hace la aplicación.
De responder preguntas a completar tareas
Un chatbot clásico funciona mediante un único intercambio: el usuario hace una pregunta y el modelo responde con texto. Un agente, en cambio, trabaja hacia un objetivo específico. Analiza qué se requiere para alcanzar ese objetivo, utiliza herramientas para obtener información o realizar acciones, examina los resultados y solo entonces devuelve un resultado final.
Considere a un usuario que quiere saber cuántos pedidos han llegado hoy. Un chatbot solo puede adivinar o explicar cómo podría averiguarlo. Un agente con las herramientas adecuadas puede acceder a los datos de los pedidos, realizar la consulta correspondiente al día actual, interpretar las cifras, redactar un breve resumen y entregarlo como informe. La distinción práctica es sencilla: los chatbots generan respuestas, mientras que los agentes realizan el trabajo.
Las herramientas convierten un modelo en algo útil
Por sí solo, un modelo de lenguaje no tiene idea de cómo funciona su aplicación. No puede leer la tabla de clientes ni realizar pedidos. Las herramientas son el puente: operaciones específicas que el modelo puede solicitar. Un conjunto típico para un backend comercial podría ser este:
GetCustomer()
CreateOrder()
SearchProducts()
GetWeather()
SendEmail()
QueryDatabase()
El modelo decide cuándo se necesita uno de estos elementos; tu código determina cómo se ejecuta. En C#, una herramienta no tiene por qué ser algo exótico. Puede tratarse de un método asíncrono ordinario en un servicio que ya posees, como aquel que carga a un cliente por su ID mediante un servicio inyectado:
public async Task<Customer> GetCustomer(int id)
{
return await customerService.GetByIdAsync(id);
}
Una vez que ese método está registrado como herramienta, el agente puede utilizar esa capacidad, mientras que su implementación permanece dentro de tu capa de servicio habitual, cubierta por la misma inyección de dependencias, pruebas y registro que el resto del código. Aquí es donde se encuentran el desarrollo de aplicaciones cotidianas y el desarrollo de inteligencia artificial.
Cómo funciona en la práctica la llamada a funciones
La llamada a funciones es el mecanismo detrás de las herramientas. El modelo no ejecuta nada por sí mismo; emite una solicitud estructurada para llamar a una función con argumentos específicos, y tu aplicación realiza esa llamada.
Supongamos que un usuario solicita el estado del pedido 12345. Internamente, el modelo concluye que carece de información:
I need order information.
Por lo tanto, pide a la aplicación anfitriona que invoque una función con el número del pedido como argumento:
GetOrderStatus(12345)
Su código ejecuta esa solicitud, devuelve el resultado al modelo, y este convierte los datos brutos en una respuesta legible. Para un desarrollador de C#, esto debería resultar familiar: está exponiendo una pequeña parte de su aplicación, similar a una API pública cuyo llamante es el modelo. Nombres claros, tipos de parámetros precisos y buenas descripciones aumentan significativamente las posibilidades de realizar llamadas correctas.
Reutilizar las APIs que ya tiene
La adopción de agentes no requiere reescribir el backend. Si su aplicación ya expone puntos de conexión, estos pueden convertirse en las herramientas del agente. Un servicio podría ya publicar una función para buscar clientes:
GET /api/customers/{id}
Junto con los puntos de extremo para leer un pedido, crear pedidos y listar productos (la lista a continuación ejecuta las tres rutas juntas en una sola línea; considérelas como puntos de extremo separados):
GET /api/orders/{id}POST /api/ordersGET /api/products
Con esto en su lugar, una solicitud como encontrar al cliente que realizó la mayor cantidad de pedidos este mes se convierte en una secuencia que el agente puede planificar por sí mismo: obtener datos del cliente, recuperar información de los pedidos, comparar las cifras e informar al ganador. El agente es simplemente otro cliente que utiliza las capacidades que ya han sido desarrolladas y protegidas.
Contexto: darle al modelo lo que necesita, no todo lo que se tiene
Imagínese una sesión de trabajo de media hora con un agente que abarque su aplicación, su esquema de base de datos, las convenciones de codificación del equipo, las reglas empresariales, los errores sin resolver y las decisiones tomadas anteriormente en la conversación. Para seguir siendo útil, el agente debe hacer un seguimiento de las partes relevantes de todo ello. Por esta razón, el historial de conversaciones, la gestión del contexto, la memoria, la recuperación de información, los embeddings y las bases de datos vectoriales aparecen constantemente en el diseño de los agentes.
Hay un detalle que es fácil pasar por alto: más contexto no significa automáticamente mejor calidad. Cada token adicional cuesta dinero y genera mayor latencia, y el material irrelevante diluye la información esencial, lo que hace que las respuestas sean menos fiables. Un buen diseño de agentes consiste en proporcionar el contexto adecuado justo cuando se necesita, por ejemplo, recuperando solo los documentos que coinciden con el paso actual en lugar de incluir toda la base de conocimientos en cada solicitud. Para conocer más sobre las diferencias entre estos mecanismos de memoria, consulte nuestro artículo explicativo sobre la memoria de IA, los embeddings y RAG.
Permitir que los agentes consulten datos de forma segura
El acceso a los datos es donde los agentes resultan especialmente atractivos para las empresas que utilizan .NET. Un usuario empresarial podría preguntar qué productos presentaron la mayor caída en ventas el mes pasado. En lugar de crear un informe dedicado para cada pregunta de este tipo, un sistema respaldado por agentes puede interpretar la pregunta, determinar qué datos son relevantes, consultarlos, analizar los resultados y explicar lo que ha encontrado.
La advertencia asociada a esto es innegociable: nunca otorgue a un modelo acceso ilimitado a su base de datos. Permitirle generar y ejecutar consultas SQL arbitrarias puede dar lugar a instrucciones destructivas, fugas de datos entre usuarios y consultas que bloquean tablas. En su lugar, exponga operaciones específicas y diseñadas para un fin con parámetros validados y sus propias verificaciones de permisos:
GetSalesReport()
GetProductSales()
GetCustomerOrders()
Cada una de ellas puede aplicar seguridad a nivel de fila, limitar el tamaño de los resultados y utilizar una conexión de solo lectura, sacrificando un poco de flexibilidad a cambio de mucha previsibilidad.
Los agentes no reemplazan a la arquitectura
Un error común es pensar que agregar un modelo permite relajar los principios fundamentales. Lo cierto es lo contrario. La inyección de dependencias, el diseño SOLID, el registro de eventos, las pruebas, la autenticación, la autorización, el manejo de errores, la observabilidad y una estructura limpia son aún más importantes cuando un componente no determinista decide qué llamar.
El modelo mental útil es uno de separación de roles: el agente puede proponer una acción, pero tu aplicación decide si dicha acción está permitida. En resumen, la IA toma las decisiones, mientras que tu aplicación establece las reglas. Las verificaciones de autorización deben estar en las implementaciones de las herramientas y en los servicios que las respaldan, nunca en el prompt, ya que este es una sugerencia al modelo y no una regla obligatoria.
Los riesgos de seguridad se multiplican con cada herramienta
Cada herramienta que se le otorga aumenta las posibilidades de que ocurran errores. Un agente podría ser capaz de realizar acciones como estas:
Read customer data
Send emails
Create orders
Delete records
Call external APIs
A continuación se plantean tres preguntas. ¿Qué sucede cuando el modelo comete un error, como eliminar el registro incorrecto? ¿Qué ocurre cuando un usuario malintencionado intenta convencer al agente de que utilice una herramienta de forma incorrecta? ¿Y qué pasa cuando el contenido externo que lee el agente, como un correo electrónico o una página web, contiene instrucciones ocultas? Este último escenario, generalmente denominado inyección indirecta de prompts, es una clase de ataque real y bien documentada, no un ejercicio teórico.
Las defensas son en su mayoría aquellas que ya conoce, aplicadas de manera deliberada:
- Autenticación y autorización en cada llamada a una herramienta, limitadas al usuario final y no al agente.
- Validación de entradas en todos los argumentos que proporciona el modelo.
Para cualquier acción de alto impacto, como reembolsos, eliminaciones o mensajes enviados a clientes, un paso de confirmación en el que una persona apruebe la acción suele ser el seguro más económico disponible.
Observabilidad para flujos de solicitud no lineales
El manejo convencional de solicitudes es fácil de rastrear porque sigue una línea recta:
Request → Service → Database → Response
Una ejecución de agente puede ir y venir entre el modelo, varias herramientas y múltiples servidores backend antes de decidir una respuesta:
User
↓
AI Model
↓
Tool
↓
API
↓
Database
↓
AI Model
↓
Another Tool
↓
Final Response
Esa estructura es mucho más difícil de depurar. Cuando algo sale mal, es necesario determinar qué herramientas se utilizaron, por qué el modelo las eligió, cuánto tiempo duró cada llamada, qué falló, cuántas invocaciones del modelo se necesitaron en la ejecución y cuál fue el costo total de la operación. Trate cada ejecución como un seguimiento con segmentos correspondientes a las llamadas al modelo y a las herramientas, registrando los argumentos y el número de tokens junto con los tiempos; de lo contrario, resulta casi imposible reproducir una respuesta incorrecta.
Por qué los desarrolladores de C# tienen ventaja
Los desarrolladores familiarizados con C# y .NET no parten de cero. Las interfaces y clases, las API HTTP, los contenedores DI, el código asíncrono, las bases de datos, la autenticación, los servicios en segundo plano alojados y el despliegue en la nube son exactamente los componentes con los que se construyen los sistemas de agentes. Lo que queda es una breve lista de nuevos conceptos, que se construyen unos sobre otros más o menos en este orden:
LLMs
↓
Prompting
↓
Function Calling
↓
Tools
↓
RAG
↓
Agents
↓
Multi-Agent Systems
No es necesario absorberlo todo de una vez; comience con algo sencillo.
Una arquitectura de referencia
Un diseño mínimo coloca al agente en el centro, con un puñado de herramientas que se conectan a sus propios servicios, la base de datos y una API de búsqueda externa, y los resultados fluyen de vuelta a través del agente hacia el usuario:
User
↓
AI Agent
↓
┌───────┼────────┐
↓ ↓ ↓
API Tool DB Tool Search Tool
↓ ↓ ↓
.NET Database External API
└───────┼────────┘
↓
Agent Result
↓
User
La característica clave de este diseño es que el agente nunca interactúa directamente con sus sistemas. Cada ruta pasa por una herramienta que pertenece a su aplicación .NET, por lo que el control de acceso, la validación y el registro de actividades se gestionan en un único lugar del que ya sabe cómo cuidar.
Un camino de aprendizaje práctico
Para un desarrollador en C# que quiere incursionar en el área de la IA, una progresión sensata sería la siguiente:
- Comprender los LLM. Aprenda cómo se comportan los modelos de lenguaje grandes, en qué son buenos y dónde fallan, como por ejemplo con respuestas seguras pero incorrectas.
Un agente de soporte al cliente es un buen primer proyecto real porque ejercita todos los aspectos relacionados. Puede buscar al cliente, inspeccionar el pedido, verificar el estado de la entrega, abrir un ticket y responder:
Search customer
↓
Check order
↓
Check delivery status
↓
Create support ticket
↓
Respond to customer
Cada paso se corresponde con una herramienta específica, y los pasos que generan efectos secundarios son candidatos obvios para reglas de aprobación.
Puntos clave
- Un agente es un sistema de software: un modelo combinado con herramientas, datos, lógica de aplicación, seguridad y monitoreo, y no un sustituto de ninguno de ellos.
- Exponga las capacidades como herramientas específicas y validadas; nunca otorgue acceso directo a la base de datos ni a una API sin restricciones.
- Mantenga la autorización en el código, de modo que la aplicación controle lo que propone el agente.
- Elabore un contexto específico para cada paso en lugar de maximizarlo.
- Rastree cada ejecución de principio a fin para que los fallos y costos sean explicables.
Lecturas relacionadas
- Comprender los agentes de IA a través de la analogía cerebro y dedo — Aprenda cómo los LLM, las herramientas y sus ejecutores interactúan al relacionar la arquitectura de los agentes con una analogía de pedidos de comida, y luego cree una implementación mínima de un agente.
- De objetivo a acción protegida: bucles, verificación y permisos en agentes de IA — Aprenda cómo los agentes de IA convierten un objetivo en llamadas a herramientas mediante un bucle de planificar, actuar y observar, y por qué la verificación, los niveles de autonomía y las capas de permisos determinan si son seguros.