Los roles que forma este libro
El mercado inventa títulos más rápido de lo que puede definirlos. La mayoría de esos títulos son la misma disciplina a distintas profundidades: la disciplina que enseña este libro. Aquí está el mapa, y hasta dónde te lleva exactamente el libro hacia cada rol.
Aquí definimos los roles de la nueva era de la IA agéntica: los trabajos que existen porque las empresas ahora fabrican, operan y gobiernan AI Workers. Las entradas están ordenadas según cómo se agrupa el trabajo en la práctica, y el veredicto junto a cada una marca el alcance con honestidad: hasta dónde te lleva este libro hacia ese rol, y dónde toman el relevo las vías de certificación. Los veredictos importan más que los nombres. Donde el libro se detiene, lo dice.
Todos empiezan en los mismos Fundamentos, las habilidades de navegador que todo lector necesita antes de cualquier trabajo con agentes. Sobre ese piso están los dos modos de uso de agentes generales. El Modo 1 consiste en usar un agente general para hacer tu propio trabajo más rápido: una competencia que todo lector necesita, no un título de puesto. El Modo 2 consiste en fabricar AI Workers que hacen el trabajo por ti, y ahí es donde viven los títulos de puesto. El mapa empieza con el piso de Fundamentos y el Profesional de Modo 1, y luego pasa a los roles de Modo 2, que son casi todo.
¿Eres nuevo en el vocabulario (Digital FTE, SKILL.md, Agent Factory)? Empieza por la Tesis y el Glosario; esta página los da por sabidos.
Todo el mapa de un vistazo: el pipeline central, lo que lo extiende y lo apoya, dónde se detiene el libro y la base que sostiene todo.
La base de la que todos parten
Fundamentos: el piso, antes de cualquier modo. Todo lector empieza del mismo modo, en una pestaña del navegador, en los Fundamentos: cómo hacer prompting, los dos lenguajes documentales del trabajo agéntico, cómo encargar código que nunca escribes, skills y conectores, y cómo pensar en la era de la IA. Sin modo, sin rol, sin nada que instalar. Este es el piso sobre el que se sostiene todo el mapa. Donde todos empiezan, no un título que ostentas.
Profesional de Modo 1: no es un título, es una competencia. Sobre ese piso, usas un agente general para hacer tu propio trabajo más rápido: razonar, escribir, programar, analizar, planificar, entregar un resultado y cerrar la sesión. Esto es el Modo 1, y el libro lo forma para todos: ingenieros mediante Claude Code u OpenCode, expertos de dominio mediante Claude Cowork u OpenWork, bajo los Siete Principios de resolución de problemas con agentes generales. Es el primer modo que todo lector recorre antes de los roles de Modo 2 de abajo, y te hace más agudo en el trabajo que ya tienes en lugar de entregarte uno nuevo. El primer modo que todos ejecutan, no un título que ostentas.
El núcleo generalista
Estos roles centrales funcionan como un solo pipeline, desde la intención hasta producción: Outcome Architect (qué) → Digital FTE Builder (construir) → AI-Native Company Architect (sistema) → Cloud AI Engineer (operar). Ejecútalo dentro de tu propia empresa y son estos cuatro roles; ejecútalo dentro de la de un cliente, llevado de principio a fin por un único ingeniero embebido y neutral respecto del proveedor, y es el Forward Deployed Engineer. Todo lo demás en el mapa apoya, extiende o acota esta línea.
Cuatro roles ejecutan la línea dentro de tu propia empresa; un ingeniero embebido lleva la misma línea dentro de la de un cliente.
Outcome Architect: es dueño de la intención, no de la ejecución. El trabajo en la era de los agentes se divide en tres: intención, ejecución, verificación. El Worker es dueño de la ejecución; este rol es dueño de la intención. Decide qué debe lograr un Worker, redacta la especificación que lo fija, define qué significa "correcto" y prioriza qué Workers se construyen siquiera: la persona que responde el qué y el porqué antes de que el Builder responda el cómo. Donde la vía de Strategist es dueña del descubrimiento de cara al cliente y del retorno de inversión, el Outcome Architect es dueño de la hoja de ruta interna de Workers y de las especificaciones que la respaldan. El libro lo forma directamente: el desarrollo guiado por especificaciones es, en esencia, la disciplina de escribir una intención a la que un Worker pueda atenerse. Lo forma: la disciplina sobre la que descansa todo el método.
Digital FTE Builder: el producto unitario, construido de principio a fin. El mercado llama a esto AI Engineer, su término comodín para alguien que crea aplicaciones a partir de componentes de IA y dirige agentes de programación con IA. El nombre de este libro es más preciso, porque lo que construyes es más preciso: el Digital FTE, la unidad con la que se ensambla toda la empresa. Este es el graduado principal del libro. Forma toda la columna: desarrollo guiado por especificaciones, redacción de SKILL.md, arquitectura de agentes, interfaces de herramientas y MCP, evaluación y supervisión humana, con despliegue suficiente para enviar a producción, y la profundidad reservada para el Cloud AI Engineer. Lo forma, de principio a fin.
AI-Native Company Architect: diseña la empresa, no el Worker individual. Toda la empresa: el modelo de dos capas, la capa de gestión, la fuerza laboral, el sistema nervioso que transporta eventos entre ellas y el sistema de registro contra el que todo se ejecuta. Agent Factory es el proceso que practica este arquitecto; AI-Native Company es el producto que entrega. El libro es su fuente canónica. El programa de cinco trimestres Certified Agentic AI Architect es su credencial. Formado por completo; certificado por la vía de Architect.
Cloud AI Engineer: quien opera el AI Worker y la AI-Native Company en producción. Construir un Digital FTE es una mitad del trabajo; operarlo de forma fiable es la otra, y también lo es operar toda la AI-Native Company a la que pertenece. Donde el AI-Native Company Architect diseña la empresa, este rol la opera: despliega y escala los Workers, la capa de gestión y el sistema nervioso sobre infraestructura de nube real: Azure Container Apps para enviar a producción, Inngest para ejecución duradera, y Dapr y Kubernetes para escalar. Es donde el sistema deja de ser un prototipo y se convierte en una empresa de la que una organización puede depender. Lo forma, de principio a fin.
Los dos roles que casi nadie más forma
Subject Matter Expert como Skill Author: el rol que el mercado todavía no ha nombrado. El contador, abogado o experto en cadena de suministro que codifica su criterio en SKILL.md y se convierte en el motor de conocimiento de un Digital FTE. La mayoría de las listas del mercado pasan por alto este rol porque todavía imaginan el trabajo de IA como algo exclusivo de ingeniería. Este libro trata el propio criterio de dominio como algo que se puede redactar, probar y desplegar. Es uno de los dos roles que casi nadie más forma. Lo forma por completo: entra criterio, sale un agente en funcionamiento.
Forward Deployed Engineer (FDE): la versión neutral respecto del proveedor que el mercado no encuentra
Qué hace realmente un FDE. La mayoría de los ingenieros de software crean un producto en la sede central y nunca conocen al cliente que lo usa. Un FDE hace lo contrario. Va al lugar de trabajo real del cliente, se sienta junto a las personas que hacen el trabajo, entiende los problemas reales que enfrentan y crea soluciones ahí mismo, en sitio, usando la plataforma de su empresa. No una demo. No una presentación. Software funcional que corre en el entorno real del cliente.
Piensa en la diferencia entre un médico que lee tu expediente desde otra ciudad y un médico que se sienta en la sala, te examina y empieza el tratamiento en ese mismo momento. El FDE es el segundo médico.
Palantir, una gran empresa de analítica de datos que crea software para gobiernos y grandes empresas, creó este rol a principios de la década de 2010 y originalmente llamó "Deltas" a estos ingenieros.1 Hasta alrededor de 2016, Palantir tenía de hecho más FDEs que ingenieros de software regulares, porque sus clientes, agencias gubernamentales y grandes empresas tradicionales, necesitaban a alguien en sitio que pudiera atravesar la burocracia interna con mentalidad de startup. La forma en que Palantir explica la diferencia es la más clara: un desarrollador regular se enfoca en una capacidad, muchos clientes (crear una función y enviarla a todos), mientras que un FDE se enfoca en un cliente, muchas capacidades (integrarse con un cliente y resolver lo que necesite). La descripción del trabajo captura el alcance: se parece al de un CTO de startup. Te haces cargo de todo, de principio a fin, en proyectos de alto riesgo.
No es lo mismo que un Solutions Architect o un Sales Engineer. Un Solutions Architect asesora: ejecuta demos, diseña soluciones en pizarras y crea prototipos de prueba de concepto con datos de muestra para convencer a un prospecto de firmar. Una vez cerrado el trato, su participación suele disminuir. Un FDE toma el relevo donde el Solutions Architect termina. Escribe código de producción directamente en la infraestructura del cliente, con datos reales, y se queda hasta que el cliente obtiene valor real. La prueba simple: si el rol es responsable de lograr que un trabajo específico para el cliente funcione realmente en producción, está más cerca de un FDE. Si es responsable de demostrar o explicar el producto, está más cerca de un solutions architect.
Un ejemplo real: el equipo de despliegue de OpenAI se integró con John Deere, la empresa agrícola de casi 190 años, para resolver en terreno un problema de temporada de siembra. A partir del historial de uso de cada agricultor, ayudaron a crear recomendaciones impulsadas por IA sobre cuánto menos químico necesitaría un agricultor con See & Spray, el sistema de control selectivo de malezas de John Deere. John Deere atribuye al trabajo una reducción del uso de químicos de alrededor del 70% y un aumento de seis veces en la interacción con clientes.2 La fecha límite era el calendario de siembra, no una hoja de ruta de producto. Esa es la labor del FDE en una línea: software real de producción, construido en el mundo del cliente y enviado cuando el cliente realmente lo necesita.
El FDE es donde se encuentran el código, el producto y el cliente: la capacidad de construcción del software engineer, el instinto de producto del platform engineer y la lectura del cliente del solutions architect, en una sola persona que construye en el mundo del cliente, no en la sede.
Por qué ahora todas las empresas de IA quieren FDEs. Las ofertas de empleo para FDE crecieron más de 800% en los tres primeros trimestres de 2025.3 Salesforce creó un equipo dedicado de FDEs para apoyar su plataforma Agentforce.4 OpenAI creó la "Deployment Company", una subsidiaria de propiedad mayoritaria respaldada por unos 4.000 millones de dólares de un consorcio de inversionistas, construida en gran parte alrededor de dotar a empresas con FDEs.5 La razón detrás de todo esto es simple: un estudio de 2025 del MIT Media Lab (Project NANDA) encontró que cerca del 95% de los pilotos de IA empresarial personalizada no muestran retorno medible.6 No porque la IA no funcione, sino porque encajarla en los sistemas reales, desordenados y concretos de una empresa es increíblemente difícil. Los FDEs existen para cerrar esa brecha. Son la razón por la que Palantir superó una capitalización de mercado de 136.000 millones de dólares a finales de 2024, por encima de Lockheed Martin,7 y ahora todas las empresas de IA quieren replicar el modelo.
El problema del lock-in con proveedores. Aquí está la trampa. Cada FDE de Palantir construye sobre la plataforma de Palantir. Cada FDE de OpenAI construye sobre los modelos de OpenAI. Cada FDE de Salesforce construye sobre las herramientas de Salesforce. El ingeniero entra profundamente en la empresa del cliente, conecta el producto de un solo proveedor con todo y se va. Cambiar después es doloroso y caro, como un plomero que solo instala una marca de tuberías: la plomería funciona, pero nunca puedes contratar a otro plomero sin romper las paredes. Como señaló Andrew Ng en The Batch,8 los clientes tienen dificultades para encontrar FDEs que no estén atados a un solo proveedor, porque el objetivo del rol, para el proveedor, es retener al cliente.
Este libro forma el FDE que el mercado sigue pidiendo pero no encuentra. El método de aquí no está atado a ningún proveedor. Una persona graduada de este libro lleva el pipeline completo (especificar la intención, construir el Worker, diseñar el sistema, operarlo en producción) dentro de la organización de un cliente sin encerrarlo en una sola plataforma. Cuando aparezca un modelo mejor el próximo trimestre, o un runtime más barato el próximo año, cambias. El cliente conserva la libertad de elegir, y tú conservas la disciplina que funciona en cualquier stack. Hay que nombrar un intercambio honesto: el FDE de un proveedor está fuertemente subsidiado, a veces es gratuito, porque el proveedor recupera ese costo con lock-in, mientras que un FDE neutral respecto del proveedor lo paga el cliente o una firma independiente. Esa es la característica, no el defecto: el cliente compra opcionalidad ahora en lugar de pagar costos de cambio después.
Ese es el segundo rol que casi nadie más forma. Y para ser exactos con la afirmación: lo que el libro forma es el núcleo técnico del FDE neutral respecto del proveedor, la mitad que el mercado no encuentra. La otra mitad, descubrimiento con clientes, priorización, encuadre del ROI y la disciplina para oponerse a una petición poco realista, pertenece a la vía Certified Agentic AI Business Strategist. Forma el núcleo técnico; la capa de consultoría vive en la vía de Strategist.
Los roles de apoyo
Todo pipeline necesita personas que revisen el trabajo, establezcan las reglas y asuman responsabilidad. Estos tres roles hacen eso.
Evals Engineer: la persona que somete a prueba de choque a los AI Workers antes de que entren en producción. No enviarías un automóvil sin pruebas de choque. No lanzarías un medicamento sin ensayos clínicos. Un AI Worker que toma decisiones que afectan a personas reales y dinero real necesita la misma disciplina. El Evals Engineer diseña esas pruebas: ¿da el Worker la respuesta correcta? ¿Falla con elegancia cuando se enfrenta a algo que nunca ha visto? ¿Se mantiene dentro de los límites que recibió? Esto no es un añadido de último momento. Está integrado en cada capítulo. Currículo central, no un añadido.
AI Governance Officer: decide qué puede hacer la IA. Todo empleado de una empresa tiene límites. Un contador junior puede aprobar gastos hasta 500 dólares, pero necesita la firma de un gerente por encima de esa cifra. Un cajero bancario puede procesar un depósito, pero no aprobar un préstamo. Los AI Workers necesitan la misma estructura. El Governance Officer escribe esas reglas a nivel de la empresa: qué puede decidir la IA por sí sola, qué debe pasar a un humano para aprobación y qué no debe tocar nunca. También maneja el mapeo hacia las regulaciones que la empresa deba cumplir: reglas de préstamos justos en un banco, privacidad de pacientes en un hospital, leyes de residencia de datos en Europa. El AI-Native Company Architect construye el sistema que aplica esas reglas; el Governance Officer decide qué deben decir. El libro forma directamente esta disciplina de marcos; las regulaciones específicas de tu industria son los insumos que tú aportas. Forma el marco de gobernanza; las reglas de tu jurisdicción te corresponde aportarlas.
Digital FTE Supervisor: la persona cuyo nombre queda en la línea. Cuando un AI Worker procesa un reclamo, redacta un contrato o marca una transacción, alguien debe rendir cuentas. Esa persona es el Supervisor. Es el humano en el bucle: quien revisa el trabajo, quien aprueba la salida, el nombre al que apunta la pista de auditoría cuando algo sale mal. No es la persona que construyó el Worker. Es la persona que lo opera día a día, como un jefe de turno opera un equipo. Lo forma.
Dónde se detiene el libro de forma deliberada
LLMOps Engineer: hasta el modelo, no el modelo en sí. Operar agentes en producción es trabajo del Cloud AI Engineer, y el libro lo forma. El libro también forma el ajuste fino de manera práctica, pero como último recurso, no como opción por defecto. Un ajuste fino ata tu sistema a una instantánea de un modelo y cuesta la opcionalidad que protege todo el método, así que recurres a él solo cuando prompting, contexto, herramientas y recuperación realmente se quedan cortos. La parada firme es construir el modelo en sí: el preentrenamiento de un modelo base desde cero queda fuera de alcance, porque esa capacidad se está convirtiendo en un bien común. Forma el ajuste fino y las operaciones alrededor del modelo, no la construcción de modelos base.
Harness Engineer: el runtime que usas, no el que construyes. El harness es el runtime del agente, OpenAI Agents SDK, los agentes gestionados de Claude y similares, que ejecuta el bucle del agente, gestiona el estado y ejecuta llamadas a herramientas. El libro te forma para usarlos con fluidez y mantenerte portable entre ellos, porque tu disciplina sobrevive a cualquier runtime que termine ganando. Construir el runtime en sí no es el trabajo. Forma al operador que usa cualquier runtime, no al ingeniero que construye uno.
AI Data Engineer: la capa de datos orientada al agente. El trabajo del sistema de registro toca la capa de datos orientada al agente: Postgres, pgvector y MCP como la columna desde la que lee un agente. La ingeniería clásica de pipelines y almacenes de datos es adyacente, no central. Forma la capa de datos orientada al agente, no la ingeniería de datos general.
El patrón lo dice todo. La era de los agentes despliega el trabajo en muchos roles, no en uno solo: construir Workers, operarlos y gobernarlos, enseñarles criterio. El mapa es lo que importa: encuentra dónde ya estás parado y hasta dónde te lleva este libro desde ahí.