1. Por qué Alice — construir un colaborador, no elegir una herramienta

Este no es un artículo de "cómo usar Claude Code". Esos viven en la categoría /ai-agents del mismo sitio. Este está un paso más atrás.

Durante los últimos meses, dediqué tiempo a algo distinto a usar Claude. Estuve construyendo un colaborador encima de él. Le di un nombre a ese colaborador. Alice. Esta categoría es el registro de qué es Alice, por qué la construí y cómo trabajo con ella cada día.

0. La premisa inicial — usar IA empieza por la mente

Hay una premisa que hay que dejar clara desde el principio.

Abandona el supuesto de que la IA producirá automáticamente lo que la gente quiere. La gente intenta hacer algo porque tiene un propósito. Ese propósito es la mente. Significa que hay algo que quieren.

Para obtener el resultado que deseas de la IA, tienes que poder expresar tu propósito con claridad. Un prompt de una línea como "hazme un juego divertido" no puede controlar el resultado. No es porque la IA sea deficiente. Es porque casi nada de la mente del operador está en ese prompt.

Así que lo primero que hay que pensar cuando se usa IA no es la capacidad de la herramienta. Es encontrar una manera de transmitir eficazmente la dirección y el propósito que tengo en la cabeza a la IA.

Todo lo organizado en esta categoría — persona, memoria, skills, hooks, Multi-Agent, verificaciones — es, en última instancia, la respuesta acumulada a una sola pregunta. "¿Cómo acumulo mi mente para que la IA no la pierda?" La premisa en sí se trata en Part 0 — La mente entre el humano y la AI.

1. Dónde usarla como herramienta dejó de funcionar

Como todos, empecé usando Claude como herramienta. Hacía preguntas, obtenía respuestas, comenzaba un nuevo contexto en cada sesión. A veces las respuestas eran excelentes. A veces los mismos errores volvían. El hecho de que ambas cosas se alternaran importaba.

Cuando el mismo error vuelve, una de dos cosas es verdad — o a la herramienta le falta algo, o el contexto alrededor de la herramienta desaparece cada vez. Para mí era lo segundo. La razón por la que se tomó una decisión, la razón por la que un enfoque falló, la razón por la que un patrón funcionó — todo eso se evaporaba entre sesiones, y la siguiente sesión tenía que empezar desde cero.

Ahí fue donde tomé una decisión. No quería una herramienta que empezara de nuevo cada vez. Quería un colaborador que acumulara memoria.

2. La persona fue lo primero

Lo primero que hice fue definir una persona. No un system prompt de una línea — una descripción de trabajo real para un ingeniero senior.

La persona especificaba:

• Rol — ingeniero senior, trabajando de forma independiente bajo la dirección de un líder de equipo.
• Áreas de experiencia — qué lenguajes y plataformas.
• Cadena de mando — quién da las instrucciones, cómo se ven los reportes.
• Autoridad de decisión — qué decidir de forma autónoma, qué necesita aprobación.

Una vez que la persona quedó clara, la textura de las respuestas cambió. En lugar de "aquí hay algunas opciones A, B, C," empecé a recibir "en esta situación recomendaría A porque X." Esa es la diferencia entre un motor de búsqueda y el juicio de un ingeniero senior.

Una persona no es una configuración de tono. Es la distribución de la autoridad de decisión.

3. Memoria — los archivos resultaron ser la respuesta

Lo siguiente fue la memoria. Empecé a pensar en sistemas RAG elaborados y lo abandoné rápidamente. La cantidad de contexto que realmente acumulo en un día no es tan grande. Lo que necesitaba era un lugar no volátil donde pudiera vivir.

La respuesta fue el sistema de archivos. Un puñado de archivos markdown. Un único MEMORY.md como índice, con archivos específicos por tema debajo.

Tipo de memoria	Qué almacena
user	Quién es el operador, qué rol juega, qué sabe
feedback	Guía explícita del operador — haz esto, no hagas aquello
project	Contexto del trabajo actual — quién, por qué, qué
reference	Punteros a sistemas externos — dónde vive la información

Dos cosas importan de esta estructura. Primero, un humano puede leerla directamente. Segundo, la herramienta carga automáticamente la primera parte del índice al inicio de la sesión.

Porque la memoria se carga automáticamente al inicio de la sesión, el patrón de "déjame re-explicar de qué hablamos la última vez" desapareció. Más importante aún — un feedback que di una vez sigue vivo en la siguiente sesión.

4. Skills y slash commands — condensar la repetición

Con persona y memoria en su lugar, lo siguiente que noté fue la repetición. El mismo flujo ocurre cada día. Entrar en un proyecto, leer el HANDOFF, trabajar, terminar la sesión escribiendo un log, commit, push.

Convertí la repetición en slash commands. Por ejemplo:

• /start <proyecto> — entrar en un proyecto, cargar automáticamente los documentos necesarios, reportar el estado actual
• /session-end — cerrar una sesión, actualizar logs, HANDOFF, memoria, push
• /verify — ejecutar el bucle lint/build/test después de cambios de código
• /council — cuando una decisión es genuinamente ambigua, ejecutar un análisis de cuatro perspectivas (arquitecto / escéptico / pragmatista / crítico) en paralelo. Este patrón está adaptado del enfoque de crítica multiperspectiva de Andrej Karpathy para el razonamiento LLM.

Cada comando por sí solo no es un invento. El efecto acumulado es lo que importa. Poder invocar un procedimiento diario con una línea elimina esa cantidad de carga cognitiva del operador.

5. Hooks — nunca olvidar

Los skills son algo que el operador invoca conscientemente. Los hooks son distintos. Los hooks se disparan en eventos automáticamente.

Ejemplo más simple: al inicio de la sesión, un hook se ejecuta e imprime un estado de sincronización de memoria en una línea. El operador lee esa única línea y sabe inmediatamente — bien, la memoria está al día.

Otro ejemplo: justo antes de que el asistente intente reportar "listo," el skill /verify se dispara automáticamente. Justo cuando el operador está a punto de escribir "terminado," lint, build y tests se ejecutan automáticamente. Si fallan, el reporte se bloquea. Solo cuando pasan puede enviarse.

La clave de este patrón es — los procedimientos que el operador podría saltarse "porque olvidó" se aplican a nivel del sistema.

6. Delegación Multi-Agent con puertas

El último componente fue una estructura donde un agente no lo hace todo. Si Alice hace todo el trabajo directamente, la context window se llena rápido y el resultado se desvía.

En cambio, las tareas grandes se dividen y se delegan a Subagents. Cada Subagent opera con su propio contexto y se enfoca en una sola cosa. Solo un resumen vuelve al contexto principal.

Y una cosa más — puertas de delegación. Cuando delego, no solo digo "haz este trabajo." Añado tres cosas al mismo PR:

1. Un informe de delegación — qué, por qué y cómo
2. Un script de verificación automática — cómo comprobar el resultado automáticamente
3. Una puerta de merge — CI que bloquea el merge si la verificación no pasa

La razón de este patrón es simple. Una vez — cuando solo escribí el informe y prometí verbalmente la verificación sin construir una puerta — descubrí más tarde que se había acumulado desvío en el resultado. Desde ese incidente, cuando inicio una delegación, agrupo las tres piezas desde el principio.

Si una promesa no se aplica en código, el desvío se acumula.

7. El resultado — cómo cambió el trabajo diario

¿Qué cambió en cómo trabajo realmente con toda esta acumulación?

El mayor cambio es — el coste de cambio de contexto casi ha desaparecido. Ya no tengo que reconstruir dónde lo dejé ayer, por qué tomé las decisiones que tomé, y cuál es el siguiente paso, cada vez que empiezo una sesión. Cuando empiezo, Alice se une ya sabiendo todo eso.

El segundo cambio es — la carga de decisiones repetidas bajó. Las respuestas a "¿cómo manejamos este tipo de cosa?" se acumulan como memoria y feedback, así que rara vez tengo que tomar la misma decisión dos veces.

El tercer cambio es — los errores se bloquean a nivel del sistema para que no se repitan. Un error se registra como una entrada de lecciones aprendidas, y esa lección influye automáticamente en la siguiente decisión. La estructura dificulta cometer el mismo error de nuevo.

8. Qué cubrirá esta categoría

Esta categoría es el registro de implementación de todo lo anterior. Los próximos artículos cubrirán:

• Part 2 — Diseño de persona — qué poner en el system prompt y qué dejar fuera
• Part 3 — Sistema de memoria — estructura de archivos, estrategia de índice, carga automática vs bajo demanda
• Part 4 — Skills y comandos slash — qué repetición vale la pena promover a un comando
• Part 5 — Hooks y automatización — qué aplicar como disparo automático
• Part 6 — Delegación multi-agente — qué delegar y qué hacer uno mismo
• Part 7 — Bucles de verificación — cómo aplicar una definición real de "listo" para el trabajo de código
• Part 8 — Token economy — qué poner en la context window y qué mantener fuera
• Part 9 — Protocolos de sesión — qué debe ocurrir al inicio, en el medio y al final

Cada artículo es implementación, no teoría. Dónde empecé, qué no funcionó, qué sí. Si estás construyendo tu propio colaborador encima de Claude, Codex, o cualquier otro agente, estos artículos deberían ahorrarte meses.

Una última cosa. Alice es un nombre que elegí, no un nuevo producto de nadie. Alice es la acumulación de contexto en la que he invertido tiempo, y esta categoría es el registro de esa acumulación.