¿Qué herramientas usan los forward-deployed engineers? Un stack abierto y ontología-first

La versión corta: la ingeniería forward-deployed es el rol que más crece en la AI empresarial — contratación ~1.000 % interanual, OpenAI comprometiendo 4.000 M$ a una compañía de deployment. El playbook que funciona es el método ontología-first de Palantir. Pero pregunta a un FDE en activo por su semana real y oirás cinco dolores recurrentes: la fontanería devora el engagement, las demos mueren en la revisión de seguridad, los requisitos cambian más rápido que el código, los patrones nunca capitalizan entre clientes y la entrega envenena la relación. Este artículo recorre los cinco, en concreto, y muestra cómo un stack abierto y ontología-first elimina cada uno — terminando con la pregunta que creemos que definirá la próxima ola del rol: la entrega de la ontología. ¿La ontología del cliente sale del engagement como archivos abiertos y tipados en su repo, o como palanca de renovación en la plataforma de otro?

El trabajo que nadie describe con honestidad

Las ofertas hablan de «ambigüedad 0→1» y bandas de 300–550K $ (Perspective AI, TechTarget). El trabajo real es hacer que la AI funcione dentro de los muros de otro: sus datos, sus permisos, su oficina de cumplimiento, su definición de «suficiente». Palantir codificó el método hace años: sus AI FDEs construyen primero una ontología específica del cliente antes de entregar cualquier aplicación LLM y dedican el 30–40 % de la semana al discovery (guía AI FDE de Palantir). El método es correcto. Dónde se va la semana de verdad lo decide la herramienta que hay debajo. Cinco dolores, uno por uno.

Dolor 1 — La semana uno siempre es fontanería

Todo engagement empieza igual: antes de mostrar un solo objeto de negocio en pantalla necesitas auth, SSO, roles, APIs CRUD, una UI de administración, almacenamiento de archivos y una tabla de auditoría. Nada de eso es la razón por la que el cliente te contrató. Tu diferenciador — el 30–40 % del tiempo dedicado a entender su negocio — queda aplastado por el 60 % dedicado a reconstruir el mismo sustrato indiferenciado que ya construiste para el cliente anterior.

Lo que cambia el stack: el sustrato ya está. Un comando y, antes de comer, están corriendo la Console, el login con SSO, los permisos de rol/fila/campo, el log de auditoría, las APIs REST y un servidor MCP:

npm create objectstack@latest client-app && cd client-app
npx os dev --ui   # Console en :3000 — auth, RBAC y auditoría ya aplicados

Todo lo derivable lo deriva el runtime. Lo único que queda por escribir es lo único que solo tú puedes escribir: los objetos, flujos y reglas de permisos del cliente. La semana uno se convierte en discovery y modelado — el trabajo en el que de verdad te diferencias.

Dolor 2 — La demo que muere en la revisión de seguridad

Conoces el arco. Viernes de la semana uno: una demo pegada con cinta — una UI improvisada sobre un CSV copiado — y la sala aplaude. Mes dos: infosec entra con tres preguntas. ¿Qué puede ver exactamente la AI? ¿Con permisos de quién actúa? ¿Dónde está el registro de auditoría? Para un stack de demo, la respuesta honesta es una reconstrucción, y la reconstrucción es donde mueren los engagements.

Lo que cambia el stack: la gobernanza es el sustrato, no un parche posterior. La puerta de validación ni siquiera acepta un objeto sin modelo de compartición declarado:

export const Ticket = ObjectSchema.create({
  name: 'support_ticket',
  label: 'Ticket',
  sharingModel: 'private',        // obligatorio — sin él, la puerta lo rechaza
  fields: {
    subject:  Field.text({ label: 'Subject', required: true }),
    status:   Field.select({ label: 'Status', options: [/* los estados reales del cliente */] }),
    approver: Field.lookup('sys_user'),
  },
});

En runtime, cada llamada — UI humana, REST o un agente de AI por MCP — pasa por el mismo RBAC, la misma seguridad de fila y de campo, y aterriza en el mismo log de auditoría. Cuando infosec pregunta «¿qué puede ver la AI?», la respuesta es un archivo que pueden leer: metadatos de permisos aplicados por el runtime, no una promesa en una diapositiva. Tu demo del viernes y tu despliegue de producción son el mismo artefacto. No hay reconstrucción, porque nunca existió una versión sin gobernanza.

