WhatsApp AgentKit

Antes de instalar nada conviene saber exactamente qué compras con la sesión que estás por empezar. Esta sección es eso: lo que te queda funcionando, lo que no, y cuál de las tres guías de WhatsApp de la bóveda es la tuya.

Tres negocios, tres agentes distintos

El mismo kit, respondiendo con lo que tú le hayas dado. Lo que cambia entre uno y otro no es el programa: es lo que contestaste en la entrevista y los archivos de tu negocio que le dejaste a mano.

Qué pasa entre que tu cliente escribe y le llega la respuesta

Seis pasos. No hace falta que los entiendas para usar el kit, pero el día que algo falle vas a saber en cuál de los seis mirar.

1  Tu cliente escribe. El mensaje llega al
   proveedor (Zernio o Meta).

2  El proveedor se lo manda a tu servidor
   por el webhook.

3  Tu servidor verifica la firma y
   descarta el aviso si ya lo había
   recibido antes.

4  Contesta 200 de inmediato y sigue
   trabajando por su cuenta.

5  Busca el historial de esa conversación
   y se lo manda a Claude junto con el
   mensaje y la información de tu negocio.

6  Claude escribe la respuesta y se envía
   de vuelta por WhatsApp.

Lo que tu agente todavía no hace solo

Ese cableado se puede hacer y no lo tienes que escribir tú: el apartado de personalizar trae el prompt que conecta una de esas funciones de punta a punta. Pero es un paso más, y no viene hecho.

Si esta no era tu guía

En la bóveda hay tres caminos para poner un agente en WhatsApp y se parecen poco entre sí. Este es el corto: una entrevista y ya.

La que cierra ventas es el AgentKit que cierra ventas, y ahí viven también los plazos de verificación de negocio en Meta.

La del código QR es OpenWA, WhatsApp sin Meta: lo hospedas tú, sin proveedor de por medio.

Cuatro para construir tu agente, y dos de ellas se instalan con un comando cada una. Conviene tenerlas antes de empezar, porque el kit revisa dos de las cuatro apenas arranca y se detiene ahí mismo si le falta alguna.

Cada una hace algo distinto y ninguna sustituye a otra: Python es lo que corre tu agente, Claude Code es lo que lo escribe, la llave de Anthropic es lo que lo hace pensar y la cuenta de WhatsApp API es por donde entran y salen los mensajes.

Más adelante vas a abrir dos cuentas más —GitHub en la sección 10 y Railway en la 11—, pero esas se crean sobre la marcha, cuando toque subir tu agente y ponerlo en internet. Hoy no te hacen falta.

Revisa Python antes de bajar nada

Puede que ya lo tengas puesto. Abre la Terminal, pega esto y mira qué te contesta:

Si responde un número igual o mayor a 3.11 —3.11, 3.12, 3.13—, ya está: no instales nada.

Si responde un número menor, o si te dice que no conoce el comando, instálalo con la ruta de tu sistema y vuelve a correr esta misma línea hasta que el número te cuadre.

Instalar Claude Code, y autenticarlo una vez

Con Node puesto, Claude Code se instala con un comando. Va en la misma Terminal y da igual en qué carpeta estés parado:

Falta el paso que casi todo el mundo se salta. Cuando termine de instalar, escribe claude a secas y deja que abra sesión con tu cuenta. Se hace una sola vez y sin eso la herramienta queda instalada pero muda.

Recién cuando claude abre sin pedirte nada conviene seguir al paso de bajar el kit. Ahí se revisa que esté a la mano, y si no lo está el arranque se corta y te pide justo este comando.

Lo único que se paga por uso es lo que tu agente le pregunta a Claude. Cuánto, con números y con fecha, está al final, en la cuenta completa.

Tu agente le habla a Claude por su cuenta, a las tres de la mañana y sin que tú estés adelante. Para eso necesita una llave propia: un texto largo que Anthropic te entrega una sola vez y que tu servidor presenta cada vez que tiene que pensar una respuesta.

Sacarla son cinco clics y no llega a dos minutos. El único que hay que hacer con cuidado es el último, porque la llave se muestra una vez y después esa pantalla ya no vuelve.

Todo pasa en la consola de Anthropic, que no es la misma página donde chateas con Claude: platform.anthropic.com. Ese enlace te deja directo en la pantalla de las llaves.

Los cinco clics, en orden

No es lo mismo que tu suscripción de Claude Code

Son dos cuentas con el mismo apellido. La suscripción es para que trabajes tú, con Claude Code abierto en tu computadora. La llave es para que trabaje tu agente, solo, desde el servidor, mientras tú haces otra cosa.

Por eso tener Claude Code pagado no te ahorra la llave, y tener la llave no te da Claude Code. La llave se factura aparte y por uso: pagas por lo que tu agente conversa, no una mensualidad fija.

Cuánto es ese uso —por modelo, por conversación y al mes— está en la sección 15, con su fecha. Los números viven ahí y solo ahí, con el día en que se consultó cada tarifa.

Qué modelo usa tu agente, y cómo se cambia

De fábrica tu agente piensa con claude-sonnet-5. Si quieres otro, no hay que abrir un archivo de código ni entender Python: se cambia el valor de una variable y ya.

Estas son las cuatro que tocan a Anthropic. La primera es la llave que acabas de sacar; las otras tres traen un valor por defecto que ya funciona.

claude-sonnet-5

low

4096

Si no escribes ninguna de las tres opcionales, tu agente arranca con esos mismos valores.

Tu agente necesita una puerta por la que entren y salgan los mensajes de WhatsApp. Hay dos, y elegir es la única decisión de la guía que conviene tomar antes de escribir nada. Tranquilo, que no es cara: al final de la sección está qué pasa si eliges mal.

Qué es cada uno

Zernio corre sobre la WhatsApp Cloud API de Meta. No la reemplaza: se para encima y te resuelve las tres partes que más tardan. El Embedded Signup —la ventana de Meta donde eliges o creas tu cuenta de WhatsApp Business y su número, sin salir de ahí—, un inbox donde ves las conversaciones, y webhooks firmados, que es lo que hace que tu agente pueda distinguir un aviso legítimo de uno inventado. No tienes que crear una app de Facebook ni pasar App Review.

Meta Cloud API directo es conectarte tú, sin nadie en medio. Creas una app de Facebook tipo Business, le agregas el producto de WhatsApp, generas tus propias credenciales y das de alta el webhook con tus manos. Nada de eso es difícil: son más pasos, y uno de ellos —App Review— lo revisa Meta y no depende de ti.

Las cuatro diferencias

Esta tabla es del propio kit. Léela por la columna que te interese y fíjate menos en qué camino es «mejor» que en cuál de los dos te pide cosas que hoy no tienes:

Ninguna fila habla de dinero, y es a propósito: lo que cuesta cada camino va junto con el resto de los números, en la sección de costos.

Se elige una vez, en la pregunta 9

Esta decisión no se declara en ningún archivo ni se configura dos veces. La entrevista te lo pregunta —es la pregunta 9 de las diez—, y con esa respuesta Claude Code escribe solo el adaptador del que elegiste.

Si eliges Zernio, el archivo que habla con Meta ni siquiera se escribe. Y al revés. Así que cuando mires tu carpeta vas a ver un proveedor y no dos: no es que falte algo, es que lo otro nunca llegó a existir.

