The Foundry Update: Architecting Multi-Agent Intelligence

The Evolution of The Foundry

I have spent the last few weeks overhauling The Foundry. What started as a personal governance substrate to keep my local AI agents from hallucinating has slowly morphed into a centralised multi-agent orchestrator. The architecture is now stable, the local-to-cloud escalation paths are working flawlessly, and the UI has matured into a professional-grade tool ready for serious engineering workflows.

However, despite the technical readiness of the platform, I am consciously choosing not to hit 'publish' on a public release just yet. In this post, I want to break down the new features shipped to the control plane, share the lessons learned from past projects like Vyzo, and explain why I am prioritising organic growth over a wide release.

What is New in The Foundry

I have introduced three massive architectural updates designed to provide users with strict control over both AI reasoning and infrastructure economics.

1. Granular Model Selection

In the previous build, escalation tiers were rigid. Now, you have absolute control over compute routing. You can assign specific LLMs not just to a failure tier, but to individual personas. By locking down the context and using strict Spec and Test-Driven Development (SDD/TDD) guardrails, I have found that I rarely need to escalate to higher-tier models. I can use a highly capable local model like Qwen 3.6 27B for almost every large task. If a task requires more power, I simply swap the model for that specific persona, avoiding premium API costs for boilerplate tasks.

2. Token Weights and Context Economics

Context windows are not infinite, and bloat is the enemy of a multi-agent swarm. I have introduced explicit Token Weights. The system now calculates and manages the context budget for every agent, ensuring that chat histories and code snippets do not silently overflow and destroy the reasoning capacity of the system.

3. The Codebase Wiki to Graph Pipeline

This is the feature I am most excited about. I added a dedicated wiki for the codebases the swarm is working on, which acts as a bridge to a centralised knowledge graph. Instead of forcing an agent to blindly read a massive repository, it queries the graph, providing context to both the user and the swarm simultaneously. You can literally see the mental model the AI has of your codebase via the management UI.

Lessons from Vyzo and OpenSwarm

With a centralised graph and a solid management UI, The Foundry is in a state where it could be incredibly powerful for engineering groups. So, why hold back? In previous projects like Vyzo and OpenSwarm-os, the technical stability was fine, but the approach was flawed. I would build, confirm, and throw the project out into the wild. I learned that dropping a tool on GitHub does not automatically create a product.

To make a project successful, you need organic growth. You need a foundational base of users who get real value out of the tool and advocate for it. The Foundry is highly opinionated and forces a specific way of working, which is why I need to find the right cohort of users who value granular control over their context and compute.

Next Steps: Building the Base

Instead of an open public beta, I am taking an organic approach. I need a small, dedicated group of peer engineers to integrate this into their workflows. My plan for the coming weeks includes:

• Engaging in niche communities like r/LocalLLaMA and r/OpenSourceAI to find engineers with the hardware to run multi-agent swarms locally.

• Sharing specific components on technical forums to test how the graph ingestion handles foreign codebases.

• Running controlled trials with a handful of developers to gauge the day-to-day feel of the UI.

The goal is not to find bugs, as the system is stable. The goal is to see if it genuinely improves the engineering process. We will test, refine, and then build the foundation for a wider release.