El recorrido de una tarea en a2

En la mesa de trabajo — 10

Una tarea suele comenzar con una frase breve: «Ordena estos datos».

Pero esa frase contiene decisiones todavía pendientes. ¿Qué campos se conservarán? ¿Cuáles cambiarán de nombre? ¿Se eliminarán los espacios? Si un registro aparece dos veces, ¿se conservarán ambas copias?

Quiero pensar el recorrido de una tarea en a2 a través de la división de estas decisiones en partes pequeñas y trazables.

Para ello tomaré una transformación sencilla de los archivos de ejemplo del proyecto. Una tarea de dos registros que no contiene datos reales de usuarios.

De la petición a una regla explícita

Cada registro de la entrada de ejemplo tiene un código, un nombre y un campo que no se utilizará:

{
  "code": "A1",
  "name": "  First item  ",
  "ignored": "discard"
}

La transformación solicitada es pequeña: code pasa a ser id y name pasa a ser label. Se eliminan los espacios iniciales y finales del nombre. Los demás campos no se incluyen en la salida.

Pero la regla no termina ahí. Conservar todos los registros y no producir registros de incidencias en este ejemplo también forma parte del contrato.

Estos detalles acotan lo que deja abierto la palabra «ordena». Determinan qué cambios pueden hacerse y cuáles no deben hacerse.

La primera pieza importante es ese contrato, antes que los propios datos.

La recepción de la entrada

Una tarea puede rechazarse antes de llegar al modelo.

En la ruta de datos de a2, la entrada local debe tener la estructura esperada. No se aceptan claves JSON duplicadas ni valores numéricos inválidos. El tamaño de la entrada también está limitado.

Estas comprobaciones no resuelven el significado de la tarea. Responden a una pregunta más básica: ¿tenemos datos que podemos leer sin ambigüedad?

Aceptar silenciosamente un nombre de campo escrito dos veces en el mismo objeto, por ejemplo, puede volver incierto qué valor se utiliza antes incluso de comenzar la transformación.

Por eso aceptar la entrada también es un paso del trabajo. Que el archivo exista no significa que esté listo para procesarse.

¿Por qué vía haremos el trabajo?

No todas las tareas siguen la misma vía en a2.

Si hay una habilidad previamente verificada cuyo contrato coincide exactamente con esta transformación, data apply puede ejecutarla directamente. En esa vía no se llama al modelo.

La coincidencia es aquí más estricta que el parecido entre dos tareas. Se consideran conjuntamente la familia de transformación, el contrato guardado y su versión. Si no hay una habilidad adecuada o la selección es ambigua, la ejecución se detiene con un informe. No recurre automáticamente al modelo para intentar otra solución.

Resolver con un modelo y aprender una habilidad nueva son vías separadas.

Esta distinción facilita entender cómo se ejecutó el trabajo. ¿Reutilizamos una pieza disponible, generamos una solución nueva o preparamos una candidata a habilidad reutilizable?

Aunque los archivos resultantes se parezcan, los fundamentos y los costes de estas vías son diferentes.

El encuentro con la salida

La transformación esperada del primer registro es:

{
  "id": "A1",
  "label": "First item"
}

El segundo registro se transforma con las mismas reglas. La salida completa contiene rows para los registros transformados e issues para las incidencias.

Aquí hay dos exámenes separados.

El primero comprueba si la salida tiene la estructura esperada. El segundo, si coincide con un resultado esperado preparado de forma independiente.

En los archivos de ejemplo de a2, la respuesta esperada se mantiene aparte. El modelo que resuelve la tarea no recibe la respuesta de referencia. La comprobación se realiza externamente sobre el resultado generado.

Como en este ejemplo deben conservarse todos los registros, la comparación también conserva la cantidad de registros duplicados. Una salida de aspecto ordenado no debería ocultar un registro perdido.

Cuando no se proporciona un resultado esperado, el informe indica que solo se ha comprobado el esquema. Al leerlo hay que atender al alcance de verificación con el que se asignó el estado de «éxito».

Conectar una tarea con otra

Podríamos querer que los registros transformados se cotejaran después con otro archivo.

Eso ya es un trabajo más amplio que el ejemplo de una sola habilidad. Debe definirse explícitamente a qué entrada del segundo paso se conectará la salida del primero.

La ruta data pipeline de a2 ejecuta planes secuenciales preparados por quien la invoca. Los contenedores rows o issues del paso anterior pueden pasarse a entradas determinadas. En esa conexión no hay una transformación implícita de campos.

Si un paso falla, los siguientes no se ejecutan. Si el resultado intermedio contiene incidencias, también debe explicitarse cómo se trasladan al siguiente paso. Transferirlas no demuestra por sí solo que se preserve su significado; el resultado requiere otra comprobación.

También puede pedirse al modelo una propuesta de plan. Sin embargo, producir una propuesta y ejecutarla son operaciones distintas. Un plan propuesto no confirma que el objetivo vaya a resolverse correctamente.

Así aparece otro punto de decisión en el recorrido: ¿se han unido realmente las piezas de una forma que haga el trabajo solicitado?

El registro que queda al final

No considero suficiente que al final solo queden datos transformados.

¿Qué habilidad se utilizó? ¿Qué comprobación se hizo? ¿Terminó la ejecución, produjo un resultado inválido o se detuvo ante un límite?

Los informes de a2 dejan rastros de estas preguntas según la vía ejecutada. La reutilización directa registra la habilidad seleccionada y el alcance de verificación; la ejecución de varios pasos registra los pasos completados y los hashes del código de las habilidades utilizadas.

Aprender una habilidad nueva tiene también su propia vía de verificación. Producir una respuesta correcta en una tarea no demuestra que la misma operación funcione con otras entradas.

La conclusión que podemos sacar de este ejemplo de dos registros también es limitada. Podemos mostrar un contrato explícito y una respuesta esperada comprobable. No podemos inferir de ello eficiencia general ni corrección amplia en trabajos reales.

El recorrido que quiero seguir en a2 es este: la petición se convierte en regla, se elige una vía adecuada, se comprueba la salida y queda un registro legible.

Para que, cuando llegue la siguiente tarea, podamos volver al archivo anterior y preguntar:

¿Qué conseguimos exactamente aquí y bajo qué condiciones podemos volver a confiar en ello?

---

Nota de fuentes — 15 de octubre de 2026: El artículo se basa en las entradas de ejemplo y los resultados esperados incluidos en a2, y en su código actual de datos, reutilización, planificación y ejecución secuencial. La transformación de dos registros es un ejemplo didáctico del proyecto, no un trabajo real de un usuario. La correspondencia posterior es una ampliación que ilustra el flujo. No se realizó ninguna nueva llamada al modelo ni ejecución de evaluación para este artículo.

Página del proyecto a2 · Artículo anterior: ¿Cuándo debería detenerse un agente?