Zernio corre sobre la WhatsApp Cloud API de Meta: pone de su lado el alta con Meta, la bandeja de conversaciones y los avisos firmados. Eso es exactamente lo que te ahorra crear una app de Facebook y pasar por App Review.

De esta sección te llevas dos valores y nada más: la API key, que te la enseña el panel una sola vez, y el secreto del webhook, que no está en ninguna pantalla porque lo inventas tú. Con esos dos, y con el número de pruebas encendido, puedes ver a tu agente contestando el mismo día.

La ruta del panel, tal cual, sin desvíos

Los dos valores, con el nombre que van a llevar

Estos son los nombres exactos con los que vas a ver escritos tus dos datos. No tienes que abrir ningún archivo a mano: Claude Code te los pide de a uno y los escribe él.

El número de pruebas: para qué sirve y para qué no

Zernio presta un número compartido para que veas tu agente andando antes de tener uno propio. Se enciende abriendo una sesión contra tu celular: te llega un WhatsApp con una plantilla llamada sandbox_start y tienes que responderlo desde tu teléfono. Ese «responder» es lo que abre la sesión, y sin él no pasa nada más.

Cupos verificados el 17 de septiembre de 2026.

Enciéndelo sin escribir un solo comando

Un detalle que te va a confundir si miras la documentación: para listar los números, la doc de Zernio dice GET /v1/phone-numbers y el documento del kit dice /api/v1/whatsapp/phone-numbers. No tienes que elegir a ciegas, y el prompt tampoco: prueba las dos y se queda con la que responda.

Quiero ver mi agente andando en WhatsApp hoy, con el número de pruebas de Zernio. Hazlo tú de punta a punta.

CONTEXTO:
- Mi llave de Zernio ya está en el .env de esta carpeta, en la variable ZERNIO_API_KEY. Léela de ahí. No me la pidas por chat.
- Base de la API: https://zernio.com/api/v1. La autenticación va en Authorization: Bearer con esa llave.
- Para listar los números hay dos rutas en circulación: la doc dice GET /v1/phone-numbers y el CLAUDE.md del kit dice /api/v1/whatsapp/phone-numbers. Prueba las dos y usa la que responda.
- Mi celular con WhatsApp, con código de país: [ESCRIBE AQUÍ: +52 55 1234 5678]

OBJETIVO:
Dejar una sesión del número de pruebas activa contra mi celular, confirmada por la API y no por lo que supones.

QUÉ HACER, EN ESTE ORDEN:
1. Descubre el número de pruebas con la ruta que te responda.
2. Abre la sesión con POST /v1/whatsapp/sandbox/sessions y mi celular.
3. Avísame, antes de seguir, que me va a llegar un WhatsApp con la plantilla sandbox_start y que tengo que RESPONDERLO desde mi celular. Espera a que yo confirme que respondí.
4. Consulta el estado de la sesión hasta que la API diga que está activa.

RESTRICCIONES DURAS:
- NUNCA imprimas mi ZERNIO_API_KEY, ni entera ni en pedazos.
- NO abras la sesión contra un número que no sea el que te di.
- NO abras una segunda sesión: solo se permite una activa a la vez.
- NO me digas que quedó activado si la API no lo confirmó.

CRITERIO DE ACEPTACIÓN, compruébalo tú:
- La ruta de números respondió 200 y trajo un número.
- El estado de la sesión dice que está activa.
- Ninguna salida que me muestres contiene la llave.

QUÉ REPORTAR AL FINAL:
Qué ruta funcionó, el estado de la sesión, y mis tres límites: 50 mensajes y 5 destinatarios distintos cada 24 horas, y que la sesión activada dura 7 días.

Dos cosas antes de seguir. El prompt de aquí arriba no se corre ahora: pide el kit ya bajado y tu llave ya escrita en el .env, que son las secciones 07 y 08. Vuelve por él cuando el chequeo de salud de la sección 09 te conteste ok, y ahí sí vas a ver a tu agente contestando en WhatsApp.

Y si te quedaste con Zernio, la sección de Meta no te toca: sáltatela entera y sigue con la que baja el kit a tu computadora.

Son cuatro datos, y viven en dos pantallas distintas del panel de desarrolladores. Dos los copias, uno te lo inventas tú y el cuarto está escondido detrás de un botón que dice Show.

Ninguno se escribe a mano en un archivo: los dejas donde los tengas a la vista y la entrevista te los va a pedir de a uno. Lo único que pide cuidado es el sexto paso, porque ese texto lo eliges tú y tiene que quedar idéntico en dos lugares.

Todo pasa en un solo panel: developers.facebook.com. Antes de empezar, ten abierto dónde vas a pegar los cuatro valores.

La ruta, en este orden

Los cuatro datos, uno por uno

Ninguno de los cuatro impide que tu agente arranque, y por eso hay que ponerlos bien desde el principio: si el token está mal, el chequeo de salud queda en degradado; si falta el App Secret, arranca, acepta todo lo que le llegue y solo lo avisa en los registros.

Los dos valores que se escriben tal cual

De todo lo de arriba, estos dos son los únicos que puedes ver escritos aquí. Los otros dos son tuyos y no se publican en ninguna página.

agentkit-verify

v25.0

La firma viene en otro encabezado

Cada aviso que Meta le manda a tu agente viene firmado, y esa firma viaja en el encabezado X-Hub-Signature-256, con el formato sha256=<hex>. Zernio firma lo mismo, pero en otro encabezado y sin ese prefijo, así que el código que comprueba una de las dos firmas no sirve para la otra.

Por eso Claude Code escribe un adaptador distinto para cada proveedor, y por eso en la entrevista se elige uno solo: el archivo del otro ni se genera.

Meta     X-Hub-Signature-256: sha256=<hex>
Zernio   X-Zernio-Signature: <hex>

Dónde se pega la URL, qué casillas se llenan y por qué hay cinco segundos de por medio va completo en el capítulo del webhook. Aquí solo importaba de dónde sale el App Secret con el que se comprueba esa firma.

Las dos puertas de este camino

Además de los cuatro datos, Meta te pone dos puertas por delante. Ninguna se salta, y ninguna la pone el kit.

• Una cuenta de Facebook Business verificada.
• Pasar App Review.

Cuánto tardan esas dos puertas no lo vas a leer aquí con un número inventado: los plazos viven, fechados y con su fuente, en el AgentKit que cierra ventas. Si al llegar hasta aquí descubres que tu cuenta todavía no está verificada, esa guía es la que te dice qué sigue.

Con esos cuatro datos guardados terminas aquí. El número de pruebas de la sección 05 no te toca: ese es de Zernio, y si te la saltaste hiciste bien.

Por este camino vas a ver a tu agente contestar primero en tu computadora, en la sección 09, y por WhatsApp solo cuando des de alta el webhook, en la 12. Ahora sigue con la sección que baja el kit.

Tres comandos en la terminal y el kit queda en tu computadora. Van en este orden y de uno en uno; el tercero es el único que hace algo, y aun así no instala nada: solo revisa que tengas lo necesario y deja la carpeta en su sitio.

Abre la terminal y pega el primero tal cual, sin cambiar de carpeta: el kit se baja donde la terminal te deja al abrirla, que es tu carpeta de usuario, y desde ahí funciona igual. Cuando termine vas a tener una carpeta nueva llamada whatsapp-agentkit, y los otros dos se corren ya adentro de ella.

