Registro de trabajo de a2
Para saber si un flujo de datos es reutilizable, hay que mirar el segundo archivo.
La solución que funciona en el primero puede estar adaptada solo a sus detalles. Cuando cambian los registros, se ve con más claridad qué permanece constante.
Por eso la demostración de a2 tiene dos días distintos.
El escenario es pequeño: averiguar qué códigos de cliente de la lista CRM tienen correspondencia en ERP. Se supone que ambos sistemas utilizan el mismo código único. Los datos y las empresas son sintéticos.
Primero las reglas
La primera habilidad prepara los campos de CRM. code pasa a ser id; name, a label. Se eliminan los espacios iniciales y finales del nombre.
La segunda habilidad coteja los registros preparados con la lista ERP mediante el código de cliente. Los registros con correspondencia entran en la lista de resultados. Los registros CRM sin correspondencia se separan con el código missing_match.
Las cuentas que solo existen en ERP no entran en la lista de clientes emparejados de esta tarea; su cantidad se informa por separado.
Esta elección importa. No aplicamos todos los significados posibles de «conciliar dos archivos». Ejecutamos una comparación en una dirección y bajo una regla determinadas.
El registro de dos días
El resumen de ejecución del paquete contiene estos resultados:
| Registro | Primer día | Segundo día |
|---|---|---|
| Registros CRM | 6 | 7 |
| Registros emparejados | 4 | 5 |
| Registros CRM sin correspondencia | 2 | 2 |
| Cuentas solo en ERP | 1 | 1 |
| Llamadas al modelo | 0 | 0 |
El resultado de cada día se comparó con una respuesta esperada independiente. Los hashes del código de las habilidades utilizadas también son iguales.
No leo esta tabla como una comparación de velocidad o aprendizaje. La leo como un registro limitado de las mismas reglas ejecutadas con las mismas versiones de habilidades sobre dos grupos de datos.
Un pequeño detalle: 0007
Uno de los códigos de cliente de la demo es 0007.
Aunque parezca un número, aquí es un identificador. Se conservan sus ceros iniciales. Convertirlo en 7 sería un cambio no permitido por el contrato de la tarea.
La coincidencia es exacta y distingue mayúsculas y minúsculas. No se infiere que los registros pertenezcan al mismo cliente porque los nombres se parezcan. No se aceptan códigos vacíos ni duplicados.
Pueden parecer detalles pequeños. Pero la fiabilidad de un flujo de datos suele decidirse precisamente ahí: el sistema sabe qué transformación hará y no deja ambiguo cuál no hará.
Dónde mirar después del resultado
La demo no produce solo una pantalla de resumen. También se pueden inspeccionar los planes, registros emparejados, listas de incidencias y registros de ejecución. El informe HTML facilita leerlos juntos.
Después de instalar, la demo se ejecuta con:
python -m a2.customer_demo --output runs/customer-demo --compact
Para otra ejecución hay que elegir un directorio de salida nuevo.
La pregunta que responde este ejemplo es acotada: ¿podemos utilizar las mismas dos habilidades en un archivo nuevo y comprobar el resultado con una referencia separada?
El uso real añadirá preguntas. ¿Los sistemas de origen comparten de verdad el identificador? ¿Han cambiado las reglas? ¿Quién atenderá los registros apartados para revisión?
El segundo archivo es el comienzo de la reutilización. Comprobar que no haya cambiado el significado del trabajo sigue siendo una responsabilidad continua.
Nota de fuentes — 18 de octubre de 2026: El texto se basa en los documentos de la versión 0.1.0a1 y los registros existentes de la demo. Los datos son sintéticos y las habilidades están escritas por personas. No se ejecutó una demo, llamada al modelo o evaluación nueva para este artículo.
Código fuente · Versión y descargas · Guía de la demo · Descargar informe HTML · Descargar evidencia de la demo · GitHub CI
Conexiones: a2 · La primera versión preliminar técnica de a2 · El recorrido de una tarea en a2 · ¿Por qué un plan se niega a ejecutarse?
Se conecta con
Examina la versión preliminar 0.1.0a1 de a2 y la evidencia limitada de su paquete.
Concreta la reutilización del anuncio mediante los registros de dos días.
Vincula el recorrido de una tarea con el ejemplo sintético publicado de CRM/ERP.
Pasa de la demo de dos días al control separado que rechaza un cambio de habilidad.