Notas sobre sistemas, mercados y cualquier cosa que intento entender.

Hoy advertí una debilidad en mi forma de construir con agentes.

Puedes diseñar el sistema de ingeniería de bucles más limpio. Dividir el proyecto en fases. Asignar un orquestador. Dar a cada agente un papel estrecho. Añadir revisores, controles, registros y criterios de aceptación. Durante un tiempo, la máquina parece casi capaz de corregirse sola.

Pero cerca del final de un proyecto largo, algo cambia.

El orquestador ha acumulado demasiada historia. Las suposiciones antiguas se mezclan con la realidad actual. Los agentes empiezan a validar el relato que han estado construyendo en lugar de validar el sistema real. La jerarquía sigue existiendo sobre el papel, pero su juicio se ha degradado lentamente.

Lo extraño es que esto suele ocurrir cerca de la meta, precisamente cuando la confianza está en su punto más alto y los errores resultan más caros.

Por eso, la puerta de decisión humana no puede tratarse como un freno de emergencia. Tiene que formar parte de la arquitectura.

En los controles finales de cada fase importante, quizá sea necesario reconstruir la jerarquía desde cero: un orquestador nuevo, un contexto limpio, evidencia explícita y ninguna creencia heredada de que el equipo anterior probablemente tenía razón.

Eso es lo que estoy haciendo ahora con Atlas.

La Fase Tres está cerca, pero no voy a permitir que la misma pandilla de cerebros certifique su propio final. Los controles restantes continuarán bajo una nueva batuta.

A veces el paso final no consiste en pedir al sistema que se esfuerce más.

Consiste

He empezado a ver la socialización como una especie de prueba de curiosidad.

¿De verdad quiero conocer a esta persona? No solo saber a qué se dedica, sino cómo piensa, cómo son sus días, qué disfruta y qué le hace sentirse viva.

Durante años, creo que enfoqué de forma equivocada la búsqueda de una pareja. Me concentraba en encontrar a la persona adecuada antes de comprender bien sobre qué debería construirse una relación sana.

Últimamente he comprendido que la base es mucho más sencilla: dos personas que sienten una curiosidad auténtica por el mundo interior de la otra.

Ya puedo ver la diferencia en las personas a las que estoy dejando entrar en mi vida. Cuando ambas partes se acercan a una conexión nueva con curiosidad, en lugar de actuación, presión o expectativas, empieza a formarse algo mucho más equilibrado.

Quizá ese sea el verdadero comienzo de la intimidad. No intentar impresionar a alguien, poseerlo o decidir de inmediato qué papel podría ocupar en tu vida.

Simplemente sentir un interés sincero por quien ya es.

Tener más contexto parece más seguro. Si el modelo dispone de toda la conversación, todos los documentos, todas las decisiones anteriores y todas las herramientas posibles, seguramente tomará una decisión mejor.

Sigo encontrando lo contrario.

Mi definición práctica de la gestión de contexto es decidir qué puede influir en la siguiente decisión. Eso incluye lo que entra, pero la parte más difícil es lo que se queda fuera. Las suposiciones antiguas, las discusiones terminadas y la tarea de otra persona pueden ser correctas y, aun así, ser equivocadas para este momento.

La diferencia se vuelve evidente cuando intervienen varios agentes. Un investigador necesita la pregunta, los archivos relevantes y el estándar de evidencia. La persona que realiza el cambio necesita el plan aceptado, los límites exactos y las pruebas. Un revisor necesita el contrato, el cambio terminado y las condiciones de fallo. Dar a los tres la misma historia gigantesca no los coordina. Hace que cada uno cargue con decisiones que pertenecen a otra persona.

Antes pensaba que el uso de herramientas era la parte impresionante: ¿puede un agente inspeccionar un navegador, leer un repositorio, ejecutar una prueba o entregar trabajo a otro agente? Esas cosas importan, pero no son la arquitectura. La arquitectura es el límite alrededor de la llamada a la herramienta. ¿Qué está decidiendo este agente? ¿Qué está dejando explícitamente fuera de su decisión? ¿Qué estado es el actual? ¿Qué evidencia cierra la tarea?

Un patrón concreto me ha ayudado separar investigación plan e implementación y después

Las personas suelen llegar con una solución ya incluida en la petición.

