Foundry: An Opinionated AI Company Platform Where the Org Chart Is the Product
Transform any idea into a running AI-powered company
At a glance
- What is it?
- Foundry ships a pre-built multi-agent company (CEO agent, departments, group chat, approvals) rather than an agent framework you wire yourself. It is a NestJS and React monorepo under GPL-3.0, and the interesting question is whether the fixed org structure is worth the Docker stack it drags in.
- Who is it for?
- Adopt Foundry if you want a working multi-agent organisation with a UI, approvals and group chat, and you accept PostgreSQL, Redis, RabbitMQ, Consul and Nginx running alongside it. Do not adopt it if you need to embed agent orchestration into an existing service, since the org chart, the message queue and the gateway are the product rather than optional parts.
- Can I use it commercially?
- Yes, with conditions. GPL-3.0 is a copyleft licence: if you distribute software that includes it, you must release that software's source code under the same licence. Running it internally without distributing it does not trigger that obligation.
- Is it still maintained?
- Yes. The repository last received commits 78 days ago.
- What is it written in?
- Mainly TypeScript, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The problem Foundry solves is orchestration, not model access
Most agent projects hand you primitives. You get a tool-calling loop, a memory store, and a blank page. The wiring (who receives the task, who reviews it, who decides it is finished) is left to you. Foundry takes the opposite position. The README frames it directly: if CrewAI is described as building blocks for agents, Foundry is described as the company already built. The unit of delivery is an organisation, not a library. You type a goal such as analysing competitors and producing a report into a group chat, and the CEO Agent decomposes the task, routes it to an analysis department, runs work in parallel, and summarises the result. A human approves key decisions. The audience is therefore narrow and specific: teams that want to operate an agent workflow through a UI, with a visible org chart and an approval gate, rather than call an SDK from their own code. If you already have a task queue and a review process, Foundry is competing with what you have built, not filling a gap in it.
What actually runs: a NestJS monorepo behind five containers
The repository is a TypeScript monorepo. The badges name NestJS 10, React 18 and TypeScript 5.9, and the topics list points at nestjs, react and workflow, which matches the split between an API service, a gateway, a client UI and an admin panel. Infrastructure is containerised and the README is explicit that you do not install these separately: PostgreSQL 18 on postgres:18-alpine, Redis 7 for cache and sessions, RabbitMQ 3 with the management image, Consul for service discovery, and Nginx as reverse proxy. RabbitMQ plus Consul is the part worth pausing on. A message queue and a service registry imply that agents, departments and the gateway are separate processes that find each other and communicate asynchronously. That is a real architectural commitment. It buys you parallel execution across departments, which is what the README promises in the competitor-analysis example. It costs you five moving parts before a single agent has done any work. The data flow the README describes is human goal to CEO Agent decomposition to department assignment to parallel execution to summarised result to human approval. Everything between the goal and the approval is the platform's responsibility, not yours.
Getting it running: one command, or seven steps you can audit
The recommended path is two lines. Clone the repository and run pnpm setup:dev, which the README describes as env, install, docker, db, start in sequence. The step-by-step path is more useful if you want to see what each stage touches. After cloning, pnpm install pulls dependencies. Environment configuration is a single Node call that copies env.shared.example to .env.shared, followed by node scripts/env-manager.js, which generates per-service .env files. Then pnpm infra:start brings up PostgreSQL, Redis and RabbitMQ, node scripts/bootstrap-db.js initialises the database, and pnpm dev starts the development server. The README states first launch takes five to ten minutes because Docker downloads roughly 2 GB of images, and subsequent starts take about 30 seconds. Operational commands are short: pnpm infra:status, pnpm infra:logs, pnpm infra:stop, pnpm infra:restart. Once healthy, the client UI is on port 5173, the admin panel on 3105, API Swagger docs on 3000, gateway Swagger docs on 3002, Grafana on 4000 and the RabbitMQ management UI on 15672. Minimum requirements are 8 GB RAM and 5 GB disk, with 16 GB and 10 GB recommended.
Default credentials are the first thing you have to change
On first startup the platform creates an admin account automatically: email admin@example.com, username admin, password changeme. The README flags this and tells you to change DEFAULT_ADMIN_PASSWORD in production. The same pattern repeats across the bundled services. Grafana ships as admin/admin, RabbitMQ as guest/guest, and the admin panel accepts admin with changeme. None of this is unusual for a development stack, and the README does not hide it. The point is that Foundry is a multi-service system with several independent entry points, so a partial hardening pass leaves holes. Changing the application admin password does nothing for Grafana or RabbitMQ, which sit on their own ports with their own credential stores. If you expose this beyond localhost, the credential surface is the application, the admin panel, the metrics dashboard and the queue management UI. The README gives you the keys; it does not give you a hardening checklist, and that work is yours.
Where the fixed org chart becomes a constraint
The design bet is that a pre-built company structure is more useful than a blank one. That bet has a cost, and the README does not address it. Departments, roles and the CEO Agent's decomposition logic are presented as the product, not as configuration. Nothing in the supplied material describes how to define a new department, rename roles, or replace the CEO Agent with a different planning strategy. So if your workflow does not look like a company (a research pipeline, a batch data process, a single long-running agent with no delegation), you are paying for an org model you will not use. The second constraint is infrastructure weight. Consul service discovery and RabbitMQ exist to support a distributed, parallel, multi-process design. If you only need one agent with a few tools, that is a large amount of operational surface for the result. The third is the approval gate itself. The README frames human approval of key decisions as a feature, and it is, for work where mistakes are expensive. If you need unattended throughput, that gate is a bottleneck you have to design around.
Foundry versus a framework like CrewAI: pre-built company or building blocks
The README draws this comparison itself, describing CrewAI as building blocks for agents and Foundry as the company already built. The difference is not model quality or prompt design. It is where the orchestration logic lives. With a framework in that class, you define agents, tasks and the order in which they run inside your own codebase, and you own the process model. Foundry moves that logic into a running platform with its own database, queue, service registry and UI. You gain a group chat, an org chart, an admin dashboard and approval flows without writing them. You lose the ability to treat orchestration as a library call inside an existing service. That trade is the whole decision. If your team wants to ship an internal tool where non-engineers submit goals and approve outputs, Foundry's shape fits. If your team wants agents as a component inside a larger backend, a framework keeps the dependency boundary where you can control it.
Licence and upgrade cost under GPL-3.0
Foundry is GPL-3.0. That matters more here than for a library, because the deliverable is a running application you would likely modify (departments, roles, prompts, UI) and possibly host for others. GPL-3.0 carries copyleft obligations when you distribute modified versions, and the network-use question is the one to raise with counsel if you plan to offer this as a hosted service, since GPL-3.0 does not include the Affero clause that closes the network gap. This is not legal advice; it is a reason to read the licence text before you build a product on top. On maintenance, the supplied material shows a v1.0.0 release dated 2026-06-24 and a last push of 2026-06-30, so the project is at a first stable tag rather than a long release history. Upgrades mean re-running pnpm setup:dev and node scripts/bootstrap-db.js against a database that already holds state, and the README's troubleshooting table already documents one migration-adjacent failure: a stale .env file carrying Docker hostnames produces getaddrinfo ENOTFOUND postgres, fixed by deleting .env and re-running setup.
Editorial conclusion
Adopt Foundry if you want a working multi-agent organisation with a UI, approvals and group chat, and you accept PostgreSQL, Redis, RabbitMQ, Consul and Nginx running alongside it. Do not adopt it if you need to embed agent orchestration into an existing service, since the org chart, the message queue and the gateway are the product rather than optional parts. Before committing, change DEFAULT_ADMIN_PASSWORD and the changeme admin login, and confirm that the department and role model can be reshaped to your own workflow, because the README documents the default structure but not how far it can be edited.
Community notes