Saltar al contenido
Proyectos

Signal Agent

En desarrollo prototype

Un monitor de mercado donde el modelo tiene que escribir una predicción falsable antes de poder ser evaluado — 3 abiertas, 0 resueltas, las primeras vencen en enero de 2027.

Un monitor de mercado que recolecta por calendario en GitHub Actions y después obliga al modelo a responder por lo que dijo: cada juicio queda firmado, cada llamada trae una predicción falsable con su criterio de resolución escrito de antemano, y el registro de aciertos es el producto de verdad.

1 min de lectura Ver arquitectura →

Tecnología

  • IA & agentes
  • Automatización

Sector

  • Economía & finanzas

Problema

Casi todas las demos de agentes son infalsables. El modelo produce un párrafo seguro de sí mismo, nadie deja escrito qué habría contado como error, y al mes siguiente hay otro párrafo igual de seguro. La pregunta interesante no es si un modelo puede resumir un mercado: es si después se le puede pedir cuentas, y eso obliga a decidir de antemano qué contaría como fallo.

Qué va a ser

Un caso de estudio sobre lo que realmente importa aquí: el esquema. Un juicio registra quién lo hizo (`judged_by`: claude-code, una persona, o una importación) y su veredicto; la confianza se fuerza a NULL cuando el veredicto es «sin cambio», así que nada puede ser confiadamente ambiguo. Una predicción lleva una afirmación binaria, el criterio de resolución escrito antes de conocer el desenlace, y un horizonte que fija la fecha en que vence. Un resultado es correcto, incorrecto, o genuinamente indeterminado — y lo indeterminado queda excluido de la tasa de acierto en vez de redondearse hacia adentro. Al re-juzgar nunca se lee el veredicto anterior, para que la confianza vieja no ancle a la nueva. Un indicador que en diez predicciones resueltas no le gana a una moneda queda marcado para eliminación. La recolección y el informe se corren solos; el juicio se dispara a mano dentro de Claude Code, y no hay ninguna API key de modelo en el código.

Estado: Solo fase 1: 95 observaciones, 6 señales y 3 predicciones abiertas. Todavía no se ha resuelto nada, así que no hay tasa de acierto que mostrar — las primeras predicciones vencen en enero de 2027 y los comandos de evaluación siguen siendo stubs. Repo y demo vienen después.

Arquitectura

Monitor de mercado: la colecta determinista corre en GitHub Actions y el juicio del modelo queda en un ledger SQLite de predicciones falsables.

  • GitHub
cronrun.py collect|briefpush · issuecarga domain.yamlHTTPS GET + ETagSQLescribe el .mdabre /analizarrun.py brief · judgelee ANALYZE.mdpersona · dueño del criterioOwnerlee el issue, lanza /analizarexterno · repo + cronGitHubrama main · cron · Issuesgithub actions · ubuntu-latestRunner de ActionsPython 3.12 · pip · gitsesión de claude code · /analizarSesión de juicioClaude Code ·.claude/commands/analizar.mdpython · núcleo del repoCLI y núcleorun.py · core/ · pydantic ·sqlite3externo · fuentes públicasFuentes de datosRSS · JSON · precios CSV/exchange ·HTMLsqlite · versionado en gitsignal.dbSQLite WAL · schema.sql ·views.sql · migracionesarchivos · la costurabriefings/YYYY-MM.mdmarkdown autosuficientearchivos · configuración y criterioDominios y criteriodomains/*/domain.yaml ·ANALYZE.mdC4 · nivel 2 (contenedores) · tráfico ambiente = llamadas reales · clic en una caja para el detallelínea continua = HTTP/SQL · punteada = adaptador elegido por configuración · caja punteada = existe fuera del proyecto
abrir en pestaña ↗

Flujos que se pueden reproducir

  1. Colecta semanal
  2. Briefing mensual con predicciones
  3. Juicio mensual y alta de predicciones