Jul 10, 2026, 9:25 AM

This commit is contained in:
Paweł Domański
2026-07-10 07:25:30 +00:00
parent 059ef99401
commit ab7a79ddbb
+134
View File
@@ -520,3 +520,137 @@ 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**.