The AI product team
Eight roles that know who to hand the work to.
You brief the Product Lead. It decides what the objective needs, and the rest of the team picks up the parts they own. You are not managing eight assistants.
Meet the AI product team
Eight roles. One product organisation.
You brief the Product Lead. It decides what the objective needs, and the rest of the team picks up the parts they own — including handing work to each other.
Product
Engineering
Delivery
These are not eight chatbots you brief individually. Select a role to see what it owns.
AI Product Lead
Owns the outcome and coordinates the team.
Does the work
- Turns a business objective into a release plan
- Assigns work across the product team
- Reviews completed work against the objective
- Escalates consequential decisions to the business
Works with the team
Receives the objective from the business, directs every other agent, and is the one agent that asks you for a decision.
Multi-agent collaboration
Agents assign work to each other.
This is what separates a product team from a set of assistants. An engineer that needs something blocks and asks for it. QA sends work back when it does not meet the criteria. Nobody marks their own homework.
Work item
Password reset
- PMProduct ManagerASSIGN
Password reset implementation
6 acceptance criteria, including a 30 minute link expiry
- FEFrontend EngineerBLOCKEDRequest → Backend
Reset endpoint missing
Blocked itself rather than stubbing a contract that does not exist
- BEBackend EngineerCOMPLETEReturn → Frontend
Reset endpoint created
Single-use tokens, rate limited. Contract published
- FEFrontend EngineerCOMPLETEHandoff → QA
4 screens integrated
- QAQA EngineerFAILEDReturn → Backend
Token expiry test failed
A token issued 45 minutes ago still authenticated
- BEBackend EngineerFIXED
Expiry now evaluated server-side
Cause was the client clock
- QAQA EngineerVERIFIED
12 of 12 tests passed
- LEADProduct LeadESCALATE
Release ready — needs your approval
- YOUYouAPPROVE
Approved production deployment
- OPSDevOps EngineerDEPLOYED
Release 1.4 live
Every handover is a structured operation against a shared work item — ASSIGN, REQUEST, RETURN, ESCALATE — not a message in a chat window. That is what makes the work inspectable afterwards.
The authority model
Access is not authority.
A DevOps agent with cloud access does not thereby have permission to provision unlimited infrastructure. A Growth agent with your social credentials does not thereby have permission to publish. Every permission is explicit, and enforced in the backend — not asked for politely in a prompt.
Foundry can
Done without asking. Nothing here reaches a customer or spends your money.
Research and discovery
Requirements and user stories
Design drafts
Writing code
Running tests
Fixing low-risk bugs
Writing documentation
Foundry prepares and waits
The work is ready and the recommendation is stated. Nothing proceeds until you decide.
Major scope changes
Architecture changes
Production deployments
Destructive database migrations
Purchasing infrastructure
Connecting sensitive systems
External marketing publication
Material budget changes
Reserved for you
No agent holds these at any permission level, and none can grant them to itself.
Granting or widening agent permissions
Deleting production data
Legal and contractual commitments
Removing a human approver
Start with one product
Tell Foundry what your business needs.
Create a workspace, describe the product, and watch the team pick it up. You approve what matters; Foundry handles the rest.