APM-Packages/apm-omos-agent-teams-v3.md

# APM, Agent-Teams und das kleine Problem namens Realität

## Wie APM-Packages um Agent Team-Empfehlungen erweitert werden können – mit oh-my-opencode-slim als erstem konkretem Target.

<img alt="SNES-Cartridge in klassischem Grau mit lila Etikett. Das Etikett zeigt den Text &quot;Tour Planer Agent 3000&quot; in fettem, retro-weißen und gelben Schriftzug. Die Cartridge ist leicht nach rechts geneigt, mit subtiler Reflexion auf der Kunststoffoberfläche. Neutraler, sauberer Hintergrund." src="./snes.jpg" title="Tour Planer Agent 3000 SNES Cartridge" width="480"/>

Ein Austauschformat so selbsterklärend wie in die Videospiele der 90er. Einfach Einlegen und Abspielen. Aktuell hat diese Vision mit der Realität des AI-Agenten-Ökosystems wenig zu tun. Nur die Gefahr des Vendor-Lock-Ins bleibt bestehen.
Heute beginnt das Abenteuer zunächst als Textadventure.
> Was willst du tun? (Instruktionen)
> 
> Wie soll es erledigt werden? (Skills)
> 
> Womit soll es erledigt werden? (Werkzeuge, MCP-Abhängigkeiten)
> 
> Wie soll das Agenten-Team zusammengesetzt sein?
> 
> Welche Modellkonfiguration sollen die Agenten erhalten? (Modell, Variante, Temperature, … pro Subagent)
> 
> Welche Untermenge der Werkzeuge erhalten die jeweiligen Agenten? (MCP-per-Subagent)
> 
> Welches Orchestrierungsmuster soll verwendet werden? 

Was folgt, ist der klassische _programmer Move_: Man automatisiert (mittlerweile AI-unterstützt) in nur 10 Stunden erfolgreich eine Aufgabe die man händisch in 10 Minuten hätte erledigen können.
Selbstverständlich ist all das praktisch nicht portabel, denn will man seinen mühsam definierten Workflow mit Freunden und Kollegen teilen muss
alles passen. Welcher Harness soll verwendet werden? Sind die Modelle verfügbar und falls nein, kann ich sie substituieren? ...

## Harnesskonfiguration
<img src="./homer.jpg" width="300" style="margin:1em;"/>

### Kann das nicht jemand anderes erledigen?

Bevor es apt, yum oder pacman gab, war Software-Installation unter Unix vor allem eins: Handarbeit. Man lud sich den Quellcode als Tarball herunter, entpackte ihn irgendwo, konfigurierte, tippte make und hoffte auf das Beste.

Bevor es Docker gab, war das Ausrollen von Software ein heilloses Durcheinander aus Versionskonflikten, fehlenden Bibliotheken und dem klassischen _„Runs on my Machine“_.

Genau das machen wir heute mit Agenten-Frameworks. Wir kopieren Prompt-Templates per Hand in `.codex/` oder `.opencode/` Ordner, passen JSON-Dateien an und beten, dass das verwendete Modell die System-Prompts versteht.
Ein Package soll mehr sein als ein Ordner voller Prompts. Wenn ich ```apm install <package>``` ausführe, will ich nicht nur Dateien in `.opencode/` oder `.codex/` kopiert bekommen – ich will ein funktionierendes Setup,
das weiß, wie es arbeiten soll. Welche Rollen braucht diese Aufgabe? Welcher Agent recherchiert, welcher schreibt, welcher misstraut? Und welches Modell darf welche Rolle übernehmen, ohne dass ich das nach jeder Installation 
von Hand in einer Config zurechtbastle? Kann ich nicht einfach einen ACP-Client meiner Wahl auf meinen Agenten richten und mich darauf verlassen, dass MCPs, Skills, Dependencies, Orchestrierung usw. mit dem Auschecken eines Pakets bereits erledigt sind?

