DBAdmin/agent.md

Architektura agenta

Poniżej Mermaid dla architektury hub-and-spoke z obrazka — wersja bez <br/>, żeby uniknąć błędu splitLineToFitWidth does not support newlines in the line.

flowchart LR
    Coordinator["Coordinator - routes and handles errors"]

    Research["Research agent"]
    Writer["Writer agent"]
    Coder["Coder agent"]
    Reviewer["Reviewer agent"]
    Summariser["Summariser agent"]
    Data["Data agent"]
    Planner["Planner agent"]

    Coordinator <--> Research
    Coordinator <--> Writer
    Coordinator <--> Coder
    Coordinator <--> Reviewer
    Coordinator <--> Summariser
    Coordinator <--> Data
    Coordinator <--> Planner

    classDef coordinator fill:#eeeaff,stroke:#8b7bd8,stroke-width:1.5px,color:#3f3a73;
    classDef agent fill:#ddf7f0,stroke:#7bb8a6,stroke-width:1.5px,color:#18584c;

    class Coordinator coordinator;
    class Research,Writer,Coder,Reviewer,Summariser,Data,Planner agent;

Wersja z opisem zasad z lewej strony jako osobne węzły:

flowchart LR
    Rules["Hub-and-spoke architecture - one coordinator at the center; subagents talk only to coordinator"]
    Ownership["Coordinator owns routing, context sharing, and error handling"]

    Coordinator["Coordinator - routes and handles errors"]

    Research["Research agent"]
    Writer["Writer agent"]
    Coder["Coder agent"]
    Reviewer["Reviewer agent"]
    Summariser["Summariser agent"]
    Data["Data agent"]
    Planner["Planner agent"]

    Rules --> Coordinator
    Ownership --> Coordinator

    Coordinator <--> Research
    Coordinator <--> Writer
    Coordinator <--> Coder
    Coordinator <--> Reviewer
    Coordinator <--> Summariser
    Coordinator <--> Data
    Coordinator <--> Planner

    classDef coordinator fill:#eeeaff,stroke:#8b7bd8,stroke-width:1.5px,color:#3f3a73;
    classDef agent fill:#ddf7f0,stroke:#7bb8a6,stroke-width:1.5px,color:#18584c;
    classDef note fill:#ffffff,stroke:#cccccc,stroke-width:1px,color:#222222;

    class Coordinator coordinator;
    class Research,Writer,Coder,Reviewer,Summariser,Data,Planner agent;
    class Rules,Ownership note;

I wersja najbardziej kompaktowa do dokumentacji:

flowchart TD
    Coordinator["Coordinator"]

    Coordinator --> Research["Research agent"]
    Coordinator --> Writer["Writer agent"]
    Coordinator --> Coder["Coder agent"]
    Coordinator --> Reviewer["Reviewer agent"]
    Coordinator --> Summariser["Summariser agent"]
    Coordinator --> Data["Data agent"]
    Coordinator --> Planner["Planner agent"]

    Research --> Coordinator
    Writer --> Coordinator
    Coder --> Coordinator
    Reviewer --> Coordinator
    Summariser --> Coordinator
    Data --> Coordinator
    Planner --> Coordinator

Kluczowa zasada z obrazka: nie rysujemy połączeń bezpośrednio między subagentami — wszystko idzie przez Coordinator.

flowchart TD
    Decompose["1. Decompose - Break task into subtasks"]
    Assess["2. Assess complexity - Which agents are needed?"]

    Simple["Single agent"]
    Moderate["2-3 agents in sequence"]
    Complex["Agents in parallel"]

    Aggregate["3. Aggregate results - Merge, rank, resolve conflicts"]
    Response["Final response"]

    Decompose --> Assess

    Assess -->|simple| Simple
    Assess -->|moderate| Moderate
    Assess -->|complex| Complex

    Simple --> Aggregate
    Moderate --> Aggregate
    Complex --> Aggregate

    Aggregate --> Response

1. You are a coordinator. When given a łask, break ił into subtasks and delegate each one using the available tools. Do not do the work yourself.