Y si se corta, es por una de dos cosas, las dos de la sección lo que hace falta: o Python no llega a 3.11, o Claude Code no está instalado. Lo resuelves ahí, vuelves a esta carpeta y corres bash start.sh otra vez. No pasa nada por correrlo dos veces.

Cómo sabes que salió bien

[1/4] Python 3.11 o superior: listo
[2/4] Claude Code en el PATH: listo
[3/4] Carpeta knowledge/: creada
[4/4] .env creado a partir de .env.example

Cuatro pasos y te devuelve el control de la terminal. El texto exacto lo pone el script y puede cambiar; lo que no cambia es el orden. Si se detiene antes de llegar al cuarto, el motivo queda escrito en la línea donde paró: no hay que ir a buscarlo a ningún registro.

Abrir Claude Code sin salir de la carpeta

Un comando más, y este cambia con quién estás hablando: hasta aquí le hablabas a la terminal, de aquí en adelante le hablas a Claude Code.

Tiene que abrirse dentro de whatsapp-agentkit, porque lo que ve es lo que hay en la carpeta desde donde lo abriste. Si lo abres en otro lado, no encuentra el kit.

Acabo de clonar este repositorio y voy a construir mi agente de WhatsApp contigo. Antes de arrancar, ubícate.

CONTEXTO, y esto es lo importante:
- Este repositorio NO contiene el agente. Contiene las instrucciones con las que tú lo escribes, y CLAUDE.md es ese sistema entero.
- Por eso agent/, config/, tests/, requirements.txt, Dockerfile y docker-compose.yml todavía no existen, y está bien que no existan: los vas a escribir tú. No me reportes que faltan.
- Lo único que hay son 19 archivos: CLAUDE.md, README.md, start.sh, scripts/audit.py, .env.example y la carpeta .claude/, entre otros.
- Yo no programo: no me muestres diffs ni me pidas editar archivos a mano.

OBJETIVO:
Que quedes ubicado y que yo sepa qué viene, antes de /build-agent.

QUÉ HACER, EN ESTE ORDEN:
1. Lee CLAUDE.md completo, de principio a fin.
2. Corre `python3 --version` y dime qué versión hay.
3. Comprueba que existe .env en la raíz. Si no existe, créalo copiando .env.example, sin escribir ningún valor adentro.
4. Explícame en español simple, en diez líneas como máximo: qué archivos vas a escribir, en qué carpetas van a quedar y cuánto dura la entrevista.

RESTRICCIONES DURAS:
- NO ejecutes /build-agent todavía. Espera a que yo te lo pida.
- NO modifiques CLAUDE.md, README.md, start.sh ni .gitignore.
- NO inventes credenciales ni pongas valores de ejemplo en .env.
- NO instales nada sin avisarme antes qué es y para qué sirve.

CRITERIO DE ACEPTACIÓN, compruébalo tú antes de decir que acabaste:
- `python3 --version` imprime 3.11 o superior.
- `ls .env` muestra el archivo en la raíz de la carpeta.
Si alguno falla, dime en español qué falta y cómo lo consigo, y no sigas.

QUÉ REPORTAR AL FINAL:
La versión de Python, si .env ya existía o lo creaste tú, y tu resumen de diez líneas.

Cuando te conteste con ese resumen de diez líneas, ya estás listo para la entrevista, que es el tramo que sigue.

Hasta aquí juntaste piezas. Este es el tramo donde se construye el agente, y se construye contestando preguntas en español: diez, una por una, sin un solo archivo que abrir ni una línea que escribir.

Claude Code lee el documento del kit, te entrevista y va escribiendo los archivos conforme le respondes. Ninguno de esos archivos existía cuando clonaste.

Ojo con dónde se escribe: eso no es un comando de la terminal. Primero entras a Claude Code —escribes claude y das enter—, y una vez adentro escribes la diagonal y el nombre en su caja de mensajes. Si lo pegas en la terminal a secas, te va a decir que el comando no existe.

A partir de ahí no te apures: se puede contestar con frases largas y desordenadas. Lo que Claude Code no puede es adivinar lo que no le digas.

Las diez preguntas, y qué decide cada respuesta

No son un formulario: cada respuesta aterriza en un archivo concreto o cambia lo que se va a escribir. Esta es la traducción, pregunta por pregunta.

Tres cosas que puedes dejar de cuidar

• Tus llaves nunca terminan escritas dentro del código: van al archivo de configuración, y antes de sobrescribir algo que ya esté en config/ o en las credenciales, Claude Code te pregunta.
• Las dependencias de Python no las instalas tú: mientras corre la entrevista, Claude Code escribe requirements.txt con la lista completa y las instala con pip. Ese es el «más adelante» que anuncia la sección 07.
• Y si te interrumpen a la mitad, no se pierde: el avance queda guardado en config/session.yaml. Vuelves a abrir Claude Code, le dices que retome la entrevista y sigue donde se quedó.

whatsapp-agentkit/
├── agent/              lo que contesta
├── config/             tu negocio y tono
├── knowledge/          tus archivos
├── tests/              las dos pruebas
├── requirements.txt    lo que se instala
├── Dockerfile          cómo se construye
├── docker-compose.yml  todo junto, local
├── .dockerignore       lo que no entra
└── .env                llaves: no se sube

Salvo knowledge/, que ya venía vacía en el clon, nada de eso estaba en GitHub, y no es un descuido: el kit lo excluye a propósito porque es tuyo, no suyo. Si al terminar te falta alguno, la entrevista no llegó hasta el final.

Configura las credenciales de mi agente. Hazlo tú; yo te las paso.

CONTEXTO:
- Estoy dentro de la carpeta del kit. start.sh ya creó el archivo .env a partir de .env.example: es el único que se toca aquí.
- Es para la prueba local, no para un servidor.
- El proveedor que ya elegí: [ESCRIBE AQUÍ: zernio o meta]

OBJETIVO:
Que la configuración quede lista para arrancar en mi computadora, sin un valor inventado.

QUÉ HACER, EN ESTE ORDEN:
1. Pídeme las credenciales UNA POR UNA y espera mi respuesta antes de pedir la siguiente. No me mandes una lista.
2. Pon WHATSAPP_PROVIDER con el proveedor que te di, en minúsculas.
3. ZERNIO_WEBHOOK_SECRET y META_VERIFY_TOKEN los invento yo. Pídemelos igual y avísame que ESE MISMO texto va después en el alta del webhook.
4. Deja PORT=8000, ENVIRONMENT=development y DATABASE_URL en SQLite: sqlite+aiosqlite:///./agentkit.db
5. Borra o comenta TODAS las variables del proveedor que NO elegí.
6. Que no quede ZERNIO_BASE_URL declarada y vacía: una URL sin https:// hace que el envío falle antes de salir a la red.

RESTRICCIONES DURAS:
- NUNCA escribas una credencial mía en el chat ni en un commit.
- NO inventes valores. Si falta uno, detente y pídemelo.
- NO agregues variables que no estén en .env.example.
- NO toques .gitignore aquí.

CRITERIO DE ACEPTACIÓN, compruébalo tú antes de decir que acabaste:
- `grep -c "^WHATSAPP_PROVIDER=" .env` devuelve 1.
- Ninguna obligatoria del proveedor que elegí quedó vacía.
- No queda ZERNIO_BASE_URL con valor vacío y sin comentar.
- `git check-ignore .env` confirma que está ignorado.
Si alguno falla, arréglalo y vuelve a comprobar.

