Nala no está planteado como una simple llamada a un modelo. La parte interesante del proyecto es la arquitectura que rodea al LLM: un runtime propio que prepara el contexto, aplica seguridad, controla herramientas, ejecuta Genkit, valida la salida, actualiza memoria y deja trazabilidad.
Esto es importante porque una demo de IA puede vivir con un prompt grande y una llamada directa al SDK. Un producto real no. En cuanto aparecen memoria, reglas familiares, streaming, señales parentales, herramientas y seguridad, necesitas fronteras claras.
Una integración inicial de IA suele empezar con algo parecido a esto:
const response = await openai.chat.completions.create(...)Eso sirve para validar una idea, pero no responde preguntas de producto:
Nala separa esas responsabilidades en capas. La API adapta HTTP. El runtime gobierna la ejecución. Genkit orquesta prompts y modelo. Los adapters encapsulan persistencia y contexto. Las policies controlan safety, memoria y tools.
Los endpoints principales están en:
api/nala/chat.ts
api/nala/stream.tsSu responsabilidad es deliberadamente pequeña: recibir la petición, validar el contrato público, construir el input interno y delegar en el runtime.
El endpoint normal acaba en:
defaultNalaRuntime.runChatFlow(...)El endpoint de streaming acaba en:
defaultNalaRuntime.runChatStreamFlow(...)La diferencia entre ambos está en la entrega de la respuesta, no en el modelo mental de ejecución.
El centro está en src/runtime.ts:
createNalaRuntime(deps)Esta función crea un runtime con dependencias explícitas:
allowLlmToolUse;runChatFlow y runChatStreamFlow.La decisión es buena porque evita que todo dependa de singletons globales. Un runtime aislado puede usar adapters inyectados y mantener garantías claras en tests, entornos separados o futuras configuraciones multi-tenant.
El runtime por defecto usa inMemoryNalaContextAdapter y activa allowLlmToolUse: true para Developer UI y flujos globales. Los runtimes custom, en cambio, tienen allowLlmToolUse a false por defecto.
El flujo de un turno no es “prompt → modelo → respuesta”. Es una pipeline.
Los pasos principales son:
const trace = createTrace('nalaChatFlow', input.metadata?.traceId)
const prepared = await prepareNalaTurn(input, trace, services)
const promptInput = buildChatPromptInput(input, prepared)
const relevantTools = selectRelevantTools(input, prepared, services)
const fallback = fallbackPromptOutput(input, prepared)
const { skip, reason } = shouldSkipChatLlm(prepared)Después, si no se salta el LLM, se ejecuta:
const response = await nalaChatPrompt(promptInput, {
tools: relevantTools.actions,
maxTurns: 3,
returnToolRequests: true,
})Y finalmente:
return finalizeNalaTurn({ input, prepared, promptOutput, trace, services })La parte importante es que el fallback se prepara antes de llamar al modelo. Si el LLM falla o si safety recomienda no usarlo, el sistema puede responder de forma controlada.
Genkit se inicializa en src/genkit.ts:
export const ai = genkit({
name: 'nala-ai-api',
plugins: [openAI()],
model: `openai/${resolveNalaModelName()}`,
})En Nala, Genkit aporta:
definePrompt;Pero Genkit no contiene toda la lógica de negocio. La arquitectura queda más sana si Genkit se usa como capa de ejecución IA y el runtime conserva las decisiones de producto.
Los contratos están en src/contracts/nala.contracts.ts.
Algunos schemas clave:
NalaChatInputSchema;NalaChatPromptInputSchema;NalaChatPromptOutputSchema;NalaChatOutputSchema;NalaSafetyOutputSchema;NalaIntentOutputSchema;NalaSessionUpdateSchema.Esto reduce ambigüedad. La API no recibe cualquier cosa. El prompt no consume un objeto improvisado. La respuesta final no sale al cliente sin validación.
En IA esto importa especialmente porque el modelo puede fallar de formas raras. Los contratos reducen el radio de impacto.
La forma correcta de mirar Nala es como un control plane alrededor del LLM.
El modelo está rodeado por cuatro fronteras:
El LLM responde, pero no decide por sí solo qué contexto ve, qué herramientas usa o qué se guarda.
El tool calling es una de las partes más delicadas de cualquier arquitectura con LLM.
Nala separa dos conceptos:
createNalaTools(adapters)crea herramientas internas cerradas sobre adapters inyectados.
Y por otro lado están las tools de Genkit declaradas con ai.defineTool.
La selección por turno se hace con:
selectRelevantTools(input, prepared, services)Además, allowLlmToolUse controla si las acciones se pasan realmente al modelo.
Este detalle evita un problema sutil: las tools de Genkit son globales. Si se pasan a un runtime aislado sin cuidado, pueden acabar usando adapters globales en lugar de los adapters inyectados. Por eso el runtime custom no permite LLM tool use por defecto.
Safety no debería ser solo una línea dentro del prompt. En Nala es una parte de la ejecución.
prepareNalaTurn integra intención, safety, memoria y reglas familiares antes de construir el prompt final. El safety flow puede devolver información como:
safetyLevel;allowed;categories;blockedReason;redirectionStrategy;parentSignal.Esto permite que el runtime decida si llama al LLM, si usa fallback o si registra una señal parental.
Para un asistente con contexto infantil/familiar, esa separación no es opcional. Privacidad, tono y límites son parte del producto.
La memoria de Nala no intenta guardar todo.
La estrategia es mantener continuidad sin convertir la memoria en un contenedor peligroso:
La memoria útil suele ser pequeña. Recordar “le gustan los dinosaurios” puede mejorar la experiencia. Guardar datos personales sensibles no.
El streaming se implementa como variante del mismo runtime.
La ejecución llama a:
nalaChatPrompt.stream(promptInput, {
tools: relevantTools.actions,
maxTurns: 3,
returnToolRequests: true,
})Los chunks se emiten de forma progresiva y, al final, se espera la respuesta estructurada completa para validar y finalizar.
Esto evita crear una segunda arquitectura para streaming. La ruta normal y la ruta streaming comparten preparación, safety, tool selection, fallback y finalización.
Nala registra trazas con:
createTrace;addTraceStep;recordToolCall;completeTrace.Esto permite saber qué intención se detectó, qué safety level salió, qué herramientas fueron seleccionadas, si hubo fallback y cómo terminó el turno.
En sistemas de IA, la observabilidad no es un extra. Sin trazas, depurar una mala respuesta es casi adivinar.
El proyecto incluye tests y datasets de evaluación para áreas como:
Esto es buena señal: una app de IA no se valida solo probando manualmente varias frases. Necesita regresión repetible.
La arquitectura gana control y testabilidad, pero añade más piezas:
Aun así, para un asistente sensible, ese coste es razonable. La alternativa —un prompt enorme con demasiadas responsabilidades— escala peor.
Las evoluciones naturales serían:
Lo interesante de Nala no es solamente que use Genkit.
Lo interesante es cómo lo usa: Genkit vive dentro de un runtime que controla contexto, seguridad, memoria, herramientas, fallback, streaming y salida final.
Ese diseño es lo que diferencia una demo de chatbot de una base seria para un asistente de IA en producción.
Después de explicar qué es Nala y por qué tiene sentido como producto, la parte técnica merece un espacio aparte. También ayuda recordar qué significan sus siglas: Natural Adaptive…
Conocí Genkit en el European GenAI Summit y, aunque todavía no lo he explorado a fondo, las primeras sensaciones son muy buenas. No solo por la velocidad con la que puedes montar f…