Un cliente puede pedir cambiar de mesa. Tal vez la mesa no sea el problema real. Podría ser el ruido, la privacidad, la temperatura o la sensación de que una noche importante se está tratando con descuido. Cambiar la mesa puede resolverlo. También puede no acertar en absoluto.

Las peticiones técnicas funcionan de la misma forma. Alguien pide un chatbot, un panel o una automatización. Es información útil, pero todavía no es el requisito. El requisito es el cambio que necesita en su día: menos solicitudes perdidas, una respuesta más rápida, una decisión en la que pueda confiar o una entrega que deje de desaparecer entre personas.

Aquí es donde creo que la hospitalidad, las ventas y el trabajo técnico tocan la misma cosa. La comunicación no es la capa que se añade después de construir el sistema. Forma parte de descubrir qué sistema debería construirse.

La parte difícil es escuchar sin hacer que la persona se sienta corregida. Si explico de inmediato por qué la solución que pidió es equivocada, pierdo información y probablemente confianza. Prefiero preguntar qué ocurrió antes de la petición, cómo sería un buen resultado y qué no puede permitirse que salga mal.

A veces la primera petición es exactamente correcta. Simplemente no quiero asumir que está completa. La frase con la que alguien empieza suele ser la puerta, no la habitación.

Me gusta trabajar con un grupo pequeño, especialmente cuando un objetivo desordenado puede convertirse en unas pocas piezas claras. Lo que no me gusta es el teatro de la jerarquía: comprobaciones constantes, presión vaga o hacer que alguien se sienta pequeño para que el trabajo parezca controlado.

Para mí, la descomposición empieza con cuatro cosas. ¿Qué resultado queremos alcanzar? ¿Qué puede decidir esta persona sin volver a preguntar? ¿Dónde se conecta su parte con la de otra persona? ¿Qué evidencia nos dice que la pieza está terminada?

Suena mecánico, pero la parte humana importa más. Una tarea pesa cuando la responsabilidad no está clara, la razón permanece oculta o los comentarios llegan solo después de que la persona haya avanzado demasiado en la dirección equivocada. La claridad puede reducir la presión. Le dice a alguien dónde tiene espacio para moverse.

También creo que la responsabilidad y la dignidad deberían viajar juntas. Si una persona es dueña de una pieza, debería poder cuestionar la suposición que contiene. De lo contrario, no le he dado responsabilidad. Le he dado instrucciones y les he cambiado el nombre.

El equilibrio sigue siendo difícil. Muy poca dirección convierte la colaboración en adivinación. Demasiada convierte a personas capaces en extensiones de las manos de una sola persona. Quiero dividir el trabajo con suficiente claridad para que nadie esté esperando, pero con suficiente libertad para que una idea mejor todavía pueda venir de quien está más cerca de la tarea.

El mercado estaba abierto y el sistema estaba dedicando su tiempo a prepararse para probar más tarde.

Ese fue el momento en que cambió mi definición de terminado.

Las comprobaciones sin conexión tenían valor. Podían detectar una función rota, un esquema incorrecto o una regresión antes de que el sistema en vivo tocara nada. Pero los fallos que me importaban aparecían solo en el entorno real: la sesión autenticada, el estado actual de la página, los controles de fecha del proveedor y los datos disponibles durante una ventana de mercado estrecha.

El primer proceso trataba cada cambio como una larga ceremonia. Hacer una corrección. Enviarla a revisores nuevos. Programar otra ejecución. Esperar. Repetir. Parecía cuidadoso, pero utilizaba el recurso escaso —el mercado abierto— para esperar y el recurso ilimitado —el tiempo sin conexión— para actuar.

Presioné para cambiar el orden. Mantener los límites de seguridad: un operador en vivo, recopilación de solo lectura, ningún reintento a ciegas, evidencia inmutable y un resultado cerrado de forma segura cuando el estado de la fuente es incorrecto. Después, usar la ventana abierta para obtener evidencia en vivo y acotada. Si una ejecución expone un problema real, diagnosticarlo, hacer la corrección mínima respaldada, pasar las comprobaciones sin conexión enfocadas y volver al mismo recorrido en vivo mientras el entorno todavía existe.

Esto no era un argumento a favor de probar de forma imprudente en producción Era un argumento sobre de dónde puede venir la certeza Un revisor puede confirmar que existe en el código