QUÉ REPORTAR AL FINAL:
Los NOMBRES de las variables que quedaron puestas y de las que comentaste —nunca sus valores— y cada criterio de arriba, uno por línea.

Ya tienes tu agente en la carpeta. Antes de subirlo a internet hay dos pruebas, y hay que hacer las dos: una revisa que conteste bien y la otra que el servidor levante. Son cosas distintas y una puede pasar con la otra rota.

Las dos corren en tu computadora. No hace falta WhatsApp, ni webhook, ni dominio: nadie de afuera puede escribirle todavía, así que es el momento de equivocarse.

Prueba 1 — háblale tú, desde la terminal

Las dos pruebas van en la terminal, no dentro de Claude Code: si lo dejaste abierto desde la entrevista, ciérralo y vuelve a la terminal, o abre una ventana nueva y entra a la carpeta con cd whatsapp-agentkit. El primer comando abre un chat ahí mismo. Le escribes como si fueras un cliente y te contesta como le contestaría a un cliente: con el tono que elegiste en la entrevista y con lo que dejaste en knowledge/.

Tú: hola, ¿están abiertos hoy?
Agente: Hola. Hoy atendemos de 9 a 19 h.

Tú: ¿cuánto cuesta el corte?
Agente: Corte 250 pesos. Con barba, 350.

Tú: ¿aceptan tarjeta?
Agente: Sí, y transferencia o efectivo.

Eso es todo lo que hace, y es exactamente lo que quieres ver antes que un cliente: si aquí se inventa un precio, en WhatsApp se lo inventa igual.

Prueba 2 — que el servidor levante

La segunda prueba no habla con nadie. Solo comprueba que el programa arranca y que puede decirte cómo se siente. Deja esta terminal corriendo: mientras el comando esté vivo, el servidor está de pie.

Ahora abre otra terminal —la primera quedó ocupada— y pregúntale a tu agente cómo está. Eso es el chequeo de salud:

Los tres estados, y dónde está el detalle de cada uno

Ese comando devuelve una línea de texto con un campo llamado «status». Tiene tres valores posibles, y cada uno se arregla en un lugar distinto. Esta es la tabla que vas a volver a mirar cuando ya esté en internet:

si arrancó (ok o degradado):
{"status":"degradado",
 "service":"agentkit",
 "proveedor":"ProveedorZernio",
 "conexion":{"ok":false,"detalle":"..."}}

si no pudo ni armar el proveedor:
{"status":"error",
 "service":"agentkit",
 "detalle":"<el error>"}

Por eso la tercera columna de la tabla: el detalle de «degradado» viene metido dentro de conexion, y el de «error» va suelto arriba del todo. Si buscas en el lugar equivocado, parece que no dice nada.

Si no te gusta cómo contesta

Nada de esto se arregla tocando código. Le dices a Claude Code qué te chirría —que se alarga, que saluda raro, que no menciona el horario— y él ajusta config/prompts.yaml, que es donde vive la personalidad de tu agente.

Qué se puede cambiar, hasta dónde, y qué cosas no se arreglan con el prompt está en cambiarle cosas, y el límite real.

Prueba mi agente en mi computadora y tradúceme el resultado.

CONTEXTO:
- Estoy en la carpeta del kit. La entrevista ya corrió: existen agent/, config/, tests/ y mi .env.
- No hay webhook ni servidor público: esto es local.
- Yo no leo Python. Explícame en español y sin jerga.

OBJETIVO:
Que las dos pruebas locales pasen y que yo entienda el resultado.

QUÉ HACER, EN ESTE ORDEN:
1. Corre `python tests/test_local.py` y mándale tres mensajes como si fueras un cliente mío.
2. Levanta el servidor con `uvicorn agent.main:app --reload --port 8000`.
3. En otra terminal corre `curl http://localhost:8000/` y léeme el campo "status", no el código HTTP.
4. Traduce ese campo con esta regla, exacta:
- "ok": arrancó y las credenciales del proveedor respondieron.
- "degradado": el proveedor no contestó bien. Lee conexion.detalle, dime qué variable falta o qué credencial rechazaron, y corrígela.
- "error": no pudo ni armar el proveedor. Lee detalle en la raíz y revisa WHATSAPP_PROVIDER: va zernio o meta, en minúsculas.
5. Si no dio "ok", arréglalo y repite desde el paso 2 hasta que diga "ok".

RESTRICCIONES DURAS:
- NO me digas "responde 200, todo bien": este servidor contesta 200 a propósito aunque las credenciales estén mal. Vale el campo "status".
- NO toques config/prompts.yaml sin preguntarme antes.
- NO cambies el modelo para ahorrar: esa decisión es mía.
- NO borres ni reescribas mi .env.

CRITERIO DE ACEPTACIÓN, compruébalo tú:
- `python tests/test_local.py` sostiene una charla de tres turnos.
- `curl http://localhost:8000/` devuelve "status":"ok".
Si falla alguno, arréglalo y vuelve a comprobar antes de decirme que terminaste.

QUÉ REPORTAR AL FINAL:
La conversación completa, el "status" que salió, qué significa, y qué tocaste.

Tu agente ya contesta en tu computadora. Para que conteste cuando tu computadora está apagada tiene que vivir en un servidor, y el camino a ese servidor pasa por un repositorio tuyo en GitHub. Son dos pasos y los dos tienen trampa: el primero te va a fallar con un error que parece grave y no lo es, y el segundo no falla — que es peor, porque sube un repositorio incompleto sin decirte nada.

Ninguno de los dos pide entender git. Piden saber que existen.

$ git remote add origin https://github.com/TU-USUARIO/mi-agente.git
error: remote origin already exists.

No rompiste nada. Git te está avisando que ese nombre ya está ocupado por el repositorio ajeno. Se suelta el heredado, se pone el tuyo, y sigues. Lo que nunca va aquí es git init.

Los tres pasos, en orden

El segundo paso: el .gitignore del kit deja fuera justo lo que hay que subir

El kit es un repositorio público de plantilla y su .gitignore está escrito para mantenerlo limpio: excluye agent/, config/, tests/, requirements.txt, Dockerfile y docker-compose.yml. Allá tiene sentido, porque esos archivos no están en GitHub a propósito: los escribe Claude Code en tu máquina durante la entrevista.

En tu repositorio pasa exactamente al revés: eso es lo que el servidor necesita para construir tu agente. Si empujas sin tocarlo, subes un repositorio sin agente y el servidor construye la nada. El error que te sale después habla del build, no del .gitignore, y ahí se va la tarde.

Los tres comandos que te tocan a ti

El primero suelta el repositorio ajeno, el segundo apunta al tuyo y el tercero comprueba que los archivos del agente van a subir de verdad. En el segundo cambias TU-USUARIO y el nombre del repositorio por los tuyos.

git remote remove origin
git remote add origin https://github.com/TU-USUARIO/mi-agente.git
git add .
git commit -m "feat: mi agente de WhatsApp"
git branch -M main
git push -u origin main

Esa secuencia está aquí para que reconozcas lo que pasa en pantalla, no para que la escribas: el prompt del final la corre por ti y se detiene si algo no cuadra.

Cómo compruebas que quedó bien sin entender git

git ls-files lista los archivos que el repositorio va a subir. No hace falta leerla entera: son tres cosas.

Si .env alcanzó a subir, borrarlo del repositorio no alcanza: quedó en el historial. Genera una llave nueva de Anthropic y otra de tu proveedor, jubila las viejas y cámbialas en tu .env.

