P1 · Personal projects
A virtual company staffed by 11 AI employees
A hand-built multi-agent orchestrator, and the trust boundary problem found inside it
11 Agents3 Divisions
- AI
- Multi-Agent
- Slack
In one line
I built a virtual company of 11 AI employees on a hand-built orchestrator, and saw firsthand the trust boundary problem when agents accept each other's work without checks.
Background
I designed a multi-agent orchestrator (a program that assigns work to several AI agents and manages the flow) and built a virtual company of 11 roles in 3 divisions.
| Division | Roles |
|---|---|
| Management | Chief of Staff, Finance, HR |
| Technology | Tech Lead, Senior Engineer, Engineer, DB Engineer, QA Engineer, Security Engineer |
| Sales | Planning & Sales Lead, Content Marketer (off by default) |
- The Chief of Staff agent turns a directive into an execution plan and asks for review before starting.
- Anthropic, OpenAI, Google, and DeepSeek models are assigned by priority for each role, and work moves to the next model on failure. Cost is tracked against a budget.
- Slack, Jira, and GitHub are connected, and a web dashboard (FastAPI) shows agent activity in a pixel-art office (CCTV view).
- I wrote a software requirements specification (SRS) and implementation instructions.
The public repository covers assignment, model selection, and cost tracking, and it simulates the language model calls.
Problem
This is a problem I ran into myself on this project. When one agent produced a wrong result, the next agent trusted it without checking and carried on.
In a human organization, a team reviews another team’s output. Between agents, there was no such step.
From a security point of view, this is trusting untrusted input. Real production AI systems face the same trust boundary and permission scope problems.
What I did
The repository has these safeguards in code. They connect to the principles below.
| Safeguard | Related principle |
|---|---|
| External writes blocked by default | Principle 3. Give the least access |
| File paths restricted | Principle 3. Give the least access |
| Work stops at 100% of budget | Principle 3. Give the least access |
| Slack request signatures verified | Principle 2. Keep it checkable |
The verification step in the last scene is not a built feature. It shows a principle I took away from this project.
What I learned
Principles I took away
- AI supports the judgment. A person approves real actions, such as blocking or changing permissions.
- AI conclusions must leave evidence that a person can check.
- Give AI the least access it needs.