flowchart TD

    A["User Request"]

    B["1. Analyze Request"]
    C["Identify Goal"]
    D["Identify Constraints"]
    E["Identify Required Knowledge"]
    F["Identify Required Actions"]

    G["Break Into Subtasks"]

    H["Research Tasks"]
    I["Data Collection Tasks"]
    J["Analysis Tasks"]
    K["Decision Tasks"]
    L["Execution Tasks"]
    M["Communication Tasks"]

    N["Subtask List"]

    A --> B
    B --> C
    B --> D
    B --> E
    B --> F

    C --> G
    D --> G
    E --> G
    F --> G

    G --> H
    G --> I
    G --> J
    G --> K
    G --> L
    G --> M

    H --> N
    I --> N
    J --> N
    K --> N
    L --> N
    M --> N

2. Access complexity You are a coordinator. Use your judgment:

• Simple factual questions: use a single agent
• Multi-step tasks: delegate sequentially, passing results forward
• Independent subtasks: delegate in parallel a. Logika decyzyjna

flowchart TD

    A["Receive Task"]

    B["Analyze Task"]

    C{"Task Complexity?"}

    D["Single Agent"]
    E["Sequential Delegation"]
    F["Parallel Delegation"]

    G["Simple factual question"]

    H["Subtask 1"]
    I["Subtask 2"]
    J["Subtask N"]

    K["Independent Subtask 1"]
    L["Independent Subtask 2"]
    M["Independent Subtask N"]

    N["Aggregate Results"]

    O["Final Response"]

    A --> B
    B --> C

    C -->|Simple| D
    C -->|Multi-step| E
    C -->|Independent subtasks| F

    D --> G
    G --> N

    E --> H
    H --> I
    I --> J
    J --> N

    F --> K
    F --> L
    F --> M

    K --> N
    L --> N
    M --> N

    N --> O

Lub też inaczej

flowchart TD

    A["Task"]

    B{"Use your judgment"}

    C["Single Agent"]
    D["Sequential Agents"]
    E["Parallel Agents"]

    F["Simple factual question"]
    G["Multi-step task"]
    H["Independent subtasks"]

    I["Pass results forward"]
    J["Aggregate outputs"]

    K["Final response"]

    A --> B

    B --> F
    B --> G
    B --> H

    F --> C
    G --> D
    H --> E

    D --> I

    C --> J
    I --> J
    E --> J

    J --> K

3. Aggregate results You have received outputs from multiple agents. Combine them into a single coherent response. Resolve any conflicts by preferring the most specific data. Research output: ${results.research} Writing output: ${results.writing} Review feedback: ${results.review}

Dla etapu "3. Aggregate results" można opracować prompt bardziej formalnie i operacyjnie:

You are the Aggregator agent.

Your responsibility is to combine outputs from multiple agents into a single coherent response.

Instructions:

1. Review all agent outputs.
2. Identify overlapping information.
3. Remove duplicates and redundancy.
4. Resolve conflicts:
   - Prefer the most specific information.
   - Prefer data supported by evidence.
   - Prefer newer information when timestamps are available.
5. Integrate review feedback into the final result.
6. Preserve important details from every agent.
7. Produce one unified response.
8. Do not mention individual agents unless explicitly requested.
9. Do not perform additional research.
10. Do not introduce new facts not present in the inputs.

Inputs:

Research output:
${results.research}

Writing output:
${results.writing}

Review feedback:
${results.review}

Output:

A single consolidated response incorporating:
- validated research findings,
- improved writing structure,
- accepted review recommendations.

Diagram Mermaid dla tego kroku:

flowchart TD

    A["Research Output"]
    B["Writing Output"]
    C["Review Feedback"]

    D["Analyze Inputs"]

    E["Remove Duplicates"]
    F["Resolve Conflicts"]
    G["Apply Review Feedback"]
    H["Merge Information"]

    I["Unified Response"]

    A --> D
    B --> D
    C --> D

    D --> E
    E --> F
    F --> G
    G --> H

    H --> I

