Proyecto de Hackathon
Los agentes proponen, el código decide.
18 de julio de 2026 · 6 min de lectura
Construimos un sistema de IA que escribe propuestas comerciales, y le prohibimos hacer la matemática.
Esa única decisión de diseño, más que cualquier elección de modelo o truco de prompt, es lo que hizo funcionar a Proposal Architect. Esta es la historia de la arquitectura que construimos para el Google for Startups AI Agents Challenge 2026, y de la regla que la moldeó: los agentes proponen, el código decide.
Por qué las propuestas son un buen problema para agentes
Una propuesta comercial no es una sola tarea. Es una cadena de competencias muy distintas: leer un brief desordenado, mapear requisitos, diseñar una arquitectura, descomponer el trabajo, estimar esfuerzo, ponerle precio y escribirlo todo en una forma que un cliente pueda evaluar de verdad. Pídale a un solo prompt que haga todo eso y obtendrá algo que parece una propuesta y no sobrevive a ningún escrutinio.
Los pipelines multiagente existen exactamente para problemas con esta forma. Cada competencia se convierte en un agente especializado con un contrato estrecho; el pipeline lleva el estado de uno al siguiente; y las partes que nunca deben ser creativas (la aritmética) salen del modelo por completo.
El pipeline en seis movimientos
Cómo funciona el pipeline de agentes.
Seis movimientos del brief en bruto a la propuesta revisable: los agentes proponen, el código determinista pone el precio y un crítico cuestiona.
- 01Brief del Cliente
Un RFP desordenado o unos párrafos de contexto entran al pipeline.
- 02Anclaje en Conocimiento
Los agentes anclan el brief en tarifas y en el conocimiento de proyectos anteriores.
- 03Diseño de Arquitectura
Un agente arquitecto diseña la solución y su estructura de trabajo.
- 04Precios Deterministas
El precio y el ROI se calculan en código, nunca los estima el modelo.
- 05Bucle de Crítica
Un crítico adversarial cuestiona el borrador y devuelve las partes débiles.
- 06Propuesta Lista para el Cliente
Una propuesta revisable y con la marca, en pantalla y en PDF.
El flujo se lee de izquierda a derecha: entra un brief en bruto; los agentes lo anclan en el conocimiento de la empresa (tarifas, proyectos anteriores); un agente arquitecto diseña la solución y su estructura de trabajo; un paso determinista calcula costo y ROI en código; un crítico adversarial cuestiona el borrador; y un compositor arma la propuesta final, en pantalla y en PDF con la marca.
El núcleo determinista
Los modelos de lenguaje son convincentes en aritmética y poco fiables en ella, que es la peor combinación posible para poner precios. Por eso el paso de precios de Proposal Architect no es un agente. Es Python puro: el modelo propone entradas estructuradas (roles, esfuerzo, supuestos), y compute_price y compute_value hacen la cuenta.
La frontera se defiende, no solo se declara. Los números de autoría del modelo se validan antes de entrar al cálculo: los valores no finitos y las cantidades negativas se rechazan de inmediato, así que una entrada alucinada no puede envenenar el precio ni el ROI. Las mismas entradas producen siempre los mismos números, lo que significa que un socio puede auditar cualquier cifra del documento hasta sus entradas.
Esta es la regla general con la que construimos: el modelo propone, el código decide. Donde un número carga consecuencias de negocio (un precio, un score, una cuota), se calcula de forma determinista, y el trabajo del modelo termina en sugerir entradas.
El crítico que cuestiona
Los primeros borradores son confiados y están equivocados de maneras sutiles. La respuesta del pipeline es un agente crítico adversarial cuyo único trabajo es atacar el borrador: afirmaciones sin sustento, secciones débiles, inconsistencias entre la arquitectura y la estimación. Las secciones reprobadas vuelven a otra pasada, dentro de un bucle acotado, para que la presión de calidad sea estructural en lugar de depender de alguien releyendo con cuidado a las 11 de la noche.
Lo que compra esta arquitectura
Tres propiedades caen del diseño en lugar de pegarse después: trazabilidad (cada requisito del brief mapea a una sección de la respuesta, con estado), auditabilidad (cada número se reproduce desde sus entradas) y consistencia (la estructura del documento la impone el pipeline, no el ánimo del día).
La parte honesta
Proposal Architect nació como un sistema de hackathon: el conocimiento en el que se ancla es sintético por diseño, y no es (todavía) un despliegue de cliente. Lo que el build validó fue la arquitectura: la frontera determinista, el bucle de crítica y el patrón de anclaje sobrevivieron a ejecuciones reales, revisión adversarial y una ola de hardening de seguridad.
Esa arquitectura es el punto. Es la misma regla que aplicamos a todo lo que entregamos en Techmorphosys: inteligencia donde ayuda, determinismo donde importa.
¿Construyendo algo con agentes, datos o ambos? Ese es nuestro trabajo diario.
Hablemos de tu Proyecto