```mermaid
graph LR
    subgraph Package Registry
        A[Skills] --> B[Package]
        C[Instructions] --> B
        D[MCP-Abhängigkeiten] --> B
    end

    subgraph Bridge
        B -->|deklarative Empfehlung| E[Adapter]
    end

    subgraph Harness
        E --> F[Agenten-Team]
        E --> G[Modellkonfiguration]
    end

    style B fill:#f9f,stroke:#333
    style E fill:#bbf,stroke:#333
```
> Ein Package Registry liefert Skills, Instructions, MCP-Abhängigkeiten und eine deklarative Empfehlung für ein Agenten-Team. Ein Harness-spezifischer Adapter übersetzt diese Empfehlung in die lokale Team- und Modellkonfiguration.


## Das Ökosystem heute
<img src="/incompatible.jpg" width="400"  style="margin:1em;" />

Der Agenten-Stack entwickelt sich gerade mit der Geschwindigkeit eines explodierenden Werkzeugschuppens. Jeden Monat erscheint ein neues Manifest, ein neues Plugin-Format oder eine neue Orchestrierungsebene. Alles löst einen legitimen Teil des Problems. Fast nichts passt nahtlos zusammen.
Das ist kein Vorwurf. Es ist der normale Zustand eines jungen Ökosystems. Der interessante Teil beginnt dort, wo die bestehenden Stücke bereits ausreichen, um eine sinnvolle Brücke zu bauen.


Die vorhandenen Formate lassen sich grob in fünf Gruppen einteilen.

