De una idea a una herramienta que funciona

Herramientas y trabajo — 04

Después de resolver una tarea, encontramos otra del mismo tipo. Los datos cambian, pero una parte de la operación sigue siendo la misma.

Reconocer esa semejanza es fácil. Determinar qué parte de la solución podemos reutilizar resulta más difícil.

Una respuesta correcta en una ocasión todavía no es una herramienta. Para convertirse en una, debe quedar claro qué entradas acepta, qué produce y en qué condiciones puede utilizarse.

Ahí se sitúa la pregunta inicial de a2:

¿Podemos convertir una solución exitosa en una habilidad que pueda probarse y reutilizarse en otras tareas?

Reducir la idea a una tarea pequeña

Esta pregunta podría mantenerse muy amplia. Podemos imaginar un agente que utiliza distintas herramientas, aprende de su historial y aborda cualquier tipo de trabajo.

El foco actual de a2 es más acotado: la transformación de datos.

Normalizar registros, relacionar datos de dos fuentes, separar conflictos y seleccionar los campos necesarios. Estas tareas pueden parecer pequeñas, pero proporcionan una base concreta para examinar el comportamiento de la herramienta.

Pensemos en un ejemplo hipotético. Dos archivos registran los mismos productos de formas diferentes. Uno utiliza códigos de producto y el otro códigos de proveedor. Algunos campos están vacíos y ciertos valores no coinciden.

Podríamos empezar con «combina estos archivos». Pero producir el resultado correcto requiere reglas más claras: ¿qué campo determina una coincidencia? ¿Qué ocurre con los registros sin correspondencia? ¿Cómo se muestran los valores en conflicto?

Al responder estas preguntas, la idea se convierte en una tarea ejecutable.

¿Basta con que el resultado parezca correcto?

La primera solución puede producir un JSON ordenado. Los campos están en su sitio y el archivo se puede leer.

Aun así, el resultado puede ser incorrecto. Puede haberse omitido un registro, combinado dos productos distintos o elegido silenciosamente uno de dos valores contradictorios.

Por eso a2 separa la comprobación del formato de salida de la verificación del resultado de la tarea.

Cuando existe una salida esperada especificada de forma independiente, el resultado generado puede compararse con ella. Sin esa referencia, el informe identifica la comprobación como limitada al esquema. No se presenta como una verificación semántica de la tarea.

La misma distinción se extiende al historial. Una salida inválida no debería guardarse como solución exitosa.

La reutilización debe partir de una solución verificada bajo condiciones concretas, en lugar de una operación que solo parece terminada.

De la solución a una habilidad candidata

Cuando una tarea se resuelve correctamente, puede generarse a partir de esa solución una habilidad candidata ejecutable.

Esta transición es distinta de guardar la respuesta. El objetivo es obtener un componente capaz de realizar la misma operación con entradas nuevas.

En la vía de aprendizaje de datos de a2, el candidato se comprueba externamente con tres tareas nuevas de verificación antes de guardarse de forma persistente. Las respuestas esperadas de verificación no se incluyen en la conversación del modelo.

Si supera las comprobaciones, se guarda con su versión de contrato, procedencia, hash del código y huellas de verificación.

Así conservamos más que «este código funcionó». También conservamos las condiciones y las comprobaciones bajo las que llegó a ser utilizable.

Superar unos ejemplos no demuestra corrección para todas las entradas posibles. El alcance de la habilidad guardada no se amplía automáticamente más allá de los ejemplos y del contrato que la verificaron.

¿Reutilizar significa trabajar mejor?

Producir una habilidad y poder invocarla es un paso importante. Su contribución al trabajo también debe medirse por separado.

En el diseño comparativo de a2, las mismas tareas se abordan bajo cinco condiciones: sin historial, ejemplos de soluciones exitosas añadidos al contexto, habilidades escritas por personas, habilidades aprendidas y habilidades ajenas a la tarea.

Las habilidades aprendidas se congelan durante la evaluación. Así no se mide una herramienta que cambia mientras se ejecuta la prueba.

Junto con la calidad, se registran la latencia, las llamadas al modelo y a herramientas, el uso real de las habilidades y el consumo observado de tokens. El coste de producir la habilidad también se mantiene separado.

El trabajo acotado de aprendizaje en vivo registrado en las fuentes produjo habilidades que superaron comprobaciones independientes en cuatro familias de transformación de datos. Sin embargo, las comparaciones pequeñas e incompletas no mostraron una ventaja de eficiencia.

Este resultado hace visible una distinción importante: producir un componente utilizable y lograr que mejore todo el flujo de trabajo son preguntas separadas.

Una herramienta puede devolver una salida correcta mientras el agente la invoca innecesariamente o la combina mal con otros componentes. Por eso, aceptar una pieza no basta para aceptar la tarea completa.

Dónde no debe utilizarse una herramienta

En el artículo anterior hablamos de evaluar las relaciones que dan validez a un registro recordado. Al reutilizar una habilidad encontramos un límite parecido.

¿Una habilidad que funcionaba correctamente antes es compatible con las reglas de la nueva tarea?

Si cambió la regla de correspondencia o se requiere otra transformación, utilizar silenciosamente la habilidad anterior puede producir un resultado incorrecto. Por eso a2 comprueba explícitamente la compatibilidad del contrato.

Construir un plan de varios pasos con las habilidades existentes es otra área de trabajo. La salida de un componente puede ser la entrada del siguiente, pero las condiciones de esa composición y su resultado final requieren una verificación aparte.

Decir que no se puede producir un plan para un trabajo no compatible también forma parte de este comportamiento. Una herramienta que funciona debe distinguir el trabajo que puede realizar del que queda fuera de su alcance actual.

Un componente que funciona y una herramienta terminada

a2 sigue en fase alfa de desarrollo.

La demostración sin conexión muestra la verificación y reutilización de habilidades escritas por personas con entradas diferentes. No debe interpretarse como un experimento que demuestra aprendizaje del modelo.

Los registros de aprendizaje en vivo constituyen otra línea de evidencia. Siguen siendo necesarias evaluaciones completas con varias semillas y validación sobre datos de usuarios reales.

En este punto es difícil ver el paso de idea a herramienta como un único momento de finalización. Cada etapa abre otra pregunta:

¿La solución es correcta? ¿La habilidad derivada funciona con entradas nuevas? ¿Con qué reglas es compatible? ¿Reutilizarla mejora toda la tarea?

El trabajo que toma forma en a2 consiste en avanzar en estas preguntas sin confundirlas.

Cuando podemos ejecutar de nuevo una solución, tenemos un componente. Al establecer cuándo utilizarlo, cómo probarlo y cuándo detenerlo, ese componente se convierte en una herramienta.

---

Nota sobre las fuentes — 15 de octubre de 2026: El artículo se basa en el README de a2, sus documentos de arquitectura y evaluación y sus registros de desarrollo fechados. El ejemplo de los archivos de productos es hipotético. No se realizó ninguna nueva llamada al modelo ni ejecución de evaluación para este artículo; se describen resultados acotados ya registrados en las fuentes.

Página del proyecto a2 · ¿La memoria guarda registros o relaciones?