Multi-parent / mixin profile inheritance

[psenger]

The Problem

Agent-OS's profile system uses single-parent inheritance — each profile has exactly one inherits_from in config.yml. For projects that fit cleanly into one technology stack, this works well.

Real-world projects often don't. A fullstack application with a React frontend and a FastAPI backend needs standards from two separate profile branches at once. Right now there's no native way to express that, so you end up reaching for workarounds that technically work but leave the setup implicit and brittle.

This is related to [#200](#200), which proposes a similar concept from the install script side (--mixins propel-auth,prisma). This discussion focuses on the config representation side of the same problem — how multi-profile intent gets encoded in config.yml so tooling can understand and enforce it.

Why Single-Parent Falls Short

Consider a monorepo or fullstack project:

• The frontend needs TypeScript conventions, React patterns, and frontend testing rules
• The backend needs Python conventions, FastAPI patterns, and async error handling rules
• Both sides share org-wide base standards

None of those concerns belong to a single profile lineage. Forcing them into one inherits_from chain means either creating bespoke composite profiles for every combination, or silently dropping standards from one side.

Current Workarounds and Their Costs

Option A — Composite leaf profile: Manually copy standards from multiple source profiles into a dedicated composite directory. Explicit, but it duplicates files, drifts as source profiles evolve, and requires manual upkeep whenever an upstream profile changes.

Option B — Sequential install + manual cp: Install the primary profile via project-install.sh, then copy standards from a second profile into agent-os/standards/. Fragile — a second run of project-install.sh overwrites everything — and the layering is invisible in config.yml.

Option C — /discover-standards after install: Let the agent infer standards for the secondary language from the codebase. Useful when the secondary stack is genuinely project-specific, but not the right fit when the standards already exist in a known profile.

All three produce a working setup. None of them encode the intent ("this project uses both of these profiles") in a way that tooling can understand or enforce.

Proposed Change

Allow inherits_from to accept a list:

profiles:
  fullstack-react-fastapi:
    inherits_from:
      - frontend-react
      - backend-fastapi

Resolution order (leftmost wins on conflict) would keep the behavior predictable. A separate mixins: key is another option — it makes the additive intent explicit without touching the existing inherits_from semantics, and would align naturally with the install-time --mixins flag proposed in [#200](#200).

Questions for the Maintainers

• Is multi-parent inheritance something you have considered or deliberately avoided?
• If a mixins: approach is preferred, are there constraints on how conflict resolution should work?
• Is there an alternative design that achieves the same goal within the current architecture?
• Is it worth coordinating this with [#200](Project Mixins #200) so the config representation and the install interface land consistently?

Happy to open a PR if the direction looks right. Thanks for the project — it has meaningfully improved consistency across how our AI agents operate.