Dolor 3 — Los requisitos cambian más rápido que el código

A mitad de reunión, el líder de operaciones dice: «por cierto, los descuentos de más del 20 % pasan primero por los gerentes regionales». En una base de código artesanal eso es una migración de esquema, tres cambios de API, un cambio de UI y una semana — y a ojos del cliente, te volviste lento justo cuando él se volvió concreto. El trabajo forward-deployed vive o muere por la velocidad de iteración dentro de la sala.

Lo que cambia el stack: toda la aplicación es metadato tipado y compacto — un CRM completo son 1.792 líneas, unos 16k tokens (cuéntalo: find examples/app-crm/src -name '*.ts' | xargs cat | wc -l). Eso significa que tu agente de código sostiene el sistema entero en contexto: el cambio de la cadena de aprobación es un diff coherente que cruza flujo, permisos y UI, escrito antes de que acabe la reunión, validado por os validate, previsualizado en vivo en la Console. «¿Qué se rompe si cambiamos esto?» es una pregunta que el agente puede responder de verdad, porque lo ve todo. Los cambios de requisitos dejan de amenazar el calendario y se convierten en la demo.

Dolor 4 — Tus patrones nunca capitalizan

El código de la cadena de aprobación del cliente A no se puede levantar hacia la base de código del cliente B — versiones de framework distintas, auth distinta, todo distinto. Así que cada engagement empieza de cero, y una boutique de tres personas nunca puede construir la palanca que hace funcionar la economía del modelo de Palantir. Esta es la razón silenciosa por la que las consultoras forward-deployed siguen siendo pequeñas.

Lo que cambia el stack: los patrones son metadatos tipados, y los metadatos tipados son portables. La cadena de aprobación que modelaste para el cliente A es una definición de flujo que sueltas en el repo del cliente B y renombras. Con los engagements acumulas una biblioteca propia — objetos, flujos, conjuntos de permisos, datos semilla — que tu agente aplica al siguiente cliente en minutos. Y no empiezas la biblioteca de cero: HotCRM es una referencia completa y forkeable — 15 objetos, 17 flujos, 4 dashboards, 2 copilotos de AI, 4 idiomas — construida como ejemplo canónico de las convenciones. Haz fork, renombra el namespace, y tu engagement arranca desde un sistema que funciona en lugar de un repo vacío.

Dolor 5 — La entrega envenena la relación

Todo engagement termina, y hoy termina mal de una de dos maneras. Entrega una plataforma y el cliente alquila su propia ontología para siempre — te has convertido en canal de ventas de otro, y él ha aprendido a temer los pilotos exitosos: cuanto mejor la ontología, más profundo el lock-in. Entrega una base de código a medida y su equipo no puede mantenerla; se pudre, y dieciocho meses después esa podredumbre lleva tu nombre.

Lo que cambia el stack: esto es la entrega de la ontología — el final que el playbook FDE nunca resolvió. Lo que entregas es el repo del cliente: objetos, flujos y permisos tipados bajo Apache-2.0, más el artefacto compilado y una checklist de revisión. Su equipo de seguridad ya leyó cada línea — son 16k tokens, no 300.000 líneas. Sus propios agentes de código lo mantienen con el mismo bucle que tú usaste, porque el formato nació para ser escrito por agentes. Si quieren la plataforma operada — AI Builder en el navegador, cloud o self-managed — está ObjectOS, sobre la misma definición abierta; pueden irse sin perder la ontología. Tu siguiente contrato se gana con trabajo nuevo, no se extrae con lock-in. Esa diferencia es tu reputación, capitalizando.

El kit completo de metadatos del FDE

La ontología no es solo el modelo de datos. Un engagement forward-deployed usa un tipo de metadato para cada fase, del discovery a la entrega — y todos son la misma clase de definición tipada, validable y portable:

Fase	La pregunta del cliente que respondes	Tipos de metadatos que usas
1 · Modelar los sustantivos	«¿Qué existe en nuestro negocio?»	Objetos y campos (relaciones, reglas de validación, fórmulas) · datasources (conectar bases de datos existentes, sin migración) · datos semilla (para demos y aceptación)
2 · Modelar los verbos	«¿Cómo fluye realmente el trabajo?»	Flujos (cadenas de aprobación, máquinas de estados, triggers de registro, programaciones) · aprobaciones (multinivel, colas, bloqueo de registro) · acciones (botones y operaciones de servidor con permisos verificados)
3 · Pantallas para personas	«¿Dónde trabaja nuestra gente?»	Apps y navegación · vistas (lista/kanban/calendario/gantt) · páginas y formularios · dashboards e informes (los KPI que piden los ejecutivos)
4 · Pasar la revisión de seguridad	«¿Quién puede ver y hacer qué?»	Conjuntos de permisos y roles (RBAC) · seguridad de fila y de campo · reglas de compartición · auditoría (integrada en el runtime — declarada, entregada)
5 · La AI que el cliente quiere de verdad	«¿Qué puede hacer la AI por nosotros?»	Agentes de AI (copilotos de ventas/soporte) · herramientas y skills de AI · exposición MCP (ai: { exposed: true })
6 · Entrega y capitalización	«¿Qué pasa cuando te vayas?»	Traducciones (etiquetas multiidioma para clientes globales) · manifiesto y empaquetado (compilar a un objectstack.json, instalable en cualquier entorno)

La clave: las seis capas son la misma sustancia. Una cadena de aprobación es metadato tipado exactamente igual que el modelo de datos, y un agente de AI también — la misma puerta de validación los revisa, el mismo diff los evalúa, el mismo repo los entrega:

// The client's verbs: a discount approval — typed metadata, same as an object
export const DiscountApproval: Flow = {
  name: 'discount_approval',
  label: 'Discount Approval',
  type: 'record_change',
  status: 'active',
  nodes: [
    { id: 'start', type: 'start', label: 'Start',
      config: { objectName: 'crm_quote', triggerType: 'record-after-update',
                condition: 'record.discount > 0.20' } },
    { id: 'review', type: 'approval', label: 'Regional Manager Review',
      config: { approvers: [{ type: 'position', value: 'regional_manager' }], lockRecord: true } },
    { id: 'end', type: 'end', label: 'End' },
  ],
  edges: [/* start -> review -> end */],
};

// The AI the client actually wants: a service copilot — still metadata
export const ServiceCopilot = defineAgent({
  name: 'service_copilot',
  label: 'Service Copilot',
  instructions: 'Help support reps triage and resolve cases. Retrieve only within the user\'s permissions. Always cite case IDs.',
  skills: ['case_triage', 'customer_360'],
  knowledge: { topics: ['support_kb', 'sla_policies'] },
});

HotCRM es la demostración completa de este vocabulario en uso: 15 objetos, 17 flujos, 10 acciones, 4 dashboards, 2 copilotos de AI, 6 skills, 6 perfiles de permisos, 5 reglas de compartición y 4 idiomas — todas las capas presentes, unos 170k tokens, y el conjunto sigue cabiendo en una sola ventana de contexto de agente.

Lo que este stack no arregla

Tratando con justicia a las alternativas: la federación de datos y los pipelines analíticos a escala Foundry son el terreno de Palantir — si el engagement va de fusionar petabytes entre cuarenta sistemas legacy, esa es otra clase de herramienta. La gestión del cambio organizacional no la arregla ningún stack. Y un cliente ya estandarizado por completo en una plataforma cerrada puede, racionalmente, quedarse. La afirmación es más estrecha: para la capa de aplicación del trabajo forward-deployed — modelar un negocio y entregar apps gobernadas sobre él — los cinco dolores de arriba ahora son eliminables, y la ontología puede entregarse en lugar de retenerse como rehén.

La checklist del FDE

1. Modela los sustantivos y verbos del cliente como objetos y flujos antes de cualquier conversación de UI.
2. Mantén la definición completa a escala de contexto para que tu agente pueda razonarla y refactorizarla entera.
3. Permisos conservadores por defecto; todo cambio de autoridad explícito en el diff.
4. Entrega el repo, el artefacto compilado y una checklist de revisión — no un login a tu tenant.
5. Deja MCP habilitado para que la propia AI del cliente opere la app dentro de sus permisos.

Prueba el bucle

Apunta tu agente de código al stack abierto — el scaffold trae AGENTS.md y el paquete de skills, así que el agente arranca con las reglas del formato cargadas:

npm create objectstack@latest client-app && cd client-app
npx os dev --ui   # la app funcionando — modela el primer objeto con tu agente

Para clientes que quieren la plataforma operada, ObjectOS es el runtime comercial sobre la misma definición abierta — construye y pregunta online, gobernanza incluida.