# Architektura agenta Poniżej Mermaid dla architektury **hub-and-spoke** z obrazka — wersja bez `
`, żeby uniknąć błędu `splitLineToFitWidth does not support newlines in the line`. ```mermaid 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: ```mermaid 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: ```mermaid 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`. ```mermaid 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. ```mermaid 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 ```mermaid 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 ```mermaid 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: ```text 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: ```mermaid 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: ```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.: ```mermaid flowchart TB Coordinator["Coordinator Agent"] Coordinator --> Engineering["Engineering Architect
Owner: CTO
Designs systems and technical direction"] Coordinator --> Marketing["Marketing Mouse
Owner: CMO
Creates messaging and promotional assets"] Coordinator --> Growth["Growth Analyst
Owner: CGO
Optimizes acquisition, conversion and retention"] Coordinator --> Research["Research Oracle
Owner: CRO
Discovers signals, trends and opportunities"] %% ======================= %% ENGINEERING %% ======================= Engineering --> Frontend["Frontend
UI surfaces, dashboards, customer flows"] Engineering --> Backend["Backend
APIs, integrations, business logic"] Engineering --> Security["Security
Risk analysis, secrets, auth boundaries"] Engineering --> QA["QA
Testing, validation, acceptance criteria"] Engineering --> Release["Release
Deployment readiness and rollback planning"] Engineering --> Implementation["Implementation
Feature delivery and execution"] %% ======================= %% MARKETING %% ======================= Marketing --> Content["Content
Storytelling, tutorials, launch narratives"] Marketing --> VideoDirector["Video Director
Production planning and coordination"] Marketing --> Scriptwriter["Scriptwriter
Ads, hooks and promo scripts"] Marketing --> Designer["Designer
Visual identity and graphics"] Marketing --> VideoEditor["Video Editor
Assembly, subtitles and rendering"] Marketing --> AssetProducer["Asset Producer
Screenshots, demos and supporting assets"] %% ======================= %% GROWTH %% ======================= Growth --> Funnels["Funnels
Landing pages and conversion optimization"] Growth --> Pricing["Pricing
Monetization and packaging strategy"] Growth --> Retention["Retention
Engagement and churn reduction"] Growth --> Analytics["Analytics
Traffic, revenue and experiment analysis"] Growth --> Partnerships["Partnerships
Affiliates and strategic collaborations"] %% ======================= %% RESEARCH %% ======================= Research --> Signals["Signals
Trend discovery and market scanning"] Research --> Synthesis["Synthesis
Converts findings into recommendations"] Research --> Competitive["Competitive
Competitor tracking and positioning"] Research --> CustomerResearch["Customer Research
Customer interviews and feedback"] Research --> ProductResearch["Product Research
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.: ```text 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. ```mermaid 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: ```text Research ↓ Growth ↓ Marketing ↓ Engineering ↓ QA ↓ Release ↘ Coordinator ↗ Wszystkie wyniki wracają przez Coordinatora. ``` Taki model bardzo dobrze współgra z Twoim wcześniejszym wzorcem: ```text 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. ```mermaid 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: ```text 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: ```text 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: ```text 62% klientów oczekuje eksportu do Excela. ``` *** ### Growth → Marketing **Artefakty** * wyniki A/B testów * CTR * konwersje * skuteczne nagłówki Przykład: ```text Wariant B zwiększył konwersję o 17%. ``` *** ### Marketing → Engineering **Artefakty** * landing page requirements * tracking requirements * content blocks * CTA requirements Przykład: ```text Potrzebujemy kalkulator ROI na stronie produktu. ``` *** ### Engineering → Growth **Artefakty** * telemetry * events * feature usage * retention data Przykład: ```text 78% użytkowników używa funkcji X mniej niż raz tygodniowo. ``` *** ### Engineering → Marketing **Artefakty** * roadmap * release notes * capabilities * differentiators Przykład: ```text Nowa funkcja AI zostanie wydana w wersji 2.4. ``` *** ## Rola Coordinatora Coordinator nie tworzy treści. Coordinator: ```text Receive task ↓ Decompose ↓ Route to domain owners ↓ Collect outputs ↓ Resolve conflicts ↓ Aggregate ↓ Final response ``` Czyli w Twojej architekturze: ```text 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. ```mermaid 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.