Enterprise AI workforce platform built as a multi-repo GitHub organization so multiple teams can independently build, release, and scale platform modules and AI employees.

AI Employee Force is designed as a platform where:

• the platform layer provides the shared product surfaces
• the agent layer provides individual AI employees
• the shared layer provides reusable contracts, SDKs, UI, and assets
• the infra layer powers CI/CD, deployment, and operations
• the governance layer keeps architecture, standards, docs, and prompts aligned

This structure allows us to scale to many agents, many teams, and many release cycles without turning the codebase into a bottleneck.

This organization is intentionally designed to support:

• independent team ownership
• one repo per major agent
• manifest-driven integration
• centralized shared contracts and UI
• enterprise-grade governance
• safer CI/CD and release management
• scalable growth to 20+ agents

We are not using one giant monorepo.
We are using a multi-repo GitHub organization model.

1. One repo per major platform module
2. One repo per major AI employee
3. Shared logic must be centralized
4. Platform must not hardcode agent internals
5. Agent discovery must be manifest-driven
6. Every repo must have a clear owner
7. Infrastructure must stay separate from product code
8. Architecture and standards must be documented
9. Teams should release independently
10. No circular dependencies across repos

ai-employee-force/
├─ platform/
│  ├─ aief-shell
│  ├─ aief-marketplace
│  ├─ aief-control-center
│  ├─ aief-admin-console
│  └─ aief-identity
│
├─ agents/
│  ├─ aief-fronto
│  ├─ aief-backo
│  ├─ aief-designo
│  ├─ aief-devopsy
│  ├─ aief-testo
│  ├─ aief-automo
│  └─ aief-stacko
│
├─ shared/
│  ├─ aief-ui-kit
│  ├─ aief-agent-sdk
│  ├─ aief-types
│  ├─ aief-auth-sdk
│  ├─ aief-workflow-sdk
│  ├─ aief-design-tokens
│  ├─ aief-icons
│  └─ aief-bot-assets
│
├─ infra/
│  ├─ aief-infra
│  └─ aief-github-actions
│
└─ governance/
   ├─ aief-docs
   ├─ aief-architecture
   ├─ aief-standards
   └─ aief-prompts

This tree is a logical repo map, not a monorepo folder structure.

Platform repos define the core product surfaces users interact with.

Main shell application that hosts:

• navigation
• layout
• workspace container
• routing
• manifest discovery
• shell-level user experience

Agent discovery and activation surface:

• browse agents
• search/filter agents
• capability listing
• activation/hire/install flows
• pricing and visibility

Operational dashboard for:

• task run monitoring
• execution history
• activity insights
• logs
• retry/failure tracking
• usage analytics

Enterprise administration surface:

• org settings
• feature flags
• policies
• tenant controls
• governance controls
• admin-level operations

Identity and access layer:

• login/session
• users
• roles
• teams
• permissions
• SSO
• RBAC
• auth integration

Each major AI employee gets its own repository.

Frontend Developer AI Employee

Backend Developer AI Employee

UI/UX Designer AI Employee

DevOps Engineer AI Employee

QA / Testing AI Employee

Automation Engineer AI Employee

Full Stack Developer AI Employee

Each agent repo may contain:

• manifest
• capabilities
• prompts
• workflows
• agent-specific assets
• evaluation rules
• task-specific UI
• docs and examples

Shared repos contain reusable building blocks used across platform and agent repos.

Shared Angular UI component library

Shared runtime SDK for agent lifecycle, manifest helpers, validation, telemetry, and orchestration support

Pure TypeScript shared contracts and interfaces

Shared auth helpers, guards, interceptors, session helpers, and permission abstractions

Shared workflow and execution abstractions

Design system tokens:

• colors
• typography
• spacing
• shadows
• animation values

Shared icon system

Shared bot SVGs, animation metadata, previews, and asset packs

Infrastructure, deployment, environment templates, scripts, and operational setup

Reusable GitHub Actions workflows and shared CI/CD automation

Central documentation hub

Architecture decisions, RFCs, ADRs, system diagrams, repo boundaries, integration strategy

Engineering rules:

• naming conventions
• PR rules
• dependency rules
• review rules
• code conventions
• release policy

AI development prompts:

• Cursor prompts
• Claude prompts
• audit prompts
• scaffold prompts
• refactor prompts

We are intentionally using a multi-repo strategy because this product needs:

• isolated ownership
• independent releases
• permission boundaries
• lower CI noise
• clearer architecture boundaries
• easier scaling for many agents
• cleaner shared package versioning

A monorepo would create:

• release coupling
• team interference
• slower pipelines
• unclear repo boundaries
• unnecessary coordination for unrelated changes

