Del Problemaa la contribución:Agentes de IA gestionados en Apache Airflow
Apache Airflow
Amazon BedrockAgentCore
LLEVATE LA PRESENTACIÓN
Escaneá para verla en tu celular.
Alejandro “Morgan” Morgante
Apache Airflow Contributor
ITINERARIO
El camino
Punto de partida: nuestra arquitectura y los criterios que guían nuestras decisiones.
01
Necesidad
El problema real en nuestra operación
02
Diseño
La arquitectura MWAA + AgentCore
03
Implementación
La integración y la contribución
04
Resultado
Comparativa de enfoques Los trade-offs elegidos
CRITERIOS DE DECISIÓN
El impacto en el negocio como norte
Para integrar Airflow con AgentCore, estos son nuestros criterios.
Build or buy
Desarrollar capacidades centrales o que generan ventajas competitivas
Delegar todo aquello que no nos diferencia
Paráfrasis de Martin Kleppmann y Chris Riccomini Designing Data-Intensive Applications, 2.ª edición
Open source friendly
Airflow
dbt Core
Strands Agents
Iceberg
Ministack
Diseñar para la resiliencia
“Everything fails, all the time.”
Werner Vogels — CTO de Amazon
“There are no solutions, there are only trade-offs.”
CONTEXTO
Nuestra arquitectura de datos
01 / PROPUESTA
Si una tarea falla, invocamos al agente
PIPELINE EN AIRFLOW Amazon MWAA
COMPLETADA
Obtener datos
FALLÓ
Procesar datos
NO EJECUTADA
Publicar resultados
Invocación ante la falla
INVESTIGACIÓN
Agente en AgentCore
Recibe el incidente y consulta sus herramientas.
AWS Knowledge MCP
Consultar documentación
GitHub
Leer código y crear una draft PR
Slack
Enviar el diagnóstico
La investigación se activa. El pipeline sigue fallado.
01 / NECESIDAD
La alerta inicia la investigación
Un equipo chico interrumpe su trabajo para reconstruir qué pasó.
Abrir logs. Buscar el código. Reconstruir el contexto.
01 / PROPUESTA EN LA PRÁCTICA
Evidencia y una propuesta para revisar
El agente investiga el incidente y reúne el diagnóstico en Slack.
Incidentes distintos, comparados por el contenido de la notificación. Propuesta de corrección ≠ recuperación.
01 / IMPACTO
Menos búsqueda, más foco en el negocio
La notificación trae contexto, una causa probable y una propuesta de corrección.
Menos context switching
Logs, código y diagnóstico juntos. Menos saltos entre herramientas.
Una respuesta mejor preparada
El equipo recibe evidencia y una propuesta para revisar y decidir.
Más foco en el negocio
Reducir la búsqueda repetitiva para dedicar más tiempo a crear valor.
BASE PARA EVOLUCIONAR
POC ACTUALInvestigar y proponer
→
SIGUIENTE PASOResponder con aprobación
→
HORIZONTESelf-healing acotado
Acciones permitidas, validación del resultado y escalamiento cuando no se resuelve.
02 / DISEÑO
Cómo funciona un agente gestionado
Amazon BedrockAgentCore
Google CloudAgent Runtime
Azure AI FoundryHosted Agents
MODELO DE DESPLIEGUEDesplegamos el contenedor del agente
FrameworksHerramientasModelos
NUESTRO AGENTEElegimos cómo construirlo
CONTENEDORCódigo empaquetado
EscaladoDisponibilidadSeguridad
RUNTIME GESTIONADOEl proveedor lo opera
Desarrollamos el agente.El proveedor opera el runtime.
02 / DISEÑO · NUESTRA HISTORIA
El primer agente ya resolvía trabajo real
Empezamos localmente, con instrucciones que conocíamos bien.
INSTRUCCIONES
SKILL.mdAGENTS.md
EJECUCIÓN LOCAL
El agente actuaba
Con ese contexto resolvía tareas operativas de nuestro día a día.
La lógica funcionaba. El próximo desafío era convertirla en un servicio.
02 / DISEÑO · NUESTRA HISTORIA
En el pod apareció otro problema
Llevamos el agente a un pod que hacía llamadas a Bedrock.
NUESTRO AGENTE
Código del agente
La lógica que ya funcionaba.
EJECUCIÓN
Pod en Kubernetes
Ahora teníamos que operar su ejecución.
AMAZON BEDROCK
Llamadas al LLM
Seguían funcionando.
01
Observabilidad
Entender qué hizo el agente y dónde falló.
02
Sesiones aisladas
Separar el contexto de cada ejecución.
03
Memoria del pod
Gestionar episodios de OOMKilled.
Cada problema nos alejaba de mejorar el comportamiento del agente.
02 / DISEÑO · NUESTRA HISTORIA
Entonces cambiamos la pregunta
¿DÓNDE PONEMOS EL ESFUERZO?
Queríamos seguir construyendo el comportamiento y las capacidades del agente, sin operar solos toda la infraestructura que lo rodea.
AgentCore ofrece capacidades gestionadas que se pueden combinar.
Decidimos invertir ese tiempo en el comportamiento del agente y delegar la operación del runtime.
02 / DISEÑO · AGENTCORE
AgentCore es más que Runtime
Capacidades gestionadas que podemos sumar según lo que necesite cada agente.
EJECUTARRuntimeEN LA POC
Alojamiento, escalado y sesiones aisladas.
ACCEDERIdentity
Identidad y credenciales del agente.
CONECTARGateway
APIs, Lambda y herramientas MCP.
RECORDARMemory
Contexto entre interacciones.
NAVEGARBrowser
Interacción web gestionada.
EJECUTAR CÓDIGOCode Interpreter
Código en un entorno aislado.
ENTENDERObservability
Métricas, logs y trazas.
MEDIR CALIDADEvaluations
Evaluaciones configurables del agente.
En nuestra POC usamos Runtime. Las demás piezas se adoptan y configuran cuando aportan valor.
02 / DISEÑO · AGENTCORE
Cómo desplegamos nuestros agentes
01 / DESARROLLO
Agente Strands
Investigación del incidente y herramientas.
02 / PAQUETE
Imagen en ECR
El código y sus dependencias en un contenedor.
03 / EJECUCIÓN
AgentCore Runtime
Un servicio invocable por clientes autorizados.
EN ESTA POC
Desplegamos un contenedor. AgentCore también admite despliegue directo de código empaquetado como ZIP; la elección depende de las dependencias y del proceso de entrega.
02 / DISEÑO · AGENTCORE
Airflow coordina; AgentCore ejecuta
AMAZON MWAA / AIRFLOW
Orquesta la respuesta
El DAG detecta el fallo, prepara el incidente e invoca al agente.
AGENTCORE RUNTIME
Ejecuta al agente
Investiga con sus herramientas y devuelve un resultado. El DAG conserva el estado fallado.
El agente puede evolucionar y servir a otros consumidores fuera del DAG.
02 / DISEÑO
La arquitectura de nuestra POC
ARQUITECTURA DE LA POCInvestigación y propuesta con revisión humana
ORQUESTACIÓN
INVESTIGACIÓN
COLABORACIÓN
Amazon MWAA
Apache Airflow
El DAG envía el incidente
Incidente
El agente
Strands en AgentCore
Investiga y propone
Acciones
GitHub
Draft pull request
Slack
Diagnóstico para el equipo
CONTEXTO Y MODELO DEL AGENTE
CloudWatchLogs de la tarea
Amazon S3Código desplegado
BedrockClaude Sonnet 4.6
BASE DE INFRAESTRUCTURA
VPC + NAT
IAM + cifrado
ECR
El agente propone. Una persona revisa y aprueba.
accepted confirma recepción. La investigación continúa en segundo plano. El DAG sigue fallado.
03 / IMPLEMENTACIÓN
La integración con Airflow
El runtime existía. Faltaba integrarlo de forma nativa en nuestros DAGs.
PUNTO DE PARTIDA
Código propio
Integración mantenida por el equipo
Airflow
SDK / API
AgentCoreRuntime
CONTRIBUCIÓN
Integración nativa
Hooks y operadores del provider Amazon
Airflow
Operador nativo
AgentCoreRuntime
¿Qué tuvimos que agregar a Apache Airflow?
03 / IMPLEMENTACIÓN
El agente como una tarea del DAG
Invocación de un runtime existente, con un operador del provider Amazon.
FRAGMENTO DENTRO DE UN DAG
from airflow.providers.amazon.aws.operators.bedrock import (
BedrockInvokeAgentRuntimeOperator,
)
invocar = BedrockInvokeAgentRuntimeOperator(
task_id="invocar_agente",
aws_conn_id="aws_default",
agent_runtime_arn="{{ var.value.agent_runtime_arn }}",
payload={"prompt": "Analizá la ejecución del pipeline."},
botocore_config={"read_timeout": 300},
)
DE VUELTA EN AIRFLOW
El resultado continúa en el DAG
invocar.output
Respuesta accesible para tareas posteriores mediante XCom.
Provider compatible, conexión AWS y permisos IAM. Los reintentos requieren revisar la idempotencia.
03 / IMPLEMENTACIÓN
La integración vive en el provider
AgentCore se incorpora a las piezas que Airflow ya sabe orquestar.
PROVIDER AMAZON
WORKFLOW
DAG
Dependencias entre tareas
TAREA
Operador
Ejecuta la operación y devuelve el resultado
CONEXIÓN
Hook
Cliente AWS y autenticación
SDK
Boto3
API de control o de invocación
SERVICIO
AgentCore
Runtime del agente
PAQUETEapache-airflow-providers-amazon
ESPERAS DIFERIBLES
Triggers y waiters para crear y eliminar el runtime.
Airflow conserva las dependencias, los reintentos configurados y el estado de la tarea.
03 / IMPLEMENTACIÓN
Una contribución en Apache Airflow
El proyecto se construye mediante discusión abierta y revisión entre pares.
01
Contributors
Proponen cambios. Aportan código, pruebas, documentación y revisión.
02
Committers
Revisan los aportes. Pueden integrar los cambios en el repositorio.
03
PMC
Comité del proyecto. Cuida el rumbo y la comunidad. Vota las releases oficiales.
APACHE SOFTWARE FOUNDATION
El marco institucional del proyecto. La comunidad de Airflow toma sus decisiones técnicas.
Podés empezar a contribuir antes de ser committer.
03 / IMPLEMENTACIÓN
El recorrido de una PR
Un cambio acotado, evidencia de que funciona y revisión de la comunidad.
01
Alcance
Explicar el problema y la propuesta.
02
Desarrollo
Código, pruebas y documentación.
03
PR y checks
Draft, validaciones y lista para revisión.
04
Revisión
Comentarios, cambios y pruebas.
05
Merge
Un committer integra el aporte.
06
Release
Validación, voto y publicación.
La revisión puede volver al código y a las pruebas tantas veces como haga falta.
MergeEl cambio entra al repositorio.
Release del providerEl cambio llega a una versión instalable.
04 / RESULTADO
El agente como servicio, Airflow como orquestador
Con AgentOperator ya podíamos ejecutar agentes dentro de una tarea de Airflow.
Con Airflow + AgentCore Runtime
Consumimos un agente con su propio ciclo de desarrollo y operación.
Responsabilidades separadas
Mantenemos SOA: Airflow orquesta y consume el servicio agéntico, como otros servicios.
Autonomía de AI Engineering
El equipo desarrolla y despliega su agente. Lo consumimos sin recrearlo en Airflow.
Calidad junto al agente
Evals de regresión, MCPs y tools comparten responsable y ciclo de desarrollo.
Una integración más
Operador, hook, conexión y permisos: el patrón que Airflow ya utiliza.
El agente evoluciona como servicio. Airflow sigue enfocado en orquestar.
04 / RESULTADO
¿Qué agregamos?
13 operadores nativos para AWS, Google Cloud y AzureIncluye versiones diferibles
Airflow
dbt Core
Strands Agents
Iceberg
Ministack
VPC + NAT
IAM + cifrado