Jeżeli budujesz system typu Coordinator → Research → Writing → Review → Aggregate, to Aggregator jest ostatnim agentem przed zwróceniem odpowiedzi do użytkownika.

Architekura

Da się, ale ten obraz jest bardzo szczegółowy. Zamiast przepisywać wszystkie opisy agentów 1:1, proponuję najpierw odtworzyć strukturę organizacyjną, a potem ewentualnie rozbudować o opisy.

Na obrazku widzę 4 domeny:

• Engineering (Architect → Frontend, Backend, Security, QA, Release, Implementation)
• Marketing (Mouse → Content, Video Director, Scriptwriter, Designer, Video Editor, Asset Producer)
• Growth (Analyst → Funnels, Pricing, Retention, Analytics, Partnerships)
• Research (Oracle → Signals, Synthesis, Competitive, Customer Research, Product Research)

Mermaid:

flowchart LR

    CTO["Engineering Architect"]
    CMO["Marketing Mouse"]
    CGO["Growth Analyst"]
    CRO["Research Oracle"]

    CTO --> Frontend["Frontend"]
    CTO --> Backend["Backend"]
    CTO --> Security["Security"]
    CTO --> QA["QA"]
    CTO --> Release["Release"]
    CTO --> Implementation["Implementation"]

    CMO --> Content["Content"]
    CMO --> VideoDirector["Video Director"]
    CMO --> Scriptwriter["Scriptwriter"]
    CMO --> Designer["Designer"]
    CMO --> VideoEditor["Video Editor"]
    CMO --> AssetProducer["Asset Producer"]

    CGO --> Funnels["Funnels"]
    CGO --> Pricing["Pricing"]
    CGO --> Retention["Retention"]
    CGO --> Analytics["Analytics"]
    CGO --> Partnerships["Partnerships"]

    CRO --> Signals["Signals"]
    CRO --> Synthesis["Synthesis"]
    CRO --> Competitive["Competitive"]
    CRO --> Customer["Customer Research"]
    CRO --> Product["Product Research"]

    classDef lead fill:#222244,color:white,stroke:#aaa;
    classDef eng fill:#1f4e79,color:white;
    classDef mkt fill:#8c5e00,color:white;
    classDef growth fill:#5b3a8c,color:white;
    classDef research fill:#8c2f39,color:white;

    class CTO lead;
    class CMO lead;
    class CGO lead;
    class CRO lead;

    class Frontend,Backend,Security,QA,Release,Implementation eng;
    class Content,VideoDirector,Scriptwriter,Designer,VideoEditor,AssetProducer mkt;
    class Funnels,Pricing,Retention,Analytics,Partnerships growth;
    class Signals,Synthesis,Competitive,Customer,Product research;

Jeżeli to ma być do Twojego systemu agentowego (Coordinator → subagenci), to lepiej byłoby narysować to jako hierarchię agentów z ownerami, np.:

flowchart TB

    Coordinator["Coordinator Agent"]

    Coordinator --> Engineering["Engineering Architect<br/>Owner: CTO<br/>Designs systems and technical direction"]

    Coordinator --> Marketing["Marketing Mouse<br/>Owner: CMO<br/>Creates messaging and promotional assets"]

    Coordinator --> Growth["Growth Analyst<br/>Owner: CGO<br/>Optimizes acquisition, conversion and retention"]

    Coordinator --> Research["Research Oracle<br/>Owner: CRO<br/>Discovers signals, trends and opportunities"]


%% =======================
%% ENGINEERING
%% =======================

    Engineering --> Frontend["Frontend<br/>UI surfaces, dashboards, customer flows"]
    Engineering --> Backend["Backend<br/>APIs, integrations, business logic"]
    Engineering --> Security["Security<br/>Risk analysis, secrets, auth boundaries"]
    Engineering --> QA["QA<br/>Testing, validation, acceptance criteria"]
    Engineering --> Release["Release<br/>Deployment readiness and rollback planning"]
    Engineering --> Implementation["Implementation<br/>Feature delivery and execution"]