| Ebene | Beispiele | Zuständigkeit |
|---|---|---|
| Portable Komponenten | [Agent Plugins](https://agent-plugins.org/) | Skills und MCP-Server verteilen |
| Dependency Management | [APM](https://microsoft.github.io/apm/) | Packages, Lockfile, Policies, Deployment |
| Team-Komposition | [Spawnfile](https://github.com/noopolis/spawnfile), Harness-Configs | Rollen, Delegation, Agentenbeziehungen |
| Runtime-Profile | [oh-my-opencode-slim Presets](https://ohmyopencodeslim.com/community-presets) | Modelle und Optionen je Agent |
| Governance | [Agent Manifest](https://agent-manifest-spec.org/) | Identität, Grenzen, Verantwortung, Auditierbarkeit |

Was fehlt, ist ein allumfassendes YAML-Format.
## Ein paar Worte zu CrewAI
<img alt="https://xkcd.com/927/" src="./standards_2x.png" title="https://xkcd.com/927/" width="320"/>

One Standard to rule them all? Ja genau das scheinen sich die Entwickler von [CrewAI](https://crewai.com/) gedacht zu haben und tatsächlich: "CrewAI is rapidly becoming the standard for production-ready agentic automation". So steht es jedenfalls auf ihrer Website wobei >50.000 GitHub Sterne zeigen, dass das Projekt durchaus über Momentum verfügt. 
CrewAI löst die fehlende Standardisierung nicht durch Übersetzung zwischen Harnessen, sondern indem es die komplette Ausführungsschicht selbst besitzt: Agenten, Tasks, Tool-Aufrufe, State, Prozesse und Delegation laufen in der CrewAI-Runtime.

Damit scheidet es für unsere weiteren Überlegungen allerdings aus, denn CrewAI integriert die Welt in eine Runtime und nicht umgekehrt. Unser Ziel ist ein Format zu finden, dessen Pakete sich in die vorhandene Welt integrieren.

### Agent Plugins
[Agent Plugins 1.0](https://agent-plugins.org/) definiert ein bewusst kleines, portables Plugin-Format. Im Kern enthält ein Plugin eine `plugin.json` und kann Skills sowie MCP-Server bereitstellen. Erweiterungen sind möglich, müssen aber im `extensions`-Block über einen Reverse-Domain-Namespace isoliert werden.
Das ist sehr gut für Interoperabilität. Ein Skill bleibt ein Skill. Ein MCP bleibt ein MCP. Der Standard versucht nicht, die Laufzeit eines jeden Agentenframeworks zu regieren.
Offen bleiben jedoch Dependencies, getestete Versionen, Teamrollen, Modellprofile und die Aktivierung im konkreten Harness.
### APM
[APM](https://microsoft.github.io/apm/) besetzt die nächste Ebene: Package- und Dependency-Management für Agent-Kontext.
Ein APM-Manifest kann Abhängigkeiten auf andere APM-Packages, MCP-Server und LSP-Server beschreiben. APM verwaltet Auflösung, Lockfile und Installation. Über Targets kompiliert es Primitives in Harness-spezifische Dateien. Das native `opencode`-Target installiert Skills, Agents und Commands in die passenden `.opencode/`-Pfade.

```yaml
name: acme/research-assistant
version: 1.0.0
type: hybrid

targets:
  - opencode
  - omos

dependencies:
  apm:
    - acme/base-engineering
  mcp:
    - name: repository-search
      registry: false
      transport: stdio
      command: repository-search-mcp
      tools: [search_code, read_file]
```

APM beantwortet damit: Welche Artefakte gehören zusammen? Welche Versionen wurden zusammen getestet? Welche MCPs werden benötigt? Wohin werden Skills und Instructions installiert?

Was APM aktuell nicht standardisiert beschreibt, ist Team-Semantik: Rollen, Delegation, Modell-Empfehlungen und Aktivierung eines Team-Profils.

### Spawnfile

[Spawnfile](https://github.com/noopolis/spawnfile) adressiert die Teamachse. Agenten und Teams können deklarativ mit Rollen, Zuständigkeiten, Kommunikationswegen und Subagenten beschrieben werden. Die offene Stelle liegt bei Dependencies und Verteilung: Ein Team-Manifest installiert keine versionierten Skills, MCPs und Policies. Gültige Ziele sind momentan
Spawnfile v0.1 ist ausdrücklich für autonome, langlebige Agent-Runtimes gedacht. Spawnfile listet OpenCode als Runtime – aber mit Status exploratory: Kein Adapter, kein generiertes opencode.json, kein `.opencode/`. Tatsächlich wird in v0.1 für keine Runtime ein natives Team-Artifact compiliert; Teams degradieren immer zu Kontext-Dokumenten in Agent-Workspaces.

### Oh My Opencode Slim
<img src="./oh-my-opencode-slim.png" title="oh-my-opencode-slim" width="520"/>

## Die wilde Welt der Agent-Harnesses

Wenn es um Multi-Agent-Orchestrierung geht, sieht die aktuelle Landschaft aus wie ein Experimentierfeld nach einem Chemieunfall. Jeder Harness hat seine eigene Vorstellung davon, wie Subagenten funktionieren sollten – und keine davon ist mit den anderen kompatibel.

Claude Code kennt Custom Subagents als Markdown-Dateien und experimentiert mit Agententeams, bei denen mehrere Claude-Instanzen über eine gemeinsame Task-List kommunizieren. GitHub Copilot definiert Custom Agents als SDK-Konfiguration mit TypeScript oder Python und bietet Fleet Mode für parallele Ausführung. Codex setzt auf ein Coordinator-Pattern, bei dem ein Hauptagent Tasks an spezialisierte Subagents delegiert. oh-my-opencode-slim wiederum arbeitet mit Presets und Custom Agents, die zur Laufzeit umgeschaltet werden können.

Das Ergebnis: Vier verschiedene Formate, vier verschiedene Delegationsmechanismen, vier verschiedene Wege, Modelle und MCPs pro Agent zu konfigurieren. Niemand hat sich auf ein gemeinsames Protokoll geeinigt. Jeder baut sein eigenes Ding.

| Harness             | Subagenten-Typ               | Team-Unterstützung                 | Modell pro Agent  | MCP pro Agent          | Skill pro Agent     | Delegation                      |
| ------------------- | ---------------------------- | ---------------------------------- | ----------------- | ---------------------- | ------------------- | ------------------------------- |
| oh-my-opencode-slim | Custom Agents + Built-in     | ❌ Nein (nur Presets)               | ✅ Ja (pro Preset) | ✅ Ja (mcps-Array)      | ✅ Ja (skills-Array) | Automatisch via Orchestrator    |
| Claude Code         | Custom Subagents (.md-Files) | ✅ Ja (Agent Teams, experimental)   | ✅ Ja (model-Feld) | ✅ Ja (mcpServers-Feld) | ✅ Ja (skills-Feld)  | Automatisch + explizit          |
| GitHub Copilot      | Custom Agents (SDK)          | ⚠️ Teilweise (Fleet Mode)          | ✅ Ja (model-Feld) | ✅ Ja (mcpServers-Feld) | ✅ Ja (skills-Feld)  | Automatisch via Intent-Matching |
| Codex               | Multi-Agent V2               | ⚠️ Teilweise (Coordinator-Pattern) | ✅ Ja              | ✅ Ja                   | ✅ Ja                | Explizit via Coordinator        |

Genau dafür hat Microsofts [APM das targets-Feld](https://microsoft.github.io/apm/reference/targets-matrix/) vorgesehen. Es ist die ehrliche Antwort auf die Frage: „Wie deployen wir Agent-Kontext in eine Welt, in der jeder Harness seine eigenen Regeln hat?" Die Antwort lautet: Wir definieren Targets für jeden Harness und übersetzen das Package in das jeweilige Format.

Oder, weniger diplomatisch: **Weil sich kein einziger der großen Player die Mühe gemacht hat, mit den anderen zu reden, bevor sie ihr Agenten-System gebaut haben, müssen wir jetzt für jeden von ihnen einen eigenen Übersetzer schreiben**. 

Claude Code macht es so. Copilot macht es anders. Codex hat wieder eine eigene Vorstellung. Und der Rest? Macht sein eigenes Ding. Das targets-Feld ist damit ein Eingeständnis: Niemand wird sich einigen. Also bauen wir Brücken zu allen.
Stand August 2026 sieht APM laut Schema folgende Werte als Ziele vor: `copilot`, `claude`, `grok-build`, `cursor`, `opencode`, `codex`, `gemini`, `antigravity`, `windsurf`, `kiro`, `agent-skills`. 

Damit klafft hier bereits die erste Lücke, denn **was fehlt, ist ein allumfassendes YAML-Format.**
Wir können also warten bis dieser Standard definiert ist, oder wir bauen uns selbst eine kleine Kompositionsschicht. Für Oh My Opencode Slim nenne ich diesen Adapter im Folgenden **`omos`**. `omos` ist dabei ein Design für eine Erweiterung bzw. ein Sidecar-Tool. Es ist heute kein offiziell eingebautes APM-Target.

[//]: # ()
[//]: # (```mermaid)

[//]: # (flowchart LR)

[//]: # (    AP[Skills und MCPs] -->|Agent Plugins| PK[Package-Inhalt])

[//]: # (    APM[Dependencies, Lockfile, Installation] -->|APM| PK)

[//]: # (    SF[Rollen und Teamstruktur] -->|Spawnfile| TM[Team-Modell])

[//]: # (    PK -. fehlende Verbindung .-> TM)

[//]: # (```)

[//]: # ()


```mermaid

flowchart LR

    AP[Skills und MCPs] -->|Agent Plugins| PK[Package-Inhalt]

    APM[Dependencies, Lockfile, Installation] -->|APM| PK

    SF[Rollen und Teamstruktur] -->|Spawnfile/OMOS Community Presets| TM[Team-Modell]

    OMOS[oh-my-opencode-slim] -->|OMOS Community Presets| RT[aktive Runtime]

    PK -. fehlende Verbindung .-> TM

    TM -. fehlende Verbindung .-> RT

```


## Die APM-OMOS-Idee

[Oh My Opencode Slim](https://ohmyopencodeslim.com/) ist ein schlankes, optimiertes Open-Source-Plugin für OpenCode, das auf Multi-Agenten-Orchestrierung ausgelegt ist und sitzt nahe an der Runtime. Sein Preset-System kann je Agent Modell, Temperatur, Variante und provider-spezifische Optionen setzen. Presets werden in der Config definiert und über den `/preset`-Befehl ausgewählt.

```jsonc
{
  "presets": {
    "deep-review": {
      "orchestrator": { "model": "ollama/qwen3.6:35b-a3b-q4_K_M" },
      "oracle": { "model": "ollama/qwen3.6:35b-a3b-q4_K_M", "variant": "thinking" },
      "librarian": { "model": "ollama/qwen3.5:9b" }
    }
  }
}
```

[//]: # (Wichtig für das Verständnis, wie die Aktivierung tatsächlich funktioniert:)

[//]: # ()
[//]: # (1. Der `/preset`-Befehl öffnet einen TUI-Manager. **Apply** schreibt ausschließlich den Namen des gewählten Presets in die Config-Datei.)

[//]: # (2. Die Agent-Registry wird bewusst **nicht** mid-session umgeschaltet. Ein Hot-Swap würde Kontext truncieren, laufende Subagents auf veraltete Definitionen lassen und Tool-Verfügbarkeit verschieben.)

[//]: # (3. Erst nach einem **Reload von OpenCode** &#40;oder dem Start einer neuen Konversation&#41; greift das Preset.)

[//]: # (4. Beim Laden angewendet werden `model`, `temperature`, `variant` und provider-spezifische `options`. Änderungen an `prompt`, `skills`, `mcps` oder `displayName` benötigen ohnehin einen Neustart.)

[//]: # ()
[//]: # (Ein Neustart von opencode ist also by Design. Für Team-Wechsel zwischen Aufgaben ist das vollkommen ausreichend – und es hält die Runtime vorhersehbar.)

Das beantwortet die Frage, wie unterschiedliche Rollen unterschiedliche Modellprofile erhalten. Es fehlt die Herkunft: Welches Package empfiehlt dieses Team? Welche Skills und MCPs gehören dazu? Welche Version wurde getestet?


Ein APM-Package bleibt Source of Truth für Skills, Instructions, MCP-Abhängigkeiten, Versionen, Dependency-Closure und Policies. Zusätzlich enthält es ein Team-Profil als Empfehlung für Harness-Adapter.

```yaml
schema: acme.team-profile/v1
id: acme.document-research
description: Team-Profil für Recherche, Erstellung und Qualitätsprüfung quellenbasierter Dokumente.

roles:
  - id: orchestrator
    purpose: Zerlegt Aufgaben, delegiert, integriert Ergebnisse
    model_class: strong-generalist
  - id: researcher
    purpose: Sammelt und bewertet Quellen
    model_class: fast-research
    capabilities:
      mcps: [websearch, openviking]
      skills: [job-matching]
  - id: writer
    purpose: Erstellt strukturierte Dokumententwürfe
    model_class: strong-writing
    capabilities:
      mcps: [sharelatex]
      skills: [application-writing]
  - id: checker
    purpose: Prüft Quellenbezug, Konsistenz und Vollständigkeit
    model_class: high-reasoning
    capabilities:
      mcps: [openviking]
      skills: [application-review]
```

Das Profil verwendet Modellklassen wie `high-reasoning` statt konkreter Modell-IDs. Der Nutzer hinterlegt in einer lokalen Mapping-Tabelle, welche Modell-IDs für welche Modellklasse verwendet werden sollen.

```yaml
# ~/.config/apm-team/model-mapping.yaml
model_classes:
  strong-generalist: ollama/qwen3.6:35b-a3b-q4_K_M
  fast-research: ollama/qwen3.5:9b
  strong-writing: ollama/qwen3.6:35b-a3b-q4_K_M
  high-reasoning: ollama/qwen3.6:35b-a3b-q4_K_M
```

Diese Tabelle ist bewusst trivial. Sie ist kein intelligentes Routing und keine Policy-Engine. Der Nutzer entscheidet einmal, welches Modell seine Klasse „schnelle Recherche" oder „starkes Reasoning" erfüllt – und der Adapter übersetzt nur noch nach.

## Was `omos` macht

`omos` ist der Übersetzer zwischen Team-Profil und oh-my-opencode-slim. Er liest installierte APM-Packages, findet Team-Profile, schlägt Modellklassen gegen die lokale Mapping-Tabelle nach und generiert Presets unter einem entsprechenden Namespace für das Projekt.

```mermaid
flowchart TD
    P[APM Package: team-profile.yaml] --> O[omos liest]
    M[~/.config/apm-team/model-mapping.yaml] --> O
    O -->|Prüfe| X{Alle Modellklassen gemappt?}
    X -->|Nein| E[Fehler: fehlendes Mapping für Rolle Y]
    X -->|Ja| G[Generiere OMOS-Preset mit konkreten Modell-IDs]
    G --> V[Validiere: Modelle in OMOS verfügbar?]
    V -->|Nein| F[Fehler: Modell Z nicht im OMOS-Setup]
    V -->|Ja| C[Schreibe .opencode/oh-my-opencode-slim.json]
    C --> D[Fertig]
```

`omos` rät nicht. Er übersetzt deterministisch:

1. Team-Profil lesen (Modellklassen + MCP/Skill-Capabilities).
2. Lokale Mapping-Tabelle laden (Modellklasse → konkrete Modell-ID).
3. OMOS-Preset generieren (konkrete Modell-IDs + MCP/Skill-Allowlists).
4. Validieren: Sind die Modelle im OMOS-Setup verfügbar?
5. Preset in `.opencode/oh-my-opencode-slim.json` schreiben.

## Mehrere Packages, ein Projekt

Jedes Profil erhält eine globale, stabile ID wie `acme.job-applications`, `acme.security-audit` oder `acme.code-review`. `omos` merged Presets anhand dieser IDs. Das aktive Team wird nicht durch die letzte Installation gewählt.

```mermaid
flowchart LR
    A[Package: Job Applications] --> M[Preset Merge]
    B[Package: Security Audit] --> M
    C[Package: Code Review] --> M
    M --> P[Projekt-Preset-Registry]
    P --> U[Nutzer oder expliziter Workflow]
    U --> S[/preset acme-job-applications + Reload]
```

## Beispiel: Autobewerber als Team-Package

Ein Bewerbungsassistent eignet sich gut als Beispiel, weil er alle Ebenen gleichzeitig berührt: Web-Recherche, personenbezogene Daten (das Kandidatenprofil), Dokumentenproduktion in LaTeX, Qualitätsprüfung und Benachrichtigungen. Der Mechanismus bleibt derselbe für Code-Review, Sales Research, Compliance oder Incident Response.

Konkret arbeite ich hier mit einem real existierenden Setup: Das Package `job-application` bringt eine Skill für Stellenrecherche und maßgeschneiderte Bewerbungsunterlagen mit. Es nutzt zwei MCP-Server:

- **OpenViking** als Langzeitgedächtnis für das Kandidatenprofil (Skills, Erfahrungen, persönliche Daten)
- **ShareLaTeX** zur Erstellung und Kompilierung der Anschreiben und Lebensläufe

Dazu kommen OpenCodes native Tools für Web-Recherche (`websearch`, `webfetch`).

### Rollen und OMOS-Mapping

| Fachliche Rolle | OMOS-Rolle | Zweck |
|---|---|---|
| Koordination | `orchestrator` | Zerlegt Aufgaben, delegiert, integriert |
| Recherche | `librarian` (Alias `researcher`) | Sucht und bewertet Stellen |
| Schreiben | Custom Agent `writer` | Erstellt Anschreiben und Unterlagen |
| Prüfung | `oracle` (Alias `checker`) | Prüft Fakten, Ton, Vollständigkeit |
| Benachrichtigung | Custom Agent `notifier` | Informiert den Nutzer |

### Was OMOS tatsächlich begrenzen kann

OMOS bietet pro Agent zwei brauchbare Kontrollflächen:

1. **MCP-Zugriff** (`mcps`-Array)
2. **Skill-Zugriff** (`skills`-Array)

Beides kann je Agent in einem Preset als Allowlist formuliert werden. `[]` bedeutet keine Freigabe; bei Konflikten gewinnt die Verweigerung.

Das generierte OMOS-Preset für unser Beispiel sieht dann so aus:

```jsonc
{
  "$schema": "https://unpkg.com/oh-my-opencode-slim@latest/oh-my-opencode-slim.schema.json",
  "presets": {
    "acme-job-applications": {
      "orchestrator": {
        "model": "ollama/qwen3.6:35b-a3b-q4_K_M",
        "mcps": [],
        "skills": ["job-application"]
      },

      "librarian": {
        "displayName": "researcher",
        "model": "ollama/qwen3.5:9b",
        "mcps": ["websearch", "openviking"],
        "skills": ["job-application"]
      },

      "writer": {
        "model": "ollama/qwen3.6:35b-a3b-q4_K_M",
        "mcps": ["openviking", "sharelatex"],
        "skills": []
      },

      "oracle": {
        "displayName": "checker",
        "model": "ollama/qwen3.6:35b-a3b-q4_K_M",
        "variant": "thinking",
        "mcps": ["openviking"],
        "skills": []
      },

      "notifier": {
        "model": "ollama/gemma4:12b",
        "mcps": [],
        "skills": []
      }
    }
  }
}
```

Damit erhält der Researcher keinen ShareLaTeX-Zugang. Der Writer sieht keine Job-Suchtools, darf aber auf Profilfakten zugreifen und in ShareLaTeX arbeiten. Der Checker kann Fakten gegen das Profil prüfen, aber nichts produzieren oder senden. Der Notifier bekommt gar keine externen Zugriffe.

### Die wichtige Einschränkung

`mcps` und `skills` schützen nur den Zugriff auf genau diese zwei Ebenen. Die Aussage „der Agent darf niemals eine Bewerbung absenden" benötigt Verteidigung in mehreren Schichten:

| Schicht | Durchsetzung |
|---|---|
| OMOS-Rollenprompt | Klare Verhaltensregel: nie einreichen |
| OMOS MCP-Allowlist | Submission-MCP gar nicht zuweisen |
| MCP-Server selbst | Submission-Tool verlangt Approval-Token |
| Workflow-State | `submit` nur aus Zustand `user_approved` erlaubt |
| OpenCode-/Sandbox-Policy | Schreib-, Shell- und Browserrechte begrenzen |
| User Interface | Explizite, sichtbare Freigabe vor jeder Außenwirkung |

In unserem Beispiel existiert der Submission-Schritt schlicht nicht: Der Workflow endet bei kompilierten ShareLaTeX-Projekten und Projektlinks für den Nutzer. Die Bewerbung wird vom Menschen selbst abgeschickt. Damit ist die härteste Grenze bereits durch Architektur gezogen – nicht durch Prompt-Hoffnung.

Sobald man automatisches Absenden möchte (z. B. über ein Bewerbungsportal), braucht es einen eigenen Submission-MCP mit Approval-Token:

```text
notification-draft       → darf Entwurf erzeugen
notification-send        → braucht userApprovalId
application-submit       → braucht userApprovalId + applicationDraftId
```

Und im Backend:

```mermaid
sequenceDiagram
    participant C as Checker
    participant N as Notifier MCP
    participant U as Nutzer
    participant S as Submission MCP

    C->>N: createDraftNotification(applicationDraftId)
    N-->>U: Stelle gefunden, Entwurf geprüft
    U->>U: Prüft PDF und Fakten
    U->>S: approve(applicationDraftId)
    S-->>S: issue userApprovalId
    U->>S: submit(applicationDraftId, userApprovalId)
    S-->>U: Bewerbung eingereicht
```

Der Notifier kann dann technisch niemals eine Bewerbung absenden, weil er keinen Submission-MCP besitzt und das Submission-Backend einen vom Nutzer stammenden Freigabenachweis verlangt.

### Das Team-Profil

```yaml
schema: acme.team-profile/v1
id: acme.job-applications
description: Human-in-the-loop-Team zur Recherche, Vorbereitung und Prüfung individueller Bewerbungsunterlagen.

roles:
  - id: orchestrator
    purpose: Zerlegt Aufgaben, delegiert, integriert Ergebnisse
    model_class: strong-generalist
    capabilities:
      mcps: []
      skills: [job-application]

  - id: researcher
    purpose: Sucht und bewertet Stellenausschreibungen gegen das Kandidatenprofil
    omos_agent: librarian
    model_class: fast-research
    capabilities:
      mcps: [websearch, webfetch, openviking]
      skills: [job-application]

  - id: writer
    purpose: Erstellt auf Fakten basierende Anschreiben und Lebensläufe in ShareLaTeX
    omos_agent: custom
    model_class: strong-writing
    capabilities:
      mcps: [openviking, sharelatex]
      skills: []

  - id: checker
    purpose: Prüft Fakten, Ton und Vollständigkeit gegen das Profil
    omos_agent: oracle
    model_class: high-reasoning
    capabilities:
      mcps: [openviking]
      skills: []

  - id: notifier
    purpose: Informiert den Nutzer über fertige Entwürfe
    omos_agent: custom
    model_class: cheap-reliable
    capabilities:
      mcps: []
      skills: []
```

Die lokale Mapping-Tabelle:

```yaml
# ~/.config/apm-team/model-mapping.yaml
model_classes:
  strong-generalist: ollama/qwen3.6:35b-a3b-q4_K_M
  fast-research: ollama/qwen3.5:9b
  strong-writing: ollama/qwen3.6:35b-a3b-q4_K_M
  high-reasoning: ollama/qwen3.6:35b-a3b-q4_K_M
  cheap-reliable: ollama/gemma4:12b
```

Das generierte OMOS-Preset wurde oben bereits gezeigt. Die Aktivierung läuft dann so:

```bash
apm install tbi/APM-Packages
omos render --harness omos   # schreibt .opencode/oh-my-opencode-slim.json
opencode                      # Start lädt die Projekt-Config
```

Im TUI:

```text
/preset acme-job-applications
# Apply → schreibt Preset-Namen in die Config
# Reload OpenCode → Team ist aktiv
```

Der Nutzer erhält danach keine unsichtbare Bewerbungsmaschine. Er erhält ein explizit aktiviertes, nachvollziehbares Team mit klaren Zuständigkeiten.

## Wie das heute beginnen kann

Die Idee muss nicht auf eine APM-Spec-Änderung warten.

Ein erster Prototyp braucht nur drei Bausteine:

1. **Ein normales APM-Package**
   Skills, Instructions und MCP-Abhängigkeiten werden über APM installiert.

2. **Ein Team-Profil als zusätzliche Package-Datei**
   Zum Beispiel `team-profile.yaml`, mit versioniertem Schema und eindeutiger ID.

3. **Ein `omos` Sidecar-CLI**
   Es liest die installierten Packages, generiert namespacete OMOS-Presets und validiert Konflikte.

APM selbst muss dafür zunächst keine unbekannten Targets akzeptieren. Tatsächlich kennt das aktuelle Manifest nur einen festen Satz dokumentierter Targets; unbekannte Zielnamen führen zu einem Fehler.

Das Sidecar ist daher der pragmatische Anfang. Es kann als externes Tool reifen, Daten über realistische Nutzung liefern und später als offizieller APM-Adapter oder als Erweiterung im APM-Ökosystem landen.

## Der Kern

Die Idee lautet nicht: „APM wird jetzt ein Multi-Agent-Framework."

APM soll sein, was es gut kann: Package-Management für Agent-Kontext.

oh-my-opencode-slim soll sein, was es gut kann: konkrete Rollen, Modelle und Laufzeit-Presets verwalten.

Dazwischen liegt ein kleines, wertvolles Stück Infrastruktur:

> Ein APM-Package beschreibt nicht nur, welche Fähigkeiten installiert werden. Es kann auch erklären, welches Team diese Fähigkeiten sinnvoll verwendet.

Damit wird ein Package vom Ordner voller Skills zu einem reproduzierbaren Arbeitsmodell:

- versionierte Rollen;
- überprüfbare Tool-Zugriffe;
- lokale Modell-Policies;
- mehrere Teams pro Projekt;
- explizite Aktivierung;
- menschliche Freigabe an kritischen Grenzen.

Und das ist wesentlich nützlicher als ein weiterer „autonomer Agent", der nach drei Minuten Browserzugriff beschließt, dass er nun Personalabteilung spielen darf.