Quiero subir mi agente a MI repositorio de GitHub. Hazlo tú de punta a punta.

CONTEXTO, y esto es lo importante:
- Estoy parado DENTRO del clon del repo público de AgentKit. Ya hay un repositorio de git aquí y su remote "origin" apunta al repo de otra persona. Por eso `git init` no aplica y `git remote add origin` va a fallar con "remote origin already exists".
- El .gitignore de este clon excluye a propósito agent/, config/, tests/, requirements.txt, Dockerfile y docker-compose.yml. Eso es exactamente lo que yo sí necesito subir: si no lo cambias, mi repo queda vacío y el despliegue construye la nada.
- Mi repositorio vacío, ya creado en GitHub sin README y sin .gitignore: [PEGA AQUÍ la URL, por ejemplo https://github.com/mi-usuario/mi-agente.git]

OBJETIVO:
Que mi repositorio tenga el agente completo y NO tenga ningún secreto.

QUÉ HACER, EN ESTE ORDEN:
1. Reemplaza el .gitignore por uno de producción que siga ignorando .env, *.db, __pycache__/, .venv/, knowledge/* salvo knowledge/.gitkeep y config/session.yaml — y que YA NO ignore agent/, config/, tests/, requirements.txt, Dockerfile ni docker-compose.yml.
2. Suelta el remote heredado con `git remote remove origin`.
3. Agrega el mío con `git remote add origin` y la URL que te di.
4. `git add .`, commit "feat: mi agente de WhatsApp", `git branch -M main`, `git push -u origin main`.
5. Si el push falla por autenticación, dime en español qué me pide GitHub. No inventes credenciales ni tokens.

RESTRICCIONES DURAS:
- NUNCA ejecutes `git init` en esta carpeta.
- NUNCA hagas `rm -rf .git` sin pedirme permiso y explicarme que eso borra el historial sin vuelta atrás.
- El archivo .env NO puede entrar al commit bajo ninguna circunstancia.
- NO subas nada de knowledge/ salvo el .gitkeep: son datos de mi negocio.
- NO empujes a un repositorio que no sea el que te di.

CRITERIO DE ACEPTACIÓN, compruébalo tú antes de decirme que terminaste:
- `git remote -v` muestra SOLO mi URL.
- `git ls-files | grep -E "^agent/main\.py$"` devuelve una línea.
- `git ls-files | grep -E "^Dockerfile$"` devuelve una línea.
- `git ls-files | grep -c "^\.env$"` devuelve 0.
Si alguno falla, arréglalo y vuelve a comprobar. No me reportes éxito con un criterio en rojo.

QUÉ REPORTAR AL FINAL:
La URL de mi repositorio, cuántos archivos subieron, la confirmación explícita de que .env NO está en el repositorio, y el resultado de cada criterio de arriba en una línea cada uno.

Railway toma tu repositorio, construye la imagen a partir del Dockerfile en sus servidores y deja tu agente corriendo en una dirección pública. Docker no hace falta en tu computadora: lo único que tiene que estar bien es lo que subiste.

Son seis pasos y el orden importa en uno solo: la base de datos va antes que las variables, porque una de las variables es una referencia a la base y no puedes referenciar algo que todavía no existe.

Los seis pasos, en orden

Las seis variables del despliegue

Estas son las que necesita tu agente para funcionar allá arriba. Las de tu .env local no viajan solas: el archivo .env se queda en tu computadora a propósito, y aquí se escriben a mano una por una.

claude-sonnet-5

production

${{Postgres.DATABASE_URL}}

Las tres que muerden

Cambia tu-app por el dominio que te dio Railway. Si en vez de ok te contesta degradado o error, no lo adivines: el diagnóstico se lee igual que en local, y ahí está qué significa cada estado y en qué campo viene el detalle.

Voy a subir mi agente a Railway. Prepara tú el repositorio y después díctame los clics con el nombre de cada botón.

CONTEXTO:
- Mi agente ya está en MI repositorio de GitHub y corre en local.
- Railway construye la imagen en sus servidores. No tengo Docker instalado.
- Railway inyecta la variable PORT.
- Mi repositorio: [PEGA AQUÍ la URL de tu repositorio]

OBJETIVO:
Que mi agente corra en una dirección pública de Railway, con PostgreSQL conectado y el chequeo de salud contestando "ok".

QUÉ HACER, EN ESTE ORDEN:
1. Antes de que yo abra Railway, revisa mi repositorio:
- que el CMD del Dockerfile use ${PORT:-8000} en forma shell y no un 8000 fijo;
- que requirements.txt diga sqlalchemy[asyncio]>=2.0.52 y traiga asyncpg>=0.31.0;
- que .env NO esté subido: `git ls-files | grep -c "^\.env$"`.
2. Si corregiste algo, haz commit y push a main.
3. Dicta los clics, uno por línea, con el nombre literal del botón: crear el proyecto, agregar PostgreSQL ANTES que las variables, cargarlas en MI servicio, generar el dominio y verificar.
4. Dame la lista de variables, una por línea, con su valor. Los pego yo en Railway.
5. Cuando te avise que terminé, corre tú el curl a mi dirección y dime qué contestó.

RESTRICCIONES DURAS:
- NO agregues ni me hagas agregar una variable PORT.
- NO escribas la cadena de conexión de PostgreSQL a mano: en DATABASE_URL va la referencia ${{Postgres.DATABASE_URL}}, tal cual.
- NO me dejes saltarme PostgreSQL "por ahora".
- NO copies valores de mi .env dentro de ningún archivo del repo.
- NO me pidas que instale Docker.

CRITERIO DE ACEPTACIÓN, compruébalo tú:
- `curl https://<mi-dominio>/` devuelve "status":"ok".
- En la lista de variables que me diste no aparece PORT.
- DATABASE_URL es la referencia con llaves dobles, no una cadena postgresql:// a mano.

QUÉ REPORTAR AL FINAL:
Qué tocaste en el repositorio y por qué, la lista de variables como quedó, mi dirección pública y el curl en una línea.

Hasta aquí llegan los clics de este proyecto. Ponerle tu propio dominio, tener un entorno de pruebas aparte del que ven tus clientes, cambiar variables por entorno, deshacer un despliegue que salió mal o dejar que cada push se publique solo es otro tema y tiene su guía: All Deploy. Ahí está eso, y lo mismo cuando el destino no es Railway.

Un webhook es la dirección a la que tu proveedor toca el timbre cuando entra un mensaje. Nada más que eso. Tu agente ya está en internet y ya sabe contestar, pero todavía no hay nadie que le avise: el mensaje llega al proveedor y ahí se queda.

Por eso este paso va al final y no antes: hace falta la URL pública, la que quedó cuando generaste el dominio. La que se pega en el panel es esa misma con /webhook al final, y ese pedacito es de los que se olvidan: sin él el aviso llega a la raíz, que solo sabe decir si tu agente está vivo.

Con Zernio, clic por clic

Cinco clics en el panel donde ya sacaste la llave. Ten a mano la URL de tu servicio y el secreto que inventaste.

Estos nombres de pantalla salen de la documentación del propio kit. Si en tu panel alguna etiqueta se llama distinto, el orden es el mismo: crear el webhook, pegar la URL, poner el secreto, marcar el evento.

Con Meta, clic por clic

El mismo trámite en la consola de desarrolladores, con un nombre distinto para cada cosa.

Si el verify token no coincide, tu servidor responde 403 a propósito. Contestarle 200 le haría creer a Meta que la URL quedó verificada sin estarlo, y después no llegaría ni un mensaje.

Qué hace tu agente con cada aviso, y por qué

El aviso no se atiende de frente. Pasa por dos filtros antes de que nadie lea el mensaje, y la respuesta al proveedor sale antes que la respuesta al cliente. Cada una de las tres decisiones tapa una falla distinta.

Cómo se ve cuando ya quedó

Que el alta se haya guardado no prueba nada. Esto sí: le escribes al número de tu agente desde tu propio celular y las tres cosas pasan una detrás de otra.

tú, desde tu celular
  →  Hola, ¿a qué hora abren?

el registro del servidor
  →  POST /webhook 200 · mensaje recibido

tu agente, en WhatsApp
  →  Abrimos de lunes a sábado, de 9 a 19.

Da de alta el webhook de mi agente y no me digas que terminaste hasta que me llegue una respuesta al celular.

CONTEXTO:
- Mi agente ya está desplegado. Su URL pública es: [PEGA AQUÍ la URL, por ejemplo https://mi-app.up.railway.app]
- Mi proveedor es [ESCRIBE AQUÍ: zernio o meta].
- El secreto del webhook ya está cargado en las variables de mi servicio: ZERNIO_WEBHOOK_SECRET con Zernio, META_VERIFY_TOKEN y META_APP_SECRET con Meta.

OBJETIVO:
Que yo escriba desde mi celular y me conteste mi agente.

QUÉ HACER, EN ESTE ORDEN:
1. Primero `curl <mi URL>/` y dime qué dice "status". Si dice "degradado" o "error", PÁRATE AHÍ y dime qué variable corregir: dar de alta un webhook contra un agente que no puede responder no sirve de nada.
2. Si dice "ok", dicta los clics de mi panel uno por línea, con la URL exacta que tengo que pegar: la mía con /webhook al final.
3. Recuérdame que el secreto del panel tiene que ser el mismo texto exacto que la variable del servidor.
4. Con Zernio: evento message.received, guardar, botón Send test, y dime qué código tiene que contestar mi servidor. Con Meta: suscribirme al campo messages y guardar.
5. Pídeme que le escriba al número desde mi celular y espera a que yo te diga qué pasó.

RESTRICCIONES DURAS:
- NO me digas que deje el secreto vacío "para probar".
- NO des de alta el webhook contra localhost ni contra una URL de prueba.
- NO me digas que quedó listo porque el alta se guardó. Solo cuenta si llegó la respuesta a mi celular.

CRITERIO DE ACEPTACIÓN, compruébalo tú:
- `curl <mi URL>/` devuelve "status":"ok".
- Yo te confirmo que escribí desde el celular y llegó la respuesta.

QUÉ REPORTAR AL FINAL:
La URL que quedó dada de alta, el evento o campo al que me suscribí, y si llegó la respuesta al celular.

Y una cosa que se resuelve sola: tu agente siempre le contesta a quien le escribió, así que nunca sale de la ventana de 24 horas que impone WhatsApp — de qué va esa ventana, en la sección donde eliges proveedor.

Esta sección es una tabla de búsqueda, no una lectura. Cuando algo deja de funcionar, el orden que ahorra horas es siempre el mismo: primero le preguntas a tu agente cómo está, y solo después buscas tu síntoma en las fichas de abajo.

Ninguna de estas dieciocho fallas llega con un aviso claro. Casi todas se ven como silencio: el número no contesta, la respuesta no sale, el historial desapareció. Por eso cada ficha empieza por lo que ves en pantalla, no por la causa.

Las dieciocho fallas de este kit

Busca por la primera línea de cada ficha: es exactamente lo que estás viendo. La causa y el arreglo vienen debajo, en ese orden.

La segunda herramienta: los registros

En desarrollo tu agente escribe su propio detalle en los registros y deja fuera el ruido de las librerías, a propósito: ahí se lee lo que hizo tu agente con tu mensaje, no lo que hizo Python por debajo.

Mi agente de WhatsApp no hace lo que debería. Diagnostícalo tú, en orden, sin que yo lea registros.

CONTEXTO:
- Mi agente está desplegado y su URL pública es [PEGA AQUÍ https://tu-app.up.railway.app]
- Mi proveedor es [ESCRIBE AQUÍ: zernio o meta].
- Lo que yo veo es [ESCRIBE AQUÍ el síntoma, con tus palabras].
- No programo. Resuélvelo tú y explícame en español.

OBJETIVO:
Encontrar la causa, arreglarla y dejarme una sola cosa por hacer.

QUÉ HACER, EN ESTE ORDEN:
1. curl a la raíz y clasifica el status. "error": la causa es WHATSAPP_PROVIDER, en detalle, para ahí. "degradado": está en conexion.detalle, para ahí. "ok": sigue bajando.
2. No llega nada: revisa el alta del webhook, la URL terminada en /webhook y el evento message.received marcado.
3. Llega y no sale respuesta: credenciales de envío del proveedor y si ZERNIO_BASE_URL quedó declarada y vacía.
4. Contesta varias veces: que devuelva 2xx antes de trabajar y descarte por id los avisos repetidos.
5. Se olvida de conversaciones viejas: DATABASE_URL.
6. Inventa precios: config/prompts.yaml y knowledge/.
7. Cambié una variable en Railway y no pasó nada: staged changes.

RESTRICCIONES DURAS:
- NO me digas "responde 200, está todo bien": responde 200 aun degradado, a propósito.
- NO cambies el modelo ni el prompt a ver si así funciona.
- NO borres la base de datos ni el archivo .env.
- NO me digas que los duplicados se quitan borrando webhooks: el aviso repetido ya se descarta por su id. Lo que sí los provoca es no contestar 2xx en cinco segundos.
- NO me reportes una causa sin comprobar los pasos anteriores.

CRITERIO DE ACEPTACIÓN, compruébalo tú:
- curl a la raíz devuelve "status":"ok".
- Le escribo al número y llega una sola respuesta.

QUÉ REPORTAR AL FINAL:
Tres cosas y nada más: cuál era la causa, qué cambiaste tú, y qué tengo que hacer yo.

Si tu síntoma es de Railway y lo que te falta es el camino del menú, los clics están en la sección 11; si es el alta del webhook, en la 12. Y si lo que cambiaste fue un archivo y no una variable, el push que lo pone en línea está en personalizarlo después. Aquí van los síntomas, no el paso a paso.

Tu agente no queda congelado el día que lo pones en línea. Cambiarle el tono, enseñarle un precio nuevo o contarle de un servicio que acabas de abrir es cuestión de minutos, y no se toca código: se tocan dos archivos de texto.

Lo que sí cuesta trabajo es otra cosa, y conviene saberla antes de prometérsela a un cliente.

Lo fácil, que de verdad es fácil

Abres la carpeta de tu agente en la terminal, arrancas Claude Code y se lo pides en español, con tus palabras. Estas tres cosas entran por ahí:

• El tono: que salude más corto, que hable de tú, que deje de usar signos de admiración.
• Información nueva: un precio que subió, el horario de los sábados, un servicio que acabas de abrir.
• Lo que no debe decir: que no prometa tiempos de entrega, que no negocie descuentos, que no opine de la competencia.

Todo eso vive en config/prompts.yaml, que es la personalidad, y en config/business.yaml, que son los datos de tu negocio. Son dos archivos de texto: pídele a Claude Code que los edite y que te diga en español qué cambió.

Entonces por qué sí se sabe tu menú

Porque la información de tu negocio no le llega por herramientas: le llega por el prompt del sistema, que se arma con config/prompts.yaml, config/business.yaml y lo que dejaste en knowledge/. El agente lo lee completo en cada turno, y por eso contesta precios, horarios y condiciones sin ejecutar nada.

La frontera es esa: para contestar no hace falta nada de tools.py; hace falta para hacer. Conversar, entender y dejar los datos en el historial ya lo hace hoy. Agendar, cobrar o apartar stock no, hasta que alguien lo cablee.

Qué cuesta cada cambio

La misma pregunta contestada por columnas: dónde se toca, y cuánto trabajo es de verdad.

Los tres prompts para pegar

Quiero que una función de agent/tools.py se ejecute de verdad. Hazlo tú de punta a punta.

CONTEXTO:
- Mi agente ya corre y contesta por WhatsApp.
- agent/tools.py existe, con sus funciones ya escritas. Que yo sepa, ningún módulo lo importa y ninguna llamada a la API lleva tools=, así que hoy no se ejecuta ninguna.
- La acción que quiero que ejecute:
[ESCRIBE AQUÍ: por ejemplo, reservar una cita]
- El sistema donde tiene que quedar registrada:
[ESCRIBE AQUÍ: por ejemplo, mi calendario de Google]

OBJETIVO:
Que esa acción quede hecha en el otro sistema cuando un cliente la pide por WhatsApp, y que el agente solo la confirme si quedó hecha.

QUÉ HACER, EN ESTE ORDEN:
1. Revisa agent/ y confírmame, con archivo y línea, que hoy nadie importa tools.py y que ninguna llamada lleva tools=. Si ya estaba cableado, dímelo y no toques nada.
2. Escribe la función en agent/tools.py y atrapa sus errores.
3. Decláramela como herramienta, con su esquema de entrada.
4. Implementa el ciclo completo: manda las herramientas en la llamada, ejecuta la que el modelo pida, devuélvele el resultado y deja que redacte la respuesta final.
5. Escribe una prueba en tests/ que FALLE si la función no se llama.
6. Ajusta config/prompts.yaml para que el agente nunca confirme algo que la herramienta no devolvió como hecho.

RESTRICCIONES DURAS:
- Si la herramienta devuelve error, el agente NO confirma nada: dice que hubo un problema y ofrece pasar con una persona.
- NUNCA inventes datos que salen del otro sistema: horarios, folios, precios o disponibilidad.
- NINGUNA credencial en el código. Todas por variable de entorno.
- NO conectes contra mi sistema de producción sin avisarme antes.
- NO toques la verificación de firma, la deduplicación por id, ni el hecho de que el servidor contesta 200 antes de ponerse a trabajar. Si rompes eso, el proveedor reintenta hasta siete veces y mis clientes reciben la misma respuesta siete veces.

CRITERIO DE ACEPTACIÓN, compruébalo tú:
- La prueba nueva pasa, y vuelve a fallar si desconectas la llamada.
- python tests/test_local.py pasa.
- curl http://localhost:8000/ contesta "status":"ok".
- Un error simulado del otro sistema termina sin confirmación.

QUÉ REPORTAR AL FINAL:
Qué archivos tocaste, cómo se llama la herramienta, qué contesta si falla, y el resultado de cada criterio en una línea.

El que sigue es para otra cosa, y hay quien no lo abre nunca: cambiar de proveedor. Como en la entrevista se generó solo el adaptador del que elegiste, pasar de Zernio a Meta —o al revés— es escribir el otro desde cero. Guárdalo para el día que te mudes.

Quiero cambiar de proveedor de WhatsApp. Hazlo tú de punta a punta.

CONTEXTO:
- Mi agente ya corre. El proveedor que uso hoy:
[ESCRIBE AQUÍ: zernio o meta]
- El proveedor al que me quiero pasar:
[ESCRIBE AQUÍ: zernio o meta]
- En la entrevista se generó SOLO el adaptador del que elegí; el del proveedor nuevo no existe todavía.
- Esto cambia por dónde entran y salen los mensajes, no lo que mi agente dice ni lo que ya conversó.

OBJETIVO:
Que el agente reciba y responda por el proveedor nuevo sin perder una sola conversación ni una línea de mi prompt.

QUÉ HACER, EN ESTE ORDEN:
1. Lee el adaptador que ya existe y anota su interfaz: qué métodos expone, qué recibe y qué devuelve.
2. Escribe el adaptador nuevo con esa MISMA interfaz. El resto del agente no se debe enterar del cambio.
3. Pídeme las credenciales del proveedor nuevo UNA POR UNA, diciéndome de qué pantalla sale cada una, y escríbelas en el .env.
4. Cambia WHATSAPP_PROVIDER al valor nuevo, en minúsculas.
5. Cuando el nuevo ya esté probado, borra el adaptador viejo y sus variables del .env.
6. Explícame en español qué cambia al dar de alta el webhook: la URL sigue terminando en /webhook, pero la firma viaja distinto. En Zernio llega en el encabezado X-Zernio-Signature, con el hex en minúsculas. En Meta llega en X-Hub-Signature-256, con el prefijo sha256= por delante.

RESTRICCIONES DURAS:
- NO toques config/prompts.yaml, config/business.yaml ni knowledge/.
- NO borres la base de datos ni el historial de conversaciones.
- NO dejes los dos adaptadores activos al mismo tiempo.
- NO des de baja el webhook viejo hasta que el nuevo esté probado con un mensaje real.
- NINGUNA credencial en el código.

CRITERIO DE ACEPTACIÓN, compruébalo tú:
- curl http://localhost:8000/ contesta "status":"ok".
- git ls-files | grep -c "^\.env$" devuelve 0.
- config/prompts.yaml y config/business.yaml quedaron sin cambios.

QUÉ REPORTAR AL FINAL:
Qué proveedor quedó activo, qué archivos creaste y borraste, los pasos que me tocan a mí en el panel del proveedor nuevo, y el resultado de cada criterio en una línea.

El último es el de todos los días. Cada vez que suba un precio, abras los sábados o quieras que salude más corto, es este el que copias, y no hace falta tocar nada de lo anterior.

Quiero cambiarle el tono a mi agente y enseñarle lo que le falta. Hazlo tú.

CONTEXTO:
- Mi agente ya corre. Su personalidad vive en config/prompts.yaml y los datos de mi negocio en config/business.yaml.
- Lo que guardo en knowledge/ se incorpora al prompt del sistema.
- El tono que quiero:
[ESCRIBE AQUÍ: por ejemplo, más corto, de tú y sin tanto adorno]
- Lo que hoy no sabe y debería saber:
[ESCRIBE AQUÍ: por ejemplo, la lista de precios nueva y el horario de los sábados]

OBJETIVO:
Que conteste con mi tono y con mis datos nuevos, y que siga diciendo que no sabe cuando no sabe.

QUÉ HACER, EN ESTE ORDEN:
1. Ajusta el tono en config/prompts.yaml y los datos fijos en config/business.yaml.
2. Guarda los precios y los horarios como texto plano en knowledge/, un archivo por tema, e incorpóralos LITERALES al prompt: precios, horarios y condiciones no se resumen ni se redondean.
3. Deja escrita la regla de que, si no sabe algo, lo dice y ofrece pasar con una persona en vez de aproximar.
4. Corre tres pruebas y muéstrame las respuestas completas: una pregunta sobre el dato nuevo, una que le intente sacar un descuento, y una sobre algo que el agente no sabe.

RESTRICCIONES DURAS:
- NO subas nada de knowledge/ a GitHub: son datos de mi negocio.
- NO resumas ni redondees precios, horarios ni condiciones.
- NO inventes un dato que no esté en knowledge/ ni en config/.
- NO toques agent/ ni el .env.

CRITERIO DE ACEPTACIÓN, compruébalo tú:
- git check-ignore imprime la ruta de cada archivo de knowledge/.
- git ls-files knowledge/ muestra solo knowledge/.gitkeep.
- python tests/test_local.py pasa.
- En la prueba del descuento el agente no concede ninguno.

QUÉ REPORTAR AL FINAL:
Qué archivos tocaste, qué guardaste en knowledge/, las tres respuestas de prueba tal cual salieron, y el resultado de cada criterio en una línea.

Y si al final resulta que lo que necesitas es que además califique al cliente, agende y escriba en tu CRM, no lo cablees pieza por pieza: eso ya está resuelto en el AgentKit que cierra ventas.

Cada número de aquí abajo va con el día en que se consultó, y eso no es un adorno: estos precios se mueven, y el que más rápido se mueve es el de Meta. Si estás leyendo esto meses después, la fila de Meta es la primera que tienes que volver a mirar.

Las tarifas de Anthropic y los planes de Railway se verificaron el 17 de septiembre de 2026. Lo de WhatsApp con Meta trae una fecha más vieja, de agosto, porque esa es la fuente que hay.

Lo que te van a cobrar, pieza por pieza

Ninguna de estas filas se inventó aquí: cada una es lo que decía la página de precios del proveedor el día de la tercera columna. Vuelve a comprobarlas antes de presupuestarle a un cliente.

Una línea sobre la ventana de 24 horas, porque es la que hace barata la parte de WhatsApp: mientras el cliente escriba primero y tú contestes dentro de ese día, hoy Meta no cobra esa respuesta, y este agente siempre responde. Cómo funciona y por qué casi nunca sales de ella está donde eliges proveedor.

El único número que puedes bajar tú mismo

El modelo lo eliges con la variable ANTHROPIC_MODEL y se cambia sin tocar nada más. Sonnet 5 es el que viene puesto:

La columna de la derecha no es una tarifa, es una cuenta: el volumen que trae el kit son 8 idas y vueltas, un prompt del sistema de unos 1.500 tokens, cerca de 16.000 tokens de entrada y 1.200 de salida. Ese volumen se midió contra el repo el 19 de agosto de 2026 y las tarifas el 17 de septiembre de 2026. Si tu prompt es más largo, tu número es más alto.

Doce preguntas que llegan cuando el agente ya está corriendo. Las que tienen dueño en otra sección se contestan en dos líneas y te mandan ahí.

Montar un segundo agente sin tocar el primero

Un negocio, un clon. El riesgo no es clonar: es que los dos terminen apuntando al mismo lado y se pisen.

Quiero montar un SEGUNDO agente de WhatsApp para otro negocio sin tocar el que ya tengo. Hazlo tú.

CONTEXTO:
- Ya tengo un agente hecho con whatsapp-agentkit en esta carpeta, y no se toca.
- El segundo sale de un clon aparte del mismo repositorio público: https://github.com/Hainrixz/whatsapp-agentkit.git
- La carpeta nueva va al mismo nivel que esta, no adentro: [ESCRIBE AQUÍ: el nombre, por ejemplo mi-agente-2]

OBJETIVO:
Dejar el segundo clon listo para su entrevista, con el primero intacto.

QUÉ HACER, EN ESTE ORDEN:
1. Sal de esta carpeta y clona el repositorio en la nueva.
2. En la carpeta nueva corre bash start.sh y dime qué verificó: Python 3.11 o superior, que claude esté en el PATH, la carpeta knowledge y la copia de .env.example a .env.
3. Comprueba que la carpeta del primer agente no cambió y dímelo.
4. Hazme la lista de lo que tiene que ser distinto entre los dos: número de WhatsApp, secreto del webhook, repositorio de GitHub, servicio de despliegue y base de datos.

RESTRICCIONES DURAS:
- NO modifiques ningún archivo del primer agente.
- NO copies el .env del primero al segundo.
- NO reutilices el webhook, el secreto ni la base de datos del primero: dos instancias contra la misma base le contestan dos veces a la misma persona.
- NO corras /build-agent todavía. Esto solo deja la carpeta lista.

CRITERIO DE ACEPTACIÓN, compruébalo tú:
- La carpeta nueva existe y es hermana de esta, no está dentro.
- Dentro de ella hay CLAUDE.md, start.sh, .env y la carpeta knowledge.
- git status en la carpeta del primer agente no muestra cambios.
Si alguno falla, arréglalo y vuelve a comprobar.

QUÉ REPORTAR AL FINAL:
La ruta de la carpeta nueva, qué verificó start.sh, la confirmación de que el primer agente no fue tocado, y la lista del punto 4.

Revisar el kit con su propio auditor

El kit trae un script que se revisa a sí mismo: seis chequeos sobre el repositorio. Sirve cuando algo no cuadra y quieres descartar que el problema venga de ahí.

Corre el auditor del kit y explícame el resultado en español. No arregles nada.

CONTEXTO:
- Estoy dentro del clon de whatsapp-agentkit y no programo: la salida de ese script en crudo no me dice nada.
- El script es scripts/audit.py y hace seis chequeos sobre el kit. Sale con código 1 si alguno falla.
- El chequeo de enlaces necesita conexión y se puede saltar con la bandera --skip-links.

OBJETIVO:
Saber si el kit está sano y, si no lo está, qué es lo que falla.

QUÉ HACER, EN ESTE ORDEN:
1. Corre python3 scripts/audit.py.
2. Si falla por conexión o se queda colgado en los enlaces, vuelve a correrlo con python3 scripts/audit.py --skip-links y avísame que ese chequeo quedó sin correr.
3. Tradúceme los seis chequeos, uno por línea, con pasó o falló: que compilen los bloques de código de CLAUDE.md, que el YAML se entienda, que no queden rastros de los proveedores retirados, que toda variable de entorno usada esté documentada en .env.example, que los enlaces del README respondan, y que las imágenes existan y midan al menos 600 px de ancho.
4. Si alguno falló, dime en una línea qué significa eso para mí.

RESTRICCIONES DURAS:
- NO arregles nada. Esto es un diagnóstico, no una reparación.
- NO instales dependencias sin avisarme. La única excepción es pyyaml si el script se queja de que falta: pídemelo y espera mi sí.
- NO subas nada a GitHub ni hagas ningún commit.

CRITERIO DE ACEPTACIÓN, compruébalo tú:
- Me diste los seis chequeos, cada uno con pasó o falló.
- Si usaste --skip-links, lo dijiste explícitamente.
- git status muestra lo mismo que antes de correr el script.

QUÉ REPORTAR AL FINAL:
Con qué código salió el script, los seis chequeos traducidos uno por línea, y qué tengo que hacer yo, si es que hay algo.

Si tu pregunta es un síntoma concreto —dice degradado, no llega nada, el agente se olvida de todo—, está en la tabla de la sección 13, con su causa y su arreglo.