%% =======================
%% MARKETING
%% =======================

    Marketing --> Content["Content<br/>Storytelling, tutorials, launch narratives"]
    Marketing --> VideoDirector["Video Director<br/>Production planning and coordination"]
    Marketing --> Scriptwriter["Scriptwriter<br/>Ads, hooks and promo scripts"]
    Marketing --> Designer["Designer<br/>Visual identity and graphics"]
    Marketing --> VideoEditor["Video Editor<br/>Assembly, subtitles and rendering"]
    Marketing --> AssetProducer["Asset Producer<br/>Screenshots, demos and supporting assets"]


%% =======================
%% GROWTH
%% =======================

    Growth --> Funnels["Funnels<br/>Landing pages and conversion optimization"]
    Growth --> Pricing["Pricing<br/>Monetization and packaging strategy"]
    Growth --> Retention["Retention<br/>Engagement and churn reduction"]
    Growth --> Analytics["Analytics<br/>Traffic, revenue and experiment analysis"]
    Growth --> Partnerships["Partnerships<br/>Affiliates and strategic collaborations"]


%% =======================
%% RESEARCH
%% =======================

    Research --> Signals["Signals<br/>Trend discovery and market scanning"]
    Research --> Synthesis["Synthesis<br/>Converts findings into recommendations"]
    Research --> Competitive["Competitive<br/>Competitor tracking and positioning"]
    Research --> CustomerResearch["Customer Research<br/>Customer interviews and feedback"]
    Research --> ProductResearch["Product Research<br/>Feature validation and opportunity discovery"]


%% =======================
%% STYLES
%% =======================

    classDef coordinator fill:#EDE9FE,stroke:#7C3AED,color:#111;
    classDef engineering fill:#DBEAFE,stroke:#2563EB,color:#111;
    classDef marketing fill:#FEF3C7,stroke:#D97706,color:#111;
    classDef growth fill:#E9D5FF,stroke:#7E22CE,color:#111;
    classDef research fill:#FECACA,stroke:#DC2626,color:#111;

    class Coordinator coordinator;

    class Engineering,Frontend,Backend,Security,QA,Release,Implementation engineering;

    class Marketing,Content,VideoDirector,Scriptwriter,Designer,VideoEditor,AssetProducer marketing;

    class Growth,Funnels,Pricing,Retention,Analytics,Partnerships growth;

    class Research,Signals,Synthesis,Competitive,CustomerResearch,ProductResearch research;

To już wygląda jak prawdziwy multi-agent architecture diagram, który można później połączyć z Twoim wcześniejszym diagramem Coordinator / Planner / Research / Review / Aggregate.

Poniżej masz pełną wersję hierarchiczną z właścicielami (ownerami) i opisami agentów, odtworzoną z obrazka jako architektura multi-agent.

To jest dobra reprezentacja organizacyjna. Dla systemu agentowego (OpenClaw/HQ/MCC) polecałbym jeszcze wersję hub-and-spoke, gdzie wszyscy raportują do Coordinatora, ale dodatkowo między domenami istnieją przepływy, np.:

Research → Marketing
Research → Growth
Growth → Marketing
Marketing → Engineering
Engineering → Growth

Wtedy diagram pokazuje nie tylko hierarchię, ale również realny przepływ pracy między agentami.

flowchart TB

    Coordinator["Coordinator"]

    Coordinator --> Engineering["Engineering Architect (CTO)"]
    Coordinator --> Marketing["Marketing Mouse (CMO)"]
    Coordinator --> Growth["Growth Analyst (CGO)"]
    Coordinator --> Research["Research Oracle (CRO)"]

%% ==================================================
%% ENGINEERING
%% ==================================================

    Engineering --> Frontend["Frontend"]
    Engineering --> Backend["Backend"]
    Engineering --> Security["Security"]
    Engineering --> QA["QA"]
    Engineering --> Release["Release"]
    Engineering --> Implementation["Implementation"]

