El bucle del arquitecto — y por qué foundry-ai nunca paga una llamada LLM
M2 entregó el servidor MCP, el sentinel y los audits de specs. El truco — y el tenet de diseño que mantiene a foundry-ai self-hosted y gratis en runtime — es que el "arquitecto" vive dentro de tu agente, no dentro de foundry-ai.
Cada otra capa de gobernanza que miré quema tokens. Llega una request, la capa dispara su propio call LLM para “decidir”, te cobra por auditoría, y te encadena al modelo que la capa eligió.
foundry-ai no hace eso. No hay llamada LLM paga en foundry-ai. Nunca.
Dónde vive el arquitecto en realidad
El arquitecto es un prompt template + una superficie de tools MCP + un contrato. El razonamiento pasa dentro del agente que ya pagás — Claude Code, Cursor, cualquier cosa MCP-aware.
Cuando le decís:
“Actuá como el arquitecto de foundry-ai y auditá el spec #3.”
…tu agente carga el prompt template audit_spec vía MCP, llama a spec.get, master_context.get, memory.search y sentinel.sanitize para armar el contexto, razona usando su propia suscripción, y escribe el veredicto vía spec.set_audit.
foundry-ai persiste el veredicto. Refuerza la cadena. Lo expone en fnd score. Nunca paga un centavo.
Qué hay en la superficie MCP
Cerrada desde M2 y estable:
memory.search,memory.recent— FTS5 sobre eventos capturados.master_context.get— la intención declarada del proyecto.spec.list,spec.get,spec.create,spec.set_status,spec.set_audit— el ciclo de vida del spec, llamable desde el agente.sentinel.sanitize— detección local de secretos, censura AWS / GitHub / OpenAI antes de que entren a un prompt.
Por qué te conviene
- Sin techo de costo. A medida que crecés, tu gasto de tokens queda donde ya está.
- Sin lock-in de modelo. Pasás de Claude 4.6 a 4.7 a lo que venga — a foundry-ai no le importa.
- Sin vendor en el loop de auditoría. El veredicto es de tu agente, persistido en tu store. Nadie más lo ve.
El próximo post va a cubrir M3 — el daemon — y cómo la cola fast-path de hooks lleva un fnd hook de ~50 ms a unos pocos.