An engineering organisation
Every agent has a job, a scope and a reviewer.
One assistant answering every question is not an engineering organisation. Foundariq runs a ladder of roles reaching down through the build and AI engineering layer, fifth of the six: portfolio strategy and product planning at the top, Blueprint architecture and reuse beneath them, then engineering, review, QA, security and release. Every role carries a written scope — what it may propose, what it may change, where it must hand the work upward. Agents propose and nothing more: deterministic validation runs first, policy evaluates what the change touches, and a named person approves where policy says one is needed. GitHub still holds the repositories, the pull requests and the releases; Foundariq holds the organisation that produced them.
One agent cannot check itself
Ask a single model to plan the work, produce the work and then confirm the work is sound, and what comes back is agreement, not verification. The reasoning under review is the same reasoning doing the reading. A pull request carrying its author's own approval was never reviewed, and that does not change when the author is a model.
Scopes and separation live outside the model
Each role's grant — repositories, Blueprint areas, capabilities, actions it must hand on — is held in configuration and checked by the control plane when the action runs, not asserted in prompt text. Two rules hold whatever you configure: the agent that raised a proposal is excluded from reviewing it, and critical work runs across more than one model provider. The platform refuses a run it cannot staff that way.
Delegation that leaves a record
You hand over the work of an engineering team without handing over control of it. Every proposal carries the role that raised it, the critic's findings, the policy result and the person who approved, so a change reads months later without replaying a conversation. Adding capacity to the portfolio then means adding roles, not extending trust.
What is included
5 capabilities in AI Workforce
Each one is its own surface, and all of them answer to the same Blueprint under one set of policies.
Agent Roles
Portfolio Strategist through Release Manager: every role has a written scope, defined inputs and work it is not allowed to do.
Read moreSeparation of Duties
An agent never approves its own output. Proposal and review are separate roles, held by separate agents, every time.
Read moreModel Routing
Choose which model does which job. Two rules hold: no model reviews its own work, and critical workflows use more than one.
Read moreAgent Permissions
An agent holds a scope, not a key to everything: what it may propose, what it may change, what it must escalate.
Read moreDecisions, Not Transcripts
The interface shows the decision, its reasoning, its impact and the options — not a scroll of agent conversation.
Read moreThe rest of the product
Six areas, one system.
Blueprints
The Blueprint records what your software means before any file is generated, and a published version of it is what every release points back to.
5 capabilitiesCapability Graph
The portfolio as a library: every capability with a key, a version, an owner, a status and the products depending on it.
5 capabilitiesAutonomous Builds
Strategy becomes ordered tasks, pull requests and a release that names its inputs. Nothing merges on an agent's word.
5 capabilitiesStop managing prompts. Start managing software strategy.
Connect your repositories. Let Foundariq understand what you have already built. Then tell it what your portfolio should build next.
Read-only to start · Your code stays in your GitHub · [email protected]