%% ==================================================
%% MARKETING
%% ==================================================

    Marketing --> Content["Content"]
    Marketing --> Scriptwriter["Scriptwriter"]
    Marketing --> Designer["Designer"]
    Marketing --> VideoDirector["Video Director"]
    Marketing --> VideoEditor["Video Editor"]
    Marketing --> AssetProducer["Asset Producer"]

%% ==================================================
%% GROWTH
%% ==================================================

    Growth --> Funnels["Funnels"]
    Growth --> Pricing["Pricing"]
    Growth --> Retention["Retention"]
    Growth --> Analytics["Analytics"]
    Growth --> Partnerships["Partnerships"]

%% ==================================================
%% RESEARCH
%% ==================================================

    Research --> Signals["Signals"]
    Research --> Synthesis["Synthesis"]
    Research --> Competitive["Competitive"]
    Research --> CustomerResearch["Customer Research"]
    Research --> ProductResearch["Product Research"]

%% ==================================================
%% DOMAIN FLOWS
%% ==================================================

    Research -. Market insights .-> Marketing
    Research -. User signals .-> Growth
    Research -. Product validation .-> Engineering

    Growth -. Conversion data .-> Marketing
    Growth -. Product metrics .-> Engineering

    Marketing -. Campaign requirements .-> Engineering
    Marketing -. Messaging tests .-> Growth

    Engineering -. Product capabilities .-> Marketing
    Engineering -. Telemetry & features .-> Growth
    Engineering -. Technical constraints .-> Research

%% ==================================================
%% STYLES
%% ==================================================

    classDef coordinator fill:#EDE9FE,stroke:#7C3AED,color:#111;
    classDef engineering fill:#DBEAFE,stroke:#2563EB,color:#111;
    classDef marketing fill:#FEF3C7,stroke:#D97706,color:#111;
    classDef growth fill:#E9D5FF,stroke:#7E22CE,color:#111;
    classDef research fill:#FECACA,stroke:#DC2626,color:#111;

    class Coordinator coordinator;

    class Engineering,Frontend,Backend,Security,QA,Release,Implementation engineering;
    class Marketing,Content,Scriptwriter,Designer,VideoDirector,VideoEditor,AssetProducer marketing;
    class Growth,Funnels,Pricing,Retention,Analytics,Partnerships growth;
    class Research,Signals,Synthesis,Competitive,CustomerResearch,ProductResearch research;

Dla architektury agentowej, którą budujesz, przepływy między domenami są często ważniejsze niż sama hierarchia. Poniższy diagram pokazuje zarówno właścicieli domen, jak i typowe zależności między nimi.

Jeżeli chcesz to wykorzystać jako organizację agentów w OpenClaw/MCC, to sugerowałbym jeszcze bardziej realistyczny przepływ pracy:

Research
    ↓
Growth
    ↓
Marketing
    ↓
Engineering
    ↓
QA
    ↓
Release

         ↘
          Coordinator
         ↗

Wszystkie wyniki wracają przez Coordinatora.

Taki model bardzo dobrze współgra z Twoim wcześniejszym wzorcem:

Coordinator
 ├── Research Oracle
 ├── Growth Analyst
 ├── Marketing Mouse
 └── Engineering Architect

Coordinator
   → Decompose
   → Route
   → Aggregate
   → Resolve Conflicts
   → Final Response

Jest to już pełnoprawna architektura hub-and-spoke + domain specialists + aggregation layer.

To już zaczyna przypominać operacyjny system agentowy, więc zamiast samych strzałek warto opisać jakie artefakty przepływają pomiędzy domenami.

Poniższy diagram pokazuje zarówno hierarchię, jak i semantykę przepływów.