flowchart TD
    subgraph Governance
        DOCS[aief-docs]
        ARCH[aief-architecture]
        STD[aief-standards]
        PROMPTS[aief-prompts]
    end

    subgraph Infra
        INFRA[aief-infra]
        GHA[aief-github-actions]
    end

    subgraph Shared
        TYPES[aief-types]
        AGENTSDK[aief-agent-sdk]
        AUTHSDK[aief-auth-sdk]
        WORKFLOWSDK[aief-workflow-sdk]
        UIKIT[aief-ui-kit]
        TOKENS[aief-design-tokens]
        ICONS[aief-icons]
        BOTS[aief-bot-assets]
    end

    subgraph Platform
        SHELL[aief-shell]
        MARKET[aief-marketplace]
        CONTROL[aief-control-center]
        ADMIN[aief-admin-console]
        IDENTITY[aief-identity]
    end

    subgraph Agents
        FRONTO[aief-fronto]
        BACKO[aief-backo]
        DESIGNO[aief-designo]
        DEVOPSY[aief-devopsy]
        TESTO[aief-testo]
        AUTOMO[aief-automo]
        STACKO[aief-stacko]
    end

    TOKENS --> UIKIT
    ICONS --> UIKIT
    TYPES --> AGENTSDK
    TYPES --> AUTHSDK
    TYPES --> WORKFLOWSDK

    TYPES --> SHELL
    TYPES --> MARKET
    TYPES --> CONTROL
    TYPES --> ADMIN
    TYPES --> IDENTITY

    AGENTSDK --> SHELL
    AGENTSDK --> MARKET
    AGENTSDK --> CONTROL

    AUTHSDK --> SHELL
    AUTHSDK --> ADMIN
    AUTHSDK --> IDENTITY

    WORKFLOWSDK --> CONTROL

    UIKIT --> SHELL
    UIKIT --> MARKET
    UIKIT --> CONTROL
    UIKIT --> ADMIN

    BOTS --> FRONTO
    BOTS --> BACKO
    BOTS --> DESIGNO
    BOTS --> DEVOPSY
    BOTS --> TESTO
    BOTS --> AUTOMO
    BOTS --> STACKO

    TYPES --> FRONTO
    TYPES --> BACKO
    TYPES --> DESIGNO
    TYPES --> DEVOPSY
    TYPES --> TESTO
    TYPES --> AUTOMO
    TYPES --> STACKO

    AGENTSDK --> FRONTO
    AGENTSDK --> BACKO
    AGENTSDK --> DESIGNO
    AGENTSDK --> DEVOPSY
    AGENTSDK --> TESTO
    AGENTSDK --> AUTOMO
    AGENTSDK --> STACKO

    UIKIT --> FRONTO
    UIKIT --> BACKO
    UIKIT --> DESIGNO
    UIKIT --> DEVOPSY
    UIKIT --> TESTO
    UIKIT --> AUTOMO
    UIKIT --> STACKO

    DOCS -. references .-> SHELL
    DOCS -. references .-> FRONTO
    DOCS -. references .-> BACKO
    DOCS -. references .-> DESIGNO
    ARCH -. governs .-> SHELL
    ARCH -. governs .-> MARKET
    ARCH -. governs .-> CONTROL
    ARCH -. governs .-> FRONTO
    ARCH -. governs .-> BACKO
    ARCH -. governs .-> DESIGNO
    STD -. enforces .-> SHELL
    STD -. enforces .-> FRONTO
    STD -. enforces .-> BACKO
    STD -. enforces .-> DESIGNO
    GHA -. reusable workflows .-> SHELL
    GHA -. reusable workflows .-> FRONTO
    GHA -. reusable workflows .-> BACKO
    GHA -. reusable workflows .-> DESIGNO
    INFRA -. deployment and envs .-> SHELL
    INFRA -. deployment and envs .-> MARKET
    INFRA -. deployment and envs .-> CONTROL
    INFRA -. deployment and envs .-> ADMIN

governance  -> references all, governs all
infra       -> supports all
shared      -> can be used by platform and agents
platform    -> can depend on shared
agents      -> can depend on shared
platform    -> may consume agent manifests
agents      -> must NOT depend on platform internals
shared      -> must NOT depend on platform repos
shared      -> must NOT depend on agent repos
agent repos -> must NOT depend on other agent repos directly unless explicitly approved

Can depend on:

• aief-types
• aief-agent-sdk
• aief-ui-kit
• aief-auth-sdk
• aief-workflow-sdk
• aief-design-tokens
• aief-icons

Must not:

• embed agent-specific private business logic
• tightly couple to one specific agent implementation
• duplicate shared contracts

Can depend on:

• aief-types
• aief-agent-sdk
• aief-ui-kit
• aief-design-tokens
• aief-icons
• aief-bot-assets
• aief-workflow-sdk where relevant

Must not:

• depend directly on platform application internals
• duplicate shared types or runtime lifecycle logic
• tightly couple to another agent repo

Can depend on:

• other shared repos only when justified and documented

Must not:

• depend on platform repos
• depend on agent repos

A core principle of this organization is manifest-driven agent integration.

Agents should publish metadata like:

{
  "id": "fronto",
  "slug": "fronto",
  "name": "Fronto",
  "title": "Frontend Developer",
  "version": "1.0.0",
  "category": "engineering",
  "description": "Builds clean, responsive, production-ready interfaces.",
  "ownerTeam": "agent-fronto-team",
  "status": "active",
  "capabilities": [
    "component-generation",
    "responsive-fix",
    "accessibility-audit"
  ],
  "entry": "/agents/fronto",
  "visibility": "public",
  "pricingTier": "pro"
}

This allows:

• aief-shell to discover agents without hardcoding them
• aief-marketplace to display agent cards from manifests
• aief-control-center to reason about agent metadata
• aief-admin-console to control availability and visibility

• app surfaces
• page routing
• product-level flows
• system dashboards
• shell layout
• admin flows
• org-level interactions

• agent-specific capability definitions
• prompts
• workflows
• manifests
• agent assets and content
• examples
• evaluation rules

• UI consistency
• runtime contracts
• common interfaces
• theme system
• icons
• bot assets
• reusable libraries

• deployment setup
• environment patterns
• CI/CD templates
• quality gates
• release automation

• architecture decisions
• standards
• docs
• prompt assets
• organizational engineering guidance

Every repo must have a clear owner team and CODEOWNERS coverage.

Example:

* @ai-employee-force/platform-core
/docs/ @ai-employee-force/docs-team
/.github/ @ai-employee-force/devops-team
/src/lib/contracts/ @ai-employee-force/platform-agent-runtime

Agent repo example:

* @ai-employee-force/agent-fronto-team
/docs/ @ai-employee-force/docs-team
/manifest/ @ai-employee-force/platform-agent-runtime @ai-employee-force/architecture-team
/.github/ @ai-employee-force/devops-team

Each major repo should be able to release independently.

Examples:

• Fronto can ship new capabilities without blocking Shell
• UI Kit can version new components without forcing immediate platform deployment
• Bot assets can evolve without editing application logic

Shared packages should follow semantic versioning and publish clean changelogs.

• app repos: owning team + platform review when needed
• shared repos: owning shared team + architecture/runtime review
• auth and infra repos: stricter security review

The following should stay centralized:

• shared TypeScript contracts → aief-types
• agent runtime helpers → aief-agent-sdk
• auth/session utilities → aief-auth-sdk
• workflow abstractions → aief-workflow-sdk
• reusable UI components → aief-ui-kit
• design tokens → aief-design-tokens
• icons → aief-icons
• bot visuals → aief-bot-assets
• engineering rules → aief-standards
• architecture decisions → aief-architecture

1. Shell becoming a dumping ground for all agent logic
2. Every repo inventing its own types
3. Every team building its own UI system
4. Shared repos depending on app repos
5. Agent repos tightly depending on platform internals
6. Hardcoded agent registration everywhere
7. Unowned repos with no CODEOWNERS
8. Infra scripts duplicated in random repos
9. Architecture decisions living only in chat history
10. Prompts and AI development assets scattered across personal notes

Start with these first:

• aief-shell
• aief-fronto
• aief-backo
• aief-designo
• aief-ui-kit
• aief-agent-sdk
• aief-types
• aief-bot-assets
• aief-infra
• aief-docs
• aief-architecture

Why:

• enough to build a real platform host
• enough to build 3 real agents
• enough to enforce shared contracts and UI
• enough to set architecture and infra discipline early

Later add:

• aief-marketplace
• aief-control-center
• aief-admin-console
• aief-identity
• aief-auth-sdk
• aief-workflow-sdk
• aief-icons
• aief-standards
• aief-prompts
• more agents

Every repo should include, where applicable:

• README.md
• CODEOWNERS
• .github/pull_request_template.md
• issue templates
• CONTRIBUTING.md
• SECURITY.md
• CHANGELOG.md
• CI workflow
• clear ownership
• release expectations
• dependency rules

• branch protection on main
• required PR reviews
• CODEOWNERS review for protected paths
• lint/test/build checks
• semantic versioning for publishable packages
• documented dependency boundaries
• secret scanning
• environment separation
• reproducible CI/CD workflows
• architecture review for foundational changes

Think of the organization like this:

• Platform = the operating surfaces
• Agents = the AI employees
• Shared = the reusable foundation
• Infra = the machinery that runs everything
• Governance = the rules, architecture, and documentation that keep the whole system healthy

This structure gives AI Employee Force the ability to become:

• an enterprise platform
• a scalable multi-agent product
• a multi-team engineering organization
• a cleanly governed code ecosystem
• a product with reusable internal standards and assets
• a system that can grow from 3 agents to 30+ without collapsing into chaos

AI Employee Force is organized as a multi-repo GitHub organization because the product requires:

• multiple platform surfaces
• many independently evolving AI employees
• centralized shared libraries
• disciplined infra and CI/CD
• documented architecture and standards

This model lets us move fast without losing structure.