flowchart TB

    Coordinator["Coordinator
    Routing • Context • Error Handling • Aggregation"]

%% ==================================================
%% DOMAIN OWNERS
%% ==================================================

    Coordinator --> Research["Research Oracle (CRO)"]
    Coordinator --> Growth["Growth Analyst (CGO)"]
    Coordinator --> Marketing["Marketing Mouse (CMO)"]
    Coordinator --> Engineering["Engineering Architect (CTO)"]

%% ==================================================
%% RESEARCH
%% ==================================================

    Research --> Signals["Signals"]
    Research --> CustomerResearch["Customer Research"]
    Research --> ProductResearch["Product Research"]
    Research --> Competitive["Competitive Analysis"]
    Research --> Synthesis["Synthesis"]

%% ==================================================
%% GROWTH
%% ==================================================

    Growth --> Funnels["Funnels"]
    Growth --> Pricing["Pricing"]
    Growth --> Retention["Retention"]
    Growth --> Analytics["Analytics"]
    Growth --> Partnerships["Partnerships"]

%% ==================================================
%% MARKETING
%% ==================================================

    Marketing --> Content["Content"]
    Marketing --> Scriptwriter["Scriptwriter"]
    Marketing --> Designer["Designer"]
    Marketing --> VideoDirector["Video Director"]
    Marketing --> VideoEditor["Video Editor"]
    Marketing --> AssetProducer["Asset Producer"]

%% ==================================================
%% ENGINEERING
%% ==================================================

    Engineering --> Frontend["Frontend"]
    Engineering --> Backend["Backend"]
    Engineering --> Security["Security"]
    Engineering --> QA["QA"]
    Engineering --> Release["Release"]
    Engineering --> Implementation["Implementation"]

%% ==================================================
%% DOMAIN FLOWS
%% ==================================================

    Research -. Customer pain points,
    market opportunities,
    competitor insights .-> Growth

    Research -. Product validation,
    user feedback,
    feature requests .-> Engineering

    Research -. Audience insights,
    positioning,
    messaging hooks .-> Marketing

    Growth -. Conversion metrics,
    funnel bottlenecks,
    winning experiments .-> Marketing

    Growth -. Usage analytics,
    retention signals,
    monetization opportunities .-> Engineering

    Marketing -. Campaign goals,
    content requirements,
    landing page needs .-> Engineering

    Marketing -. Messaging tests,
    campaign outcomes,
    audience responses .-> Growth

    Engineering -. Product capabilities,
    release schedules,
    technical constraints .-> Marketing

    Engineering -. Product telemetry,
    feature adoption,
    event tracking .-> Growth

    Engineering -. Technical feasibility,
    implementation feedback .-> Research

%% ==================================================
%% FEEDBACK LOOP
%% ==================================================

    Research --> Coordinator
    Growth --> Coordinator
    Marketing --> Coordinator
    Engineering --> Coordinator

---

Co dokładnie płynie między agentami?

Research → Growth

Artefakty

• trendy rynkowe
• sygnały zakupowe
• segmentacja klientów
• konkurencja
• opportunity discovery

Przykład:

Klienci SMB mają problem z onboardingiem.
Największy odpływ następuje w ciągu pierwszych 7 dni.

---

Research → Marketing

Artefakty

• ICP (Ideal Customer Profile)
• pain points
• messaging angles
• value propositions
• objections

Przykład:

Najczęstszy problem:
„Konfiguracja trwa za długo”

Najlepszy komunikat:
„Uruchomienie w 15 minut”

---

Research → Engineering

Artefakty

• feature requests
• customer complaints
• usability issues
• unmet needs

Przykład:

62% klientów oczekuje eksportu do Excela.

---

Growth → Marketing

Artefakty

• wyniki A/B testów
• CTR
• konwersje
• skuteczne nagłówki

Przykład:

Wariant B zwiększył konwersję o 17%.

---

Marketing → Engineering

Artefakty

• landing page requirements
• tracking requirements
• content blocks
• CTA requirements

Przykład:

Potrzebujemy kalkulator ROI na stronie produktu.

---

Engineering → Growth

Artefakty

• telemetry
• events
• feature usage
• retention data

Przykład:

78% użytkowników używa funkcji X
mniej niż raz tygodniowo.

---

Engineering → Marketing

Artefakty

• roadmap
• release notes
• capabilities
• differentiators

Przykład:

Nowa funkcja AI zostanie wydana w wersji 2.4.

---

Rola Coordinatora

Coordinator nie tworzy treści.

Coordinator:

Receive task
    ↓
Decompose
    ↓
Route to domain owners
    ↓
Collect outputs
    ↓
Resolve conflicts
    ↓
Aggregate
    ↓
Final response

Czyli w Twojej architekturze:

Research = odkrywa wiedzę
Growth = optymalizuje biznes
Marketing = komunikuje wartość
Engineering = buduje rozwiązanie
Coordinator = zarządza przepływem pracy

To jest już pełny model Hub-and-Spoke Multi-Agent Organization z przepływami wiedzy, decyzji i artefaktów między domenami.

Świetny kandydat na Capability Map / AIOS Architecture Diagram. Dla Mermaid najlepiej użyć subgraph + style, dzięki czemu każda domena ma własny kolor, a diagram przypomina oryginalny dashboard.

flowchart TB

%% =====================================================
%% ROOT
%% =====================================================

    ROOT["AI Operating System"]
%% FOUNDATIONS
%% =====================================================

    subgraph Foundations
        Memory["MEMORY"]
        Productivity["PRODUCTIVITY"]
    end

%% =====================================================
%% MEMORY
%% =====================================================

    subgraph MemoryDomain["MEMORY • Foundations"]
        Vault["Obsidian Vault"]
        Raw["/raw"]
        Wiki["/wiki"]
        Projects["/projects"]
        Claude["CLAUDE.md"]
        MemoryStore[".claude/memory"]

        Vault --> Raw
        Vault --> Wiki
        Vault --> Projects
    end

%% =====================================================
%% PRODUCTIVITY
%% =====================================================

    subgraph ProductivityDomain["PRODUCTIVITY • Foundations"]
        GWS["GWS CLI"]
        Inbox["Inbox Triage"]
        Calendar["Calendar Brief"]
        Sync["Drive Sync"]
        Daily["Daily Review"]
        Morning["Morning Routine"]
    end

%% =====================================================
%% RESEARCH
%% =====================================================

    subgraph ResearchDomain["RESEARCH"]
        YT["YT Pipeline"]
        Deep["Deep Research"]
        LightRAG["LightRAG Query"]
        Trends["Morning Trend Scan"]
        Competitor["Competitor Watch"]
        NotebookLM["NotebookLM Bridge"]
    end

%% =====================================================
%% CONTENT
%% =====================================================

    subgraph ContentDomain["CONTENT"]
        Outlines["Outlines"]
        Hooks["Hooks"]
        Cascade["Content Cascade"]
        Carousel["Carousel Generator"]
        Repurpose["Short Form Repurpose"]
        Thumbnail["Thumbnail Briefs"]
    end

%% =====================================================
%% COMMUNITY
%% =====================================================

    subgraph CommunityDomain["COMMUNITY"]
        PostDrafts["Post Drafts"]
        Classroom["AI Classroom"]
        MemberOnboarding["Member Onboarding"]
        WeeklyQA["Weekly QA Digest"]
        CommentTriage["Comment Triage"]
        Pulse["Community Pulse"]
    end

%% =====================================================
%% AGENCY
%% =====================================================

    subgraph AgencyDomain["AGENCY"]
        ClientOnboarding["Client Onboarding"]
        Scope["Scope of Work Generator"]
        ClientStatus["Weekly Client Status"]
        DeliverableQA["Deliverable QA"]
        Renewal["Retainer Renewal"]
        AIOSBuilder["Client AIOS Builder"]
    end

%% =====================================================
%% SALES
%% =====================================================

    subgraph SalesDomain["SALES"]
        Pitch["Sponsor Pitch Deck"]
        LeadEnrichment["Lead Enrichment"]
        Followup["Follow-up Cadence"]
        Proposal["Proposal Drafts"]
        Pipeline["Pipeline Review"]
        InboxSales["Sponsor Inbox Triage"]
    end

%% =====================================================
%% FINANCE
%% =====================================================

    subgraph FinanceDomain["FINANCE"]
        Books["Books Categorizer"]
        PL["Monthly P&L"]
        Tax["Tax Prep"]
        Anomaly["Anomaly Scan"]
        Audit["Subscription Audit"]
        Receipts["Receipts Tracker"]
    end

%% =====================================================
%% OPS
%% =====================================================

    subgraph OpsDomain["OPS / CUSTOM"]
        Cleanup["Vault Cleanup"]
        SkillCreator["Skill Creator"]
        Cron["Cron Manager"]
        HooksCfg["Hook Config"]
        Spawn["Sub-Agent Spawn"]
    end

%% =====================================================
%% RELATIONSHIPS
%% =====================================================

    ROOT --> Memory
    ROOT --> Productivity

    ROOT --> ResearchDomain
    ROOT --> ContentDomain
    ROOT --> CommunityDomain
    ROOT --> AgencyDomain
    ROOT --> SalesDomain
    ROOT --> FinanceDomain
    ROOT --> OpsDomain

%% KNOWLEDGE FLOW

    Raw -. Raw Data .-> Deep
    Raw -. Raw Data .-> Trends
    Raw -. Raw Data .-> Competitor

    Deep -. Findings .-> Wiki
    Trends -. Findings .-> Wiki
    Competitor -. Findings .-> Wiki
    NotebookLM -. Insights .-> Wiki

    Wiki -. Context .-> ContentDomain
    Wiki -. Context .-> CommunityDomain
    Wiki -. Context .-> AgencyDomain

    Projects -. Work Items .-> ContentDomain
    Projects -. Work Items .-> AgencyDomain
    Projects -. Work Items .-> CommunityDomain

    ContentDomain -. Assets .-> CommunityDomain
    ContentDomain -. Assets .-> SalesDomain

    CommunityDomain -. Audience Signals .-> ResearchDomain
    CommunityDomain -. Leads .-> SalesDomain

    SalesDomain -. Opportunities .-> AgencyDomain

    AgencyDomain -. Revenue .-> FinanceDomain

    FinanceDomain -. Budgets .-> AgencyDomain

    OpsDomain -. Automation .-> ResearchDomain
    OpsDomain -. Automation .-> ContentDomain
    OpsDomain -. Automation .-> CommunityDomain
    OpsDomain -. Automation .-> AgencyDomain
    OpsDomain -. Automation .-> SalesDomain
    OpsDomain -. Automation .-> FinanceDomain

%% =====================================================
%% COLORS
%% =====================================================

    style MemoryDomain fill:#052e16,stroke:#22c55e,stroke-width:3px,color:#ffffff
    style ProductivityDomain fill:#052e16,stroke:#22c55e,stroke-width:3px,color:#ffffff

    style ResearchDomain fill:#0f172a,stroke:#60a5fa,stroke-width:3px,color:#ffffff
    style ContentDomain fill:#0f172a,stroke:#60a5fa,stroke-width:3px,color:#ffffff
    style CommunityDomain fill:#0f172a,stroke:#60a5fa,stroke-width:3px,color:#ffffff
    style AgencyDomain fill:#0f172a,stroke:#60a5fa,stroke-width:3px,color:#ffffff
    style SalesDomain fill:#0f172a,stroke:#60a5fa,stroke-width:3px,color:#ffffff
    style FinanceDomain fill:#0f172a,stroke:#60a5fa,stroke-width:3px,color:#ffffff

    style OpsDomain fill:#3b0764,stroke:#c084fc,stroke-width:3px,color:#ffffff

Ten wariant wizualnie odpowiada kolorystyce z obrazka:

• 🟢 Memory / Productivity = fundamenty (always-on)
• 🔵 Research / Content / Community / Agency / Sales / Finance = capability domains
• 🟣 Ops / Custom = warstwa administracyjna i automatyzacyjna
• Linie przerywane pokazują przepływ wiedzy i artefaktów między domenami.