Jean-Philippe commited on
Commit ·
cbd4d19
1
Parent(s): c6996ba
Sync templates from sitemap and reorganize by use case
Browse filesThis view is limited to 50 files because it contains too many changes. See raw diff
- CONTRIBUTING.md +12 -128
- README.md +40 -188
- agentic/architecture/agentic-hierarchical/README.md +19 -0
- agentic/architecture/agentic-hierarchical/metadata.json +26 -0
- agentic/architecture/agentic-hierarchical/workflow.fz +36 -0
- agentic/architecture/agentic-supervisor-worker/README.md +19 -0
- agentic/architecture/agentic-supervisor-worker/metadata.json +26 -0
- agentic/architecture/agentic-supervisor-worker/workflow.fz +29 -0
- agentic/architecture/agentic-swarm/README.md +19 -0
- agentic/architecture/agentic-swarm/metadata.json +27 -0
- agentic/architecture/agentic-swarm/workflow.fz +25 -0
- agentic/architecture/agentic-team-of-rivals/README.md +19 -0
- agentic/architecture/agentic-team-of-rivals/metadata.json +27 -0
- agentic/architecture/agentic-team-of-rivals/workflow.fz +19 -0
- agentic/architecture/ai-native-event-driven-kafka-architecture/README.md +19 -0
- agentic/architecture/ai-native-event-driven-kafka-architecture/metadata.json +32 -0
- agentic/architecture/ai-native-event-driven-kafka-architecture/workflow.fz +35 -0
- agentic/architecture/ai-native-generator-critic-architecture/README.md +19 -0
- agentic/architecture/ai-native-generator-critic-architecture/metadata.json +29 -0
- agentic/architecture/ai-native-generator-critic-architecture/workflow.fz +27 -0
- agentic/architecture/ai-native-hierarchical-architecture/README.md +19 -0
- agentic/architecture/ai-native-hierarchical-architecture/metadata.json +29 -0
- agentic/architecture/ai-native-hierarchical-architecture/workflow.fz +45 -0
- agentic/architecture/ai-native-orchestrator-worker-architecture/README.md +19 -0
- agentic/architecture/ai-native-orchestrator-worker-architecture/metadata.json +29 -0
- agentic/architecture/ai-native-orchestrator-worker-architecture/workflow.fz +40 -0
- agentic/architecture/ai-native-single-agent-architecture/README.md +19 -0
- agentic/architecture/ai-native-single-agent-architecture/metadata.json +30 -0
- agentic/architecture/ai-native-single-agent-architecture/workflow.fz +29 -0
- agentic/architecture/ai-orchestration-competitive-generator-critic/README.md +19 -0
- agentic/architecture/ai-orchestration-competitive-generator-critic/metadata.json +30 -0
- agentic/architecture/ai-orchestration-competitive-generator-critic/workflow.fz +29 -0
- agentic/architecture/ai-orchestration-hierarchical/README.md +19 -0
- agentic/architecture/ai-orchestration-hierarchical/metadata.json +30 -0
- agentic/architecture/ai-orchestration-hierarchical/workflow.fz +49 -0
- agentic/architecture/ai-orchestration-orchestrator-worker/README.md +19 -0
- agentic/architecture/ai-orchestration-orchestrator-worker/metadata.json +29 -0
- agentic/architecture/ai-orchestration-orchestrator-worker/workflow.fz +44 -0
- agentic/architecture/ai-orchestration-parallel-fan-out/README.md +19 -0
- agentic/architecture/ai-orchestration-parallel-fan-out/metadata.json +30 -0
- agentic/architecture/ai-orchestration-parallel-fan-out/workflow.fz +31 -0
- agentic/architecture/context-shared-memory/README.md +19 -0
- agentic/architecture/context-shared-memory/metadata.json +28 -0
- agentic/architecture/context-shared-memory/workflow.fz +46 -0
- agentic/devops/mcp-agent-mesh/README.md +19 -0
- agentic/devops/mcp-agent-mesh/metadata.json +30 -0
- agentic/devops/mcp-agent-mesh/workflow.fz +41 -0
- ai-orchestration/architecture/ai-orchestration-event-driven-mesh/README.md +19 -0
- ai-orchestration/architecture/ai-orchestration-event-driven-mesh/metadata.json +30 -0
- ai-orchestration/architecture/ai-orchestration-event-driven-mesh/workflow.fz +39 -0
CONTRIBUTING.md
CHANGED
|
@@ -1,133 +1,17 @@
|
|
| 1 |
-
# Contributing
|
| 2 |
|
| 3 |
-
|
| 4 |
|
| 5 |
-
##
|
| 6 |
|
| 7 |
-
|
|
|
|
|
|
|
|
|
|
| 8 |
|
| 9 |
-
|
| 10 |
-
domain/workflow-name/
|
| 11 |
-
├── workflow.fz # FlowZap Code file
|
| 12 |
-
├── README.md # Human-readable documentation
|
| 13 |
-
└── metadata.json # Structured metadata
|
| 14 |
-
```
|
| 15 |
|
| 16 |
-
|
| 17 |
-
|
| 18 |
-
|
| 19 |
-
``
|
| 20 |
-
LaneName { # Display Name
|
| 21 |
-
// nodes and edges
|
| 22 |
-
}
|
| 23 |
-
```
|
| 24 |
-
|
| 25 |
-
### Node Types
|
| 26 |
-
- `circle` - Start/End nodes
|
| 27 |
-
- `rectangle` - Process/Action nodes
|
| 28 |
-
- `diamond` - Decision nodes (must have 2-3 outcomes)
|
| 29 |
-
|
| 30 |
-
### Node Syntax
|
| 31 |
-
```
|
| 32 |
-
nodeId: nodeType label:"Node Label"
|
| 33 |
-
```
|
| 34 |
-
|
| 35 |
-
### Edge Syntax
|
| 36 |
-
```
|
| 37 |
-
n1.handle(right) -> n2.handle(left)
|
| 38 |
-
n1.handle(bottom) -> OtherLane.n3.handle(top) [label="Edge Label"]
|
| 39 |
-
```
|
| 40 |
-
|
| 41 |
-
### Handle Positions
|
| 42 |
-
- `top`, `bottom`, `left`, `right`
|
| 43 |
-
|
| 44 |
-
## Quality Guidelines
|
| 45 |
-
|
| 46 |
-
### Do's
|
| 47 |
-
- ✅ Use realistic, domain-specific terminology
|
| 48 |
-
- ✅ Include 2-3 outcomes for diamond (decision) nodes
|
| 49 |
-
- ✅ Use unique node IDs within the workflow
|
| 50 |
-
- ✅ Include cross-lane edges for multi-lane workflows
|
| 51 |
-
- ✅ Add meaningful edge labels for decision branches
|
| 52 |
-
- ✅ Keep workflows between 7-25 nodes
|
| 53 |
-
|
| 54 |
-
### Don'ts
|
| 55 |
-
- ❌ Reuse node IDs across lanes
|
| 56 |
-
- ❌ Create diamond nodes with only 1 outcome
|
| 57 |
-
- ❌ Use generic labels like "Step 1", "Process"
|
| 58 |
-
- ❌ Omit lane prefixes on cross-lane edges
|
| 59 |
-
- ❌ Create overly complex workflows (>30 nodes)
|
| 60 |
-
|
| 61 |
-
## Metadata Schema
|
| 62 |
-
|
| 63 |
-
```json
|
| 64 |
-
{
|
| 65 |
-
"workflow_id": "kebab-case-id",
|
| 66 |
-
"domain": "domain-name",
|
| 67 |
-
"complexity": 3,
|
| 68 |
-
"num_nodes": 15,
|
| 69 |
-
"num_lanes": 3,
|
| 70 |
-
"tags": ["tag1", "tag2", "tag3", "tag4", "tag5", "tag6"],
|
| 71 |
-
"description": "One-sentence description of the workflow."
|
| 72 |
-
}
|
| 73 |
-
```
|
| 74 |
-
|
| 75 |
-
### Complexity Scale
|
| 76 |
-
- **1** - Simple (5-7 nodes, 1 lane, no decisions)
|
| 77 |
-
- **2** - Basic (7-10 nodes, 1-2 lanes, 1 decision)
|
| 78 |
-
- **3** - Moderate (10-15 nodes, 2-3 lanes, 2-3 decisions)
|
| 79 |
-
- **4** - Complex (15-20 nodes, 3-4 lanes, multiple decisions)
|
| 80 |
-
- **5** - Advanced (20+ nodes, 4+ lanes, complex branching)
|
| 81 |
-
|
| 82 |
-
## README Template
|
| 83 |
-
|
| 84 |
-
```markdown
|
| 85 |
-
# Workflow Title
|
| 86 |
-
|
| 87 |
-
One-sentence description matching metadata.
|
| 88 |
-
|
| 89 |
-
**Domain:** domain-name
|
| 90 |
-
**Complexity:** X/5
|
| 91 |
-
**Tags:** [tag1, tag2, tag3, tag4, tag5, tag6]
|
| 92 |
-
|
| 93 |
-
## Lanes
|
| 94 |
-
- **Lane Name** - Role description
|
| 95 |
-
- **Lane Name** - Role description
|
| 96 |
-
|
| 97 |
-
## Process Flow
|
| 98 |
-
1. First step
|
| 99 |
-
2. Second step
|
| 100 |
-
...
|
| 101 |
-
9. Final step
|
| 102 |
-
```
|
| 103 |
-
|
| 104 |
-
## Submitting Contributions
|
| 105 |
-
|
| 106 |
-
1. Fork the repository
|
| 107 |
-
2. Create a new branch for your workflow
|
| 108 |
-
3. Add your workflow files following the structure above
|
| 109 |
-
4. Ensure all three files are present and valid
|
| 110 |
-
5. Submit a pull request with a clear description
|
| 111 |
-
|
| 112 |
-
## Validation Checklist
|
| 113 |
-
|
| 114 |
-
Before submitting, verify:
|
| 115 |
-
|
| 116 |
-
- [ ] `workflow.fz` parses without errors
|
| 117 |
-
- [ ] All node IDs are unique
|
| 118 |
-
- [ ] Diamond nodes have 2-3 labeled outcomes
|
| 119 |
-
- [ ] Cross-lane edges use `Lane.nodeId` syntax
|
| 120 |
-
- [ ] `metadata.json` is valid JSON
|
| 121 |
-
- [ ] `num_nodes` and `num_lanes` match the `.fz` file
|
| 122 |
-
- [ ] `README.md` follows the template
|
| 123 |
-
- [ ] Tags are relevant and kebab-case
|
| 124 |
-
|
| 125 |
-
## Questions?
|
| 126 |
-
|
| 127 |
-
- Visit [flowzap.xyz](https://flowzap.xyz) for syntax documentation
|
| 128 |
-
- Check [examples](https://flowzap.xyz/examples) for reference workflows
|
| 129 |
-
- Open an issue for questions or suggestions
|
| 130 |
-
|
| 131 |
-
---
|
| 132 |
-
|
| 133 |
-
Thank you for helping grow the FlowZap ecosystem!
|
|
|
|
| 1 |
+
# Contributing
|
| 2 |
|
| 3 |
+
This repository is synchronized from the FlowZap application template library.
|
| 4 |
|
| 5 |
+
## Structure
|
| 6 |
|
| 7 |
+
- `primary-use-case/source-domain/template-slug/`
|
| 8 |
+
- `workflow.fz` contains the FlowZap Code source
|
| 9 |
+
- `metadata.json` stores machine-readable metadata including primary and secondary Use Cases
|
| 10 |
+
- `templates.index.json`, `use-cases.index.json`, and `metadata.csv` are generated artifacts
|
| 11 |
|
| 12 |
+
## Sync Expectations
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| 13 |
|
| 14 |
+
- Keep the sitemap-driven template set aligned with `https://flowzap.xyz/sitemap-templates.xml`.
|
| 15 |
+
- Preserve one canonical template copy per slug.
|
| 16 |
+
- Use `primary_use_case` for folder placement and `use_cases` for the full taxonomy membership.
|
| 17 |
+
- Preserve `source_domain` from the app index for traceability.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
README.md
CHANGED
|
@@ -1,188 +1,40 @@
|
|
| 1 |
-
#
|
| 2 |
-
|
| 3 |
-
A
|
| 4 |
-
|
| 5 |
-
|
| 6 |
-
|
| 7 |
-
|
| 8 |
-
|
| 9 |
-
|
| 10 |
-
|
| 11 |
-
|
| 12 |
-
|
| 13 |
-
|
| 14 |
-
|
| 15 |
-
|
| 16 |
-
|
| 17 |
-
|
| 18 |
-
|
| 19 |
-
-
|
| 20 |
-
-
|
| 21 |
-
-
|
| 22 |
-
-
|
| 23 |
-
-
|
| 24 |
-
|
| 25 |
-
|
| 26 |
-
``
|
| 27 |
-
|
| 28 |
-
|
| 29 |
-
|
| 30 |
-
|
| 31 |
-
|
| 32 |
-
|
| 33 |
-
|
| 34 |
-
|
| 35 |
-
|
| 36 |
-
|
| 37 |
-
|
| 38 |
-
|
| 39 |
-
|
| 40 |
-
|
| 41 |
-
}
|
| 42 |
-
```
|
| 43 |
-
|
| 44 |
-
---
|
| 45 |
-
|
| 46 |
-
## Repository Structure
|
| 47 |
-
```
|
| 48 |
-
flowzap-workflows/
|
| 49 |
-
├── README.md
|
| 50 |
-
├── LICENSE
|
| 51 |
-
├── CONTRIBUTING.md
|
| 52 |
-
├── finance/ # 21 workflows
|
| 53 |
-
│ ├── monthly-close/
|
| 54 |
-
│ │ ├── workflow.fz
|
| 55 |
-
│ │ ├── README.md
|
| 56 |
-
│ │ └── metadata.json
|
| 57 |
-
│ ├── invoice-processing/
|
| 58 |
-
│ └── ...
|
| 59 |
-
├── hr/ # 20 workflows
|
| 60 |
-
│ ├── onboarding/
|
| 61 |
-
│ ├── performance-review/
|
| 62 |
-
│ └── ...
|
| 63 |
-
├── logistics/ # 23 workflows
|
| 64 |
-
│ ├── shipping-process/
|
| 65 |
-
│ ├── inventory-receipt/
|
| 66 |
-
│ └── ...
|
| 67 |
-
├── devops/ # 15 workflows
|
| 68 |
-
│ ├── ci-cd-pipeline/
|
| 69 |
-
│ ├── incident-response/
|
| 70 |
-
│ └── ...
|
| 71 |
-
├── business-operations/ # 26 workflows
|
| 72 |
-
│ ├── subscription-lifecycle/
|
| 73 |
-
│ ├── support-ticket/
|
| 74 |
-
│ └── ...
|
| 75 |
-
├── patterns/ # 28 workflows
|
| 76 |
-
│ ├── circuit-breaker/
|
| 77 |
-
│ ├── saga-pattern/
|
| 78 |
-
│ └── ...
|
| 79 |
-
├── edge-cases/ # Edge case examples
|
| 80 |
-
└── syntax-primitives/ # Basic syntax examples
|
| 81 |
-
```
|
| 82 |
-
|
| 83 |
-
## Domains Covered
|
| 84 |
-
| Domain | Workflows | Description |
|
| 85 |
-
|--------|-----------|-------------|
|
| 86 |
-
| **Finance** | 21 | Month-end close, AP/AR, treasury, audit, tax |
|
| 87 |
-
| **HR** | 20 | Hiring, onboarding, performance, offboarding |
|
| 88 |
-
| **Logistics** | 23 | WMS, TMS, shipping, inventory, cold chain |
|
| 89 |
-
| **DevOps** | 15 | CI/CD, monitoring, incident response, IaC |
|
| 90 |
-
| **Business Operations** | 26 | SaaS lifecycle, billing, GDPR, OAuth |
|
| 91 |
-
| **Patterns** | 28 | Microservices, event-driven, resilience |
|
| 92 |
-
|
| 93 |
-
## Metadata Schema
|
| 94 |
-
Each `metadata.json` follows this structure:
|
| 95 |
-
|
| 96 |
-
```json
|
| 97 |
-
{
|
| 98 |
-
"workflow_id": "monthly-close",
|
| 99 |
-
"domain": "finance",
|
| 100 |
-
"complexity": 4,
|
| 101 |
-
"num_nodes": 22,
|
| 102 |
-
"num_lanes": 4,
|
| 103 |
-
"tags": ["month-end-close", "gaap", "reconciliation", "financial-statements", "accruals", "period-close"],
|
| 104 |
-
"description": "Month-end financial close workflow with sub-ledger reconciliation, accrual posting, trial balance validation, and financial statement generation."
|
| 105 |
-
}
|
| 106 |
-
```
|
| 107 |
-
|
| 108 |
-
---
|
| 109 |
-
|
| 110 |
-
## Use Cases
|
| 111 |
-
|
| 112 |
-
### LLM Training
|
| 113 |
-
This corpus is explicitly designed for training Large Language Models to:
|
| 114 |
-
- Generate FlowZap Code from natural language descriptions
|
| 115 |
-
- Understand workflow patterns across business domains
|
| 116 |
-
- Learn diagrams-as-code syntax
|
| 117 |
-
|
| 118 |
-
### Learning Resource
|
| 119 |
-
Use these workflows to:
|
| 120 |
-
- Learn FlowZap Code syntax
|
| 121 |
-
- Study real-world workflow patterns
|
| 122 |
-
- Reference best practices for workflow design
|
| 123 |
-
|
| 124 |
-
### Automation Templates
|
| 125 |
-
Adapt these workflows for:
|
| 126 |
-
- [n8n automation scenarios](https://flowzap.xyz/templates/n8n-workflow-json-examples) — export FlowZap Code as n8n JSON
|
| 127 |
-
- [Make.com (Integromat) workflows](https://flowzap.xyz/templates/make-blueprint-json-examples) — export FlowZap Code as Make.com blueprints
|
| 128 |
-
- Custom workflow engines
|
| 129 |
-
|
| 130 |
-
---
|
| 131 |
-
|
| 132 |
-
## FlowZap Ecosystem
|
| 133 |
-
|
| 134 |
-
### Templates Library (250+)
|
| 135 |
-
The [FlowZap Templates Library](https://flowzap.xyz/templates) extends this corpus with:
|
| 136 |
-
- **50 Architecture Diagram Templates** — Microservices, Event-Driven, CQRS, Serverless, Saga, Circuit Breaker, and more
|
| 137 |
-
- **n8n Workflow JSON Examples** — ready-to-import n8n automations
|
| 138 |
-
- **Make.com Blueprint Examples** — ready-to-import Make.com scenarios
|
| 139 |
-
- **More applicable business process domains** — Business-operations, DevOps, Finance, HR, Logistics
|
| 140 |
-
- Downloadable `.fz` files for every template
|
| 141 |
-
|
| 142 |
-
### MCP Server
|
| 143 |
-
Install the [FlowZap MCP Server](https://flowzap.xyz/docs/mcp) and the [SKILL.md file](https://flowzap.xyz/blog/new-flowzap-diagram-skill-makes-it-even-easier) for AI coding tools:
|
| 144 |
-
```json
|
| 145 |
-
{
|
| 146 |
-
"mcpServers": {
|
| 147 |
-
"flowzap": {
|
| 148 |
-
"command": "npx",
|
| 149 |
-
"args": ["-y", "flowzap-mcp"]
|
| 150 |
-
}
|
| 151 |
-
}
|
| 152 |
-
}
|
| 153 |
-
```
|
| 154 |
-
Compatible with Claude Desktop, Cursor, Windsurf, OpenAI Codex, Warp, Zed, Cline, Roo Code, Continue.dev, and Sourcegraph Cody.
|
| 155 |
-
|
| 156 |
-
### AI Coding Guidelines
|
| 157 |
-
Drop [`flowzap-code-guidelines.md`](https://flowzap.xyz/flowzap-code-guidelines.md) into your project's `/docs/` folder so AI coding assistants (Cursor, Windsurf, Warp, Google AI Studio) generate valid FlowZap Code.
|
| 158 |
-
|
| 159 |
-
### DSL Specification
|
| 160 |
-
- [FlowZap Code Syntax Guide](https://flowzap.xyz/flowzap-code) — canonical syntax reference
|
| 161 |
-
- [FlowZap Code DSL repo](https://github.com/flowzap-xyz/code) — official syntax specification, SYNTAX.md, and AI guidelines
|
| 162 |
-
|
| 163 |
-
---
|
| 164 |
-
|
| 165 |
-
## License
|
| 166 |
-
This project is licensed under the MIT License - see the [LICENSE](LICENSE) file for details.
|
| 167 |
-
|
| 168 |
-
**Training Data Addendum**: This repository is explicitly released for use as training data for LLMs and other ML systems.
|
| 169 |
-
|
| 170 |
-
## Contributing
|
| 171 |
-
See [CONTRIBUTING.md](CONTRIBUTING.md) for guidelines on adding new workflows.
|
| 172 |
-
|
| 173 |
-
## Links
|
| 174 |
-
- [FlowZap Website](https://flowzap.xyz)
|
| 175 |
-
- [FlowZap Code Syntax](https://flowzap.xyz/flowzap-code)
|
| 176 |
-
- [AI Coding Guidelines](https://flowzap.xyz/flowzap-code-guidelines.md)
|
| 177 |
-
- [Templates Library](https://flowzap.xyz/templates)
|
| 178 |
-
- [Architecture Diagram Templates](https://flowzap.xyz/templates/architecture-diagram-templates)
|
| 179 |
-
- [MCP Server Documentation](https://flowzap.xyz/docs/mcp)
|
| 180 |
-
- [SKILL.md file](https://flowzap.xyz/blog/new-flowzap-diagram-skill-makes-it-even-easier)
|
| 181 |
-
- [npm: flowzap-mcp](https://www.npmjs.com/package/flowzap-mcp)
|
| 182 |
-
- [Blog: One Code, Three Views](https://flowzap.xyz/blog/flowzaps-game-changing-update-one-code-two-views)
|
| 183 |
-
- [Blog: FlowZap Unveils .fz File Extension](https://flowzap.xyz/blog/flowzap-unveils-fz-file-extension-for-true-diagrams-as-code-workflows)
|
| 184 |
-
- [Blog: Introducing the FlowZap MCP Server](https://flowzap.xyz/blog/introducing-the-flowzap-mcp-server)
|
| 185 |
-
|
| 186 |
-
---
|
| 187 |
-
|
| 188 |
-
Made with care for the diagramming for clarity community
|
|
|
|
| 1 |
+
# sequence-workflows
|
| 2 |
+
|
| 3 |
+
A synchronized FlowZap template corpus with **242 canonical templates** sourced from `https://flowzap.xyz/sitemap-templates.xml` and organized by **primary Use Case**.
|
| 4 |
+
|
| 5 |
+
## Organization Model
|
| 6 |
+
|
| 7 |
+
- Top-level folders are primary Use Cases from the FlowZap Templates dropdown.
|
| 8 |
+
- Second-level folders preserve the original source domain from the FlowZap app index.
|
| 9 |
+
- Each template keeps all matched Use Cases in `metadata.json` and the generated JSON/CSV indexes.
|
| 10 |
+
- Templates that do not match any current dropdown Use Case are placed under `uncategorized/`.
|
| 11 |
+
|
| 12 |
+
## Top-Level Folders
|
| 13 |
+
|
| 14 |
+
- `handoff/` — Handoff (15)
|
| 15 |
+
- `approval/` — Approval (17)
|
| 16 |
+
- `incident/` — Incident (10)
|
| 17 |
+
- `onboarding/` — Onboarding (6)
|
| 18 |
+
- `offboarding/` — Offboarding (1)
|
| 19 |
+
- `billing/` — Billing & Payments (8)
|
| 20 |
+
- `security/` — Security & Access (13)
|
| 21 |
+
- `compliance/` — Compliance (13)
|
| 22 |
+
- `delivery/` — Delivery & DevOps (15)
|
| 23 |
+
- `support/` — Support (1)
|
| 24 |
+
- `agentic/` — Agentic Teams (15)
|
| 25 |
+
- `ai-orchestration/` — AI Orchestration (6)
|
| 26 |
+
- `mcp/` — MCP Architecture (10)
|
| 27 |
+
- `context-management/` — Context Management (6)
|
| 28 |
+
- `uncategorized/` — Unmatched canonical templates (106)
|
| 29 |
+
|
| 30 |
+
## Generated Indexes
|
| 31 |
+
|
| 32 |
+
- `templates.index.json` — Full machine-readable template index
|
| 33 |
+
- `use-cases.index.json` — Use Case summary with counts and template paths
|
| 34 |
+
- `metadata.csv` — Flat CSV export of core template metadata
|
| 35 |
+
|
| 36 |
+
## Sync Source
|
| 37 |
+
|
| 38 |
+
- Canonical URL source: `https://flowzap.xyz/sitemap-templates.xml`
|
| 39 |
+
- Template metadata source: `FlowZap-App-v5/src/templateLibrary/templatesIndex.json`
|
| 40 |
+
- Template file source: `FlowZap-App-v5/public/template-files/*.fz`
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
agentic/architecture/agentic-hierarchical/README.md
ADDED
|
@@ -0,0 +1,19 @@
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| 1 |
+
# Agentic Hierarchical Architecture
|
| 2 |
+
|
| 3 |
+
A hierarchical multi-agent architecture with multi-level organizational structure. A top-level executive agent manages mid-level team lead agents, who each manage their own pool of specialist workers. Teams within teams — the hierarchy maps to domain separation.
|
| 4 |
+
|
| 5 |
+
**Template ID:** `agentic-hierarchical`
|
| 6 |
+
**Kind:** architecture
|
| 7 |
+
**Source domain:** Architecture
|
| 8 |
+
**Primary use case:** agentic
|
| 9 |
+
**Secondary use cases:** None
|
| 10 |
+
**Complexity:** 4/5
|
| 11 |
+
**Nodes:** 8
|
| 12 |
+
**Lanes:** 7
|
| 13 |
+
**Tags:** [agentic, hierarchical, multi-agent, enterprise, architecture-diagram, ai-team]
|
| 14 |
+
**Source path:** ``
|
| 15 |
+
**Repo path:** `agentic/architecture/agentic-hierarchical`
|
| 16 |
+
|
| 17 |
+
## Files
|
| 18 |
+
- `workflow.fz` — FlowZap Code source
|
| 19 |
+
- `metadata.json` — Structured metadata
|
agentic/architecture/agentic-hierarchical/metadata.json
ADDED
|
@@ -0,0 +1,26 @@
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| 1 |
+
{
|
| 2 |
+
"template_id": "agentic-hierarchical",
|
| 3 |
+
"workflow_id": "agentic-hierarchical",
|
| 4 |
+
"title": "Agentic Hierarchical Architecture",
|
| 5 |
+
"kind": "architecture",
|
| 6 |
+
"source_domain": "Architecture",
|
| 7 |
+
"primary_use_case": "agentic",
|
| 8 |
+
"secondary_use_cases": [],
|
| 9 |
+
"use_cases": [
|
| 10 |
+
"agentic"
|
| 11 |
+
],
|
| 12 |
+
"complexity": 4,
|
| 13 |
+
"num_nodes": 8,
|
| 14 |
+
"num_lanes": 7,
|
| 15 |
+
"tags": [
|
| 16 |
+
"agentic",
|
| 17 |
+
"hierarchical",
|
| 18 |
+
"multi-agent",
|
| 19 |
+
"enterprise",
|
| 20 |
+
"architecture-diagram",
|
| 21 |
+
"ai-team"
|
| 22 |
+
],
|
| 23 |
+
"description": "A hierarchical multi-agent architecture with multi-level organizational structure. A top-level executive agent manages mid-level team lead agents, who each manage their own pool of specialist workers. Teams within teams — the hierarchy maps to domain separation.",
|
| 24 |
+
"source_path": "",
|
| 25 |
+
"repo_path": "agentic/architecture/agentic-hierarchical"
|
| 26 |
+
}
|
agentic/architecture/agentic-hierarchical/workflow.fz
ADDED
|
@@ -0,0 +1,36 @@
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| 1 |
+
executive_agent {# Executive Agent
|
| 2 |
+
n1: rectangle label="Route Master Goal"
|
| 3 |
+
n1.handle(bottom) -> research_lead_agent.n2.handle(top) [label="Assign Research"]
|
| 4 |
+
n1.handle(bottom) -> content_lead_agent.n5.handle(top) [label="Assign Content"]
|
| 5 |
+
}
|
| 6 |
+
|
| 7 |
+
research_lead_agent {# Research Lead Agent
|
| 8 |
+
n2: rectangle label="Manage Retrieval Team"
|
| 9 |
+
n2.handle(bottom) -> web_search_agent.n3.handle(top) [label="Web Task"]
|
| 10 |
+
n2.handle(bottom) -> db_retrieval_agent.n4.handle(top) [label="DB Task"]
|
| 11 |
+
}
|
| 12 |
+
|
| 13 |
+
web_search_agent {# Web Search Agent
|
| 14 |
+
n3: rectangle label="Live Web Search"
|
| 15 |
+
n3.handle(right) -> research_lead_agent.n2.handle(right) [label="Web Data"]
|
| 16 |
+
}
|
| 17 |
+
|
| 18 |
+
db_retrieval_agent {# DB Retrieval Agent
|
| 19 |
+
n4: rectangle label="Internal Knowledge RAG"
|
| 20 |
+
n4.handle(right) -> research_lead_agent.n2.handle(right) [label="Internal Data"]
|
| 21 |
+
}
|
| 22 |
+
|
| 23 |
+
content_lead_agent {# Content Lead Agent
|
| 24 |
+
n5: rectangle label="Manage Production Team"
|
| 25 |
+
n5.handle(bottom) -> writer_agent.n6.handle(top) [label="Draft Topic"]
|
| 26 |
+
}
|
| 27 |
+
|
| 28 |
+
writer_agent {# Writer Agent
|
| 29 |
+
n6: rectangle label="Draft Document"
|
| 30 |
+
n6.handle(bottom) -> qa_agent.n7.handle(top) [label="Draft Text"]
|
| 31 |
+
}
|
| 32 |
+
|
| 33 |
+
qa_agent {# QA Agent
|
| 34 |
+
n7: rectangle label="Fact Check"
|
| 35 |
+
n7.handle(right) -> content_lead_agent.n5.handle(right) [label="Final Content"]
|
| 36 |
+
}
|
agentic/architecture/agentic-supervisor-worker/README.md
ADDED
|
@@ -0,0 +1,19 @@
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| 1 |
+
# Agentic Supervisor-Worker Architecture
|
| 2 |
+
|
| 3 |
+
A supervisor-worker multi-agent architecture where an orchestrator agent receives a high-level goal, breaks it into subtasks, delegates each to specialist worker agents (researcher, writer, QA), monitors execution, handles failures, and synthesizes results. The orchestrator manages but does not execute tasks itself.
|
| 4 |
+
|
| 5 |
+
**Template ID:** `agentic-supervisor-worker`
|
| 6 |
+
**Kind:** architecture
|
| 7 |
+
**Source domain:** Architecture
|
| 8 |
+
**Primary use case:** agentic
|
| 9 |
+
**Secondary use cases:** None
|
| 10 |
+
**Complexity:** 3/5
|
| 11 |
+
**Nodes:** 10
|
| 12 |
+
**Lanes:** 4
|
| 13 |
+
**Tags:** [agentic, supervisor-worker, multi-agent, orchestrator, architecture-diagram, ai-team]
|
| 14 |
+
**Source path:** ``
|
| 15 |
+
**Repo path:** `agentic/architecture/agentic-supervisor-worker`
|
| 16 |
+
|
| 17 |
+
## Files
|
| 18 |
+
- `workflow.fz` — FlowZap Code source
|
| 19 |
+
- `metadata.json` — Structured metadata
|
agentic/architecture/agentic-supervisor-worker/metadata.json
ADDED
|
@@ -0,0 +1,26 @@
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| 1 |
+
{
|
| 2 |
+
"template_id": "agentic-supervisor-worker",
|
| 3 |
+
"workflow_id": "agentic-supervisor-worker",
|
| 4 |
+
"title": "Agentic Supervisor-Worker Architecture",
|
| 5 |
+
"kind": "architecture",
|
| 6 |
+
"source_domain": "Architecture",
|
| 7 |
+
"primary_use_case": "agentic",
|
| 8 |
+
"secondary_use_cases": [],
|
| 9 |
+
"use_cases": [
|
| 10 |
+
"agentic"
|
| 11 |
+
],
|
| 12 |
+
"complexity": 3,
|
| 13 |
+
"num_nodes": 10,
|
| 14 |
+
"num_lanes": 4,
|
| 15 |
+
"tags": [
|
| 16 |
+
"agentic",
|
| 17 |
+
"supervisor-worker",
|
| 18 |
+
"multi-agent",
|
| 19 |
+
"orchestrator",
|
| 20 |
+
"architecture-diagram",
|
| 21 |
+
"ai-team"
|
| 22 |
+
],
|
| 23 |
+
"description": "A supervisor-worker multi-agent architecture where an orchestrator agent receives a high-level goal, breaks it into subtasks, delegates each to specialist worker agents (researcher, writer, QA), monitors execution, handles failures, and synthesizes results. The orchestrator manages but does not execute tasks itself.",
|
| 24 |
+
"source_path": "",
|
| 25 |
+
"repo_path": "agentic/architecture/agentic-supervisor-worker"
|
| 26 |
+
}
|
agentic/architecture/agentic-supervisor-worker/workflow.fz
ADDED
|
@@ -0,0 +1,29 @@
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| 1 |
+
orchestrator_agent {# Orchestrator Agent
|
| 2 |
+
n1: rectangle label="Decompose & Manage Subtasks"
|
| 3 |
+
n5: diamond label="All Passed QA?"
|
| 4 |
+
n6: rectangle label="Synthesize Final Result"
|
| 5 |
+
|
| 6 |
+
n1.handle(bottom) -> researcher_agent.n2.handle(top) [label="Task: Gather Sources"]
|
| 7 |
+
n1.handle(bottom) -> writer_agent.n3.handle(top) [label="Task: Draft"]
|
| 8 |
+
n1.handle(bottom) -> qa_agent.n4.handle(top) [label="Task: Review"]
|
| 9 |
+
|
| 10 |
+
n5.handle(right) -> n6.handle(left) [label="Yes"]
|
| 11 |
+
n5.handle(top) -> writer_agent.n3.handle(top) [label="No (Fix Draft)"]
|
| 12 |
+
}
|
| 13 |
+
|
| 14 |
+
researcher_agent {# Research Agent
|
| 15 |
+
n2: rectangle label="Retrieve Information (Web/RAG)"
|
| 16 |
+
n2.handle(right) -> orchestrator_agent.n1.handle(right) [label="Summary"]
|
| 17 |
+
}
|
| 18 |
+
|
| 19 |
+
writer_agent {# Writer Agent
|
| 20 |
+
n3: rectangle label="Generate Text"
|
| 21 |
+
n3.handle(right) -> orchestrator_agent.n1.handle(right) [label="Draft"]
|
| 22 |
+
}
|
| 23 |
+
|
| 24 |
+
qa_agent {# QA Agent
|
| 25 |
+
n4: rectangle label="Review Output"
|
| 26 |
+
n4.handle(right) -> orchestrator_agent.n5.handle(left) [label="Flags"]
|
| 27 |
+
}
|
| 28 |
+
|
| 29 |
+
loop [retry loop] writer_agent.n3 qa_agent.n4 orchestrator_agent.n5
|
agentic/architecture/agentic-swarm/README.md
ADDED
|
@@ -0,0 +1,19 @@
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| 1 |
+
# Agentic Swarm Architecture
|
| 2 |
+
|
| 3 |
+
A swarm multi-agent architecture where multiple agents work on the same or related tasks simultaneously, with no central coordinator. Their outputs are then aggregated, voted on, or merged by a dedicated aggregator node. Agents may compete — the best output wins.
|
| 4 |
+
|
| 5 |
+
**Template ID:** `agentic-swarm`
|
| 6 |
+
**Kind:** architecture
|
| 7 |
+
**Source domain:** Architecture
|
| 8 |
+
**Primary use case:** agentic
|
| 9 |
+
**Secondary use cases:** None
|
| 10 |
+
**Complexity:** 3/5
|
| 11 |
+
**Nodes:** 6
|
| 12 |
+
**Lanes:** 5
|
| 13 |
+
**Tags:** [agentic, swarm, multi-agent, parallel, aggregator, architecture-diagram, ai-team]
|
| 14 |
+
**Source path:** ``
|
| 15 |
+
**Repo path:** `agentic/architecture/agentic-swarm`
|
| 16 |
+
|
| 17 |
+
## Files
|
| 18 |
+
- `workflow.fz` — FlowZap Code source
|
| 19 |
+
- `metadata.json` — Structured metadata
|
agentic/architecture/agentic-swarm/metadata.json
ADDED
|
@@ -0,0 +1,27 @@
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| 1 |
+
{
|
| 2 |
+
"template_id": "agentic-swarm",
|
| 3 |
+
"workflow_id": "agentic-swarm",
|
| 4 |
+
"title": "Agentic Swarm Architecture",
|
| 5 |
+
"kind": "architecture",
|
| 6 |
+
"source_domain": "Architecture",
|
| 7 |
+
"primary_use_case": "agentic",
|
| 8 |
+
"secondary_use_cases": [],
|
| 9 |
+
"use_cases": [
|
| 10 |
+
"agentic"
|
| 11 |
+
],
|
| 12 |
+
"complexity": 3,
|
| 13 |
+
"num_nodes": 6,
|
| 14 |
+
"num_lanes": 5,
|
| 15 |
+
"tags": [
|
| 16 |
+
"agentic",
|
| 17 |
+
"swarm",
|
| 18 |
+
"multi-agent",
|
| 19 |
+
"parallel",
|
| 20 |
+
"aggregator",
|
| 21 |
+
"architecture-diagram",
|
| 22 |
+
"ai-team"
|
| 23 |
+
],
|
| 24 |
+
"description": "A swarm multi-agent architecture where multiple agents work on the same or related tasks simultaneously, with no central coordinator. Their outputs are then aggregated, voted on, or merged by a dedicated aggregator node. Agents may compete — the best output wins.",
|
| 25 |
+
"source_path": "",
|
| 26 |
+
"repo_path": "agentic/architecture/agentic-swarm"
|
| 27 |
+
}
|
agentic/architecture/agentic-swarm/workflow.fz
ADDED
|
@@ -0,0 +1,25 @@
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| 1 |
+
dispatcher_agent {# Dispatcher Agent
|
| 2 |
+
n1: rectangle label="Split Goals & Dispatch"
|
| 3 |
+
n1.handle(bottom) -> research_agent_a.n2.handle(top) [label="Explore Angle 1"]
|
| 4 |
+
n1.handle(bottom) -> research_agent_b.n3.handle(top) [label="Explore Angle 2"]
|
| 5 |
+
n1.handle(bottom) -> research_agent_c.n4.handle(top) [label="Explore Angle 3"]
|
| 6 |
+
}
|
| 7 |
+
|
| 8 |
+
research_agent_a {# Research Agent A
|
| 9 |
+
n2: rectangle label="Parallel Search A"
|
| 10 |
+
n2.handle(bottom) -> aggregator_agent.n5.handle(top) [label="Findings A"]
|
| 11 |
+
}
|
| 12 |
+
|
| 13 |
+
research_agent_b {# Research Agent B
|
| 14 |
+
n3: rectangle label="Parallel Search B"
|
| 15 |
+
n3.handle(bottom) -> aggregator_agent.n5.handle(top) [label="Findings B"]
|
| 16 |
+
}
|
| 17 |
+
|
| 18 |
+
research_agent_c {# Research Agent C
|
| 19 |
+
n4: rectangle label="Parallel Search C"
|
| 20 |
+
n4.handle(bottom) -> aggregator_agent.n5.handle(top) [label="Findings C"]
|
| 21 |
+
}
|
| 22 |
+
|
| 23 |
+
aggregator_agent {# Aggregator Agent
|
| 24 |
+
n5: rectangle label="Merge & Deduplicate"
|
| 25 |
+
}
|
agentic/architecture/agentic-team-of-rivals/README.md
ADDED
|
@@ -0,0 +1,19 @@
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| 1 |
+
# Agentic Team of Rivals Architecture
|
| 2 |
+
|
| 3 |
+
The most architecturally sophisticated multi-agent pattern. Agents are assigned not just roles but opposing incentives. A Planner is optimistic about goal completion. A Critic is constitutionally skeptical and holds veto authority. Errors get caught through adversarial pressure rather than trusting a single model's self-assessment.
|
| 4 |
+
|
| 5 |
+
**Template ID:** `agentic-team-of-rivals`
|
| 6 |
+
**Kind:** architecture
|
| 7 |
+
**Source domain:** Architecture
|
| 8 |
+
**Primary use case:** agentic
|
| 9 |
+
**Secondary use cases:** None
|
| 10 |
+
**Complexity:** 3/5
|
| 11 |
+
**Nodes:** 5
|
| 12 |
+
**Lanes:** 3
|
| 13 |
+
**Tags:** [agentic, team-of-rivals, multi-agent, critic, veto, architecture-diagram, ai-team]
|
| 14 |
+
**Source path:** ``
|
| 15 |
+
**Repo path:** `agentic/architecture/agentic-team-of-rivals`
|
| 16 |
+
|
| 17 |
+
## Files
|
| 18 |
+
- `workflow.fz` — FlowZap Code source
|
| 19 |
+
- `metadata.json` — Structured metadata
|
agentic/architecture/agentic-team-of-rivals/metadata.json
ADDED
|
@@ -0,0 +1,27 @@
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| 1 |
+
{
|
| 2 |
+
"template_id": "agentic-team-of-rivals",
|
| 3 |
+
"workflow_id": "agentic-team-of-rivals",
|
| 4 |
+
"title": "Agentic Team of Rivals Architecture",
|
| 5 |
+
"kind": "architecture",
|
| 6 |
+
"source_domain": "Architecture",
|
| 7 |
+
"primary_use_case": "agentic",
|
| 8 |
+
"secondary_use_cases": [],
|
| 9 |
+
"use_cases": [
|
| 10 |
+
"agentic"
|
| 11 |
+
],
|
| 12 |
+
"complexity": 3,
|
| 13 |
+
"num_nodes": 5,
|
| 14 |
+
"num_lanes": 3,
|
| 15 |
+
"tags": [
|
| 16 |
+
"agentic",
|
| 17 |
+
"team-of-rivals",
|
| 18 |
+
"multi-agent",
|
| 19 |
+
"critic",
|
| 20 |
+
"veto",
|
| 21 |
+
"architecture-diagram",
|
| 22 |
+
"ai-team"
|
| 23 |
+
],
|
| 24 |
+
"description": "The most architecturally sophisticated multi-agent pattern. Agents are assigned not just roles but opposing incentives. A Planner is optimistic about goal completion. A Critic is constitutionally skeptical and holds veto authority. Errors get caught through adversarial pressure rather than trusting a single model's self-assessment.",
|
| 25 |
+
"source_path": "",
|
| 26 |
+
"repo_path": "agentic/architecture/agentic-team-of-rivals"
|
| 27 |
+
}
|
agentic/architecture/agentic-team-of-rivals/workflow.fz
ADDED
|
@@ -0,0 +1,19 @@
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| 1 |
+
planner_agent {# Planner Agent
|
| 2 |
+
n1: rectangle label="Declare Step-by-Step Plan & Acceptance Criteria"
|
| 3 |
+
n1.handle(right) -> executor_agent.n2.handle(left) [label="Task Plan + Criteria"]
|
| 4 |
+
}
|
| 5 |
+
|
| 6 |
+
executor_agent {# Executor Agent
|
| 7 |
+
n2: rectangle label="Execute Remote Code & Tools"
|
| 8 |
+
n2.handle(right) -> critic_agent.n3.handle(left) [label="Execution Summary"]
|
| 9 |
+
}
|
| 10 |
+
|
| 11 |
+
critic_agent {# Critic Agent
|
| 12 |
+
n3: rectangle label="Validate vs Acceptance Criteria"
|
| 13 |
+
n4: diamond label="Passed Gate?"
|
| 14 |
+
|
| 15 |
+
n3.handle(bottom) -> n4.handle(top)
|
| 16 |
+
n4.handle(top) -> planner_agent.n1.handle(bottom) [label="Veto (Reject & Explain)"]
|
| 17 |
+
}
|
| 18 |
+
|
| 19 |
+
loop [Rejection Iteration] planner_agent.n1 executor_agent.n2 critic_agent.n3 critic_agent.n4
|
agentic/architecture/ai-native-event-driven-kafka-architecture/README.md
ADDED
|
@@ -0,0 +1,19 @@
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| 1 |
+
# AI-Native Event-Driven Kafka Architecture
|
| 2 |
+
|
| 3 |
+
An event-driven agentic AI architecture that replaces the central orchestrator with Kafka/PubSub topics: agents subscribe, react, and publish new events. This aligns multi-agent systems with proven microservices choreography and is ideal for real-time, high-throughput systems and 'agent mesh' setups.
|
| 4 |
+
|
| 5 |
+
**Template ID:** `ai-native-event-driven-kafka-architecture`
|
| 6 |
+
**Kind:** architecture
|
| 7 |
+
**Source domain:** Architecture
|
| 8 |
+
**Primary use case:** agentic
|
| 9 |
+
**Secondary use cases:** ai-orchestration, mcp
|
| 10 |
+
**Complexity:** 3/5
|
| 11 |
+
**Nodes:** 12
|
| 12 |
+
**Lanes:** 5
|
| 13 |
+
**Tags:** [ai-native, event-driven, agentic-ai, kafka, pub-sub, agent-mesh, architecture-diagram]
|
| 14 |
+
**Source path:** ``
|
| 15 |
+
**Repo path:** `agentic/architecture/ai-native-event-driven-kafka-architecture`
|
| 16 |
+
|
| 17 |
+
## Files
|
| 18 |
+
- `workflow.fz` — FlowZap Code source
|
| 19 |
+
- `metadata.json` — Structured metadata
|
agentic/architecture/ai-native-event-driven-kafka-architecture/metadata.json
ADDED
|
@@ -0,0 +1,32 @@
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| 1 |
+
{
|
| 2 |
+
"template_id": "ai-native-event-driven-kafka-architecture",
|
| 3 |
+
"workflow_id": "ai-native-event-driven-kafka-architecture",
|
| 4 |
+
"title": "AI-Native Event-Driven Kafka Architecture",
|
| 5 |
+
"kind": "architecture",
|
| 6 |
+
"source_domain": "Architecture",
|
| 7 |
+
"primary_use_case": "agentic",
|
| 8 |
+
"secondary_use_cases": [
|
| 9 |
+
"ai-orchestration",
|
| 10 |
+
"mcp"
|
| 11 |
+
],
|
| 12 |
+
"use_cases": [
|
| 13 |
+
"agentic",
|
| 14 |
+
"ai-orchestration",
|
| 15 |
+
"mcp"
|
| 16 |
+
],
|
| 17 |
+
"complexity": 3,
|
| 18 |
+
"num_nodes": 12,
|
| 19 |
+
"num_lanes": 5,
|
| 20 |
+
"tags": [
|
| 21 |
+
"ai-native",
|
| 22 |
+
"event-driven",
|
| 23 |
+
"agentic-ai",
|
| 24 |
+
"kafka",
|
| 25 |
+
"pub-sub",
|
| 26 |
+
"agent-mesh",
|
| 27 |
+
"architecture-diagram"
|
| 28 |
+
],
|
| 29 |
+
"description": "An event-driven agentic AI architecture that replaces the central orchestrator with Kafka/PubSub topics: agents subscribe, react, and publish new events. This aligns multi-agent systems with proven microservices choreography and is ideal for real-time, high-throughput systems and 'agent mesh' setups.",
|
| 30 |
+
"source_path": "",
|
| 31 |
+
"repo_path": "agentic/architecture/ai-native-event-driven-kafka-architecture"
|
| 32 |
+
}
|
agentic/architecture/ai-native-event-driven-kafka-architecture/workflow.fz
ADDED
|
@@ -0,0 +1,35 @@
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| 1 |
+
Source { # Event Sources
|
| 2 |
+
n1: circle label:"Start"
|
| 3 |
+
n2: rectangle label:"User action event"
|
| 4 |
+
n3: rectangle label:"System alert event"
|
| 5 |
+
n1.handle(right) -> n2.handle(left)
|
| 6 |
+
n2.handle(bottom) -> Broker.n4.handle(top) [label="Publish event"]
|
| 7 |
+
n3.handle(bottom) -> Broker.n4.handle(top) [label="Publish event"]
|
| 8 |
+
}
|
| 9 |
+
Broker { # Event Broker (Kafka / Pub-Sub)
|
| 10 |
+
n4: rectangle label:"Event bus receives event"
|
| 11 |
+
n5: rectangle label:"Route to subscribers"
|
| 12 |
+
n4.handle(right) -> n5.handle(left)
|
| 13 |
+
n5.handle(bottom) -> Orders.n6.handle(top) [label="topic: orders"]
|
| 14 |
+
n5.handle(bottom) -> Alerts.n8.handle(top) [label="topic: alerts"]
|
| 15 |
+
n5.handle(bottom) -> Analytics.n10.handle(top) [label="topic: analytics"]
|
| 16 |
+
}
|
| 17 |
+
Orders { # Order Processing Agent
|
| 18 |
+
n6: rectangle label:"Parse order event"
|
| 19 |
+
n7: rectangle label:"Execute fulfillment"
|
| 20 |
+
n6.handle(right) -> n7.handle(left)
|
| 21 |
+
n7.handle(bottom) -> Broker.n4.handle(top) [label="Publish: order.completed"]
|
| 22 |
+
}
|
| 23 |
+
Alerts { # Alert Triage Agent
|
| 24 |
+
n8: rectangle label:"Classify severity"
|
| 25 |
+
n9: rectangle label:"Route to on-call or auto-resolve"
|
| 26 |
+
n8.handle(right) -> n9.handle(left)
|
| 27 |
+
n9.handle(bottom) -> Broker.n4.handle(top) [label="Publish: alert.resolved"]
|
| 28 |
+
}
|
| 29 |
+
Analytics { # Analytics Agent
|
| 30 |
+
n10: rectangle label:"Aggregate metrics"
|
| 31 |
+
n11: rectangle label:"Update dashboard"
|
| 32 |
+
n12: circle label:"Stored"
|
| 33 |
+
n10.handle(right) -> n11.handle(left)
|
| 34 |
+
n11.handle(right) -> n12.handle(left)
|
| 35 |
+
}
|
agentic/architecture/ai-native-generator-critic-architecture/README.md
ADDED
|
@@ -0,0 +1,19 @@
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| 1 |
+
# AI-Native Generator-Critic Architecture
|
| 2 |
+
|
| 3 |
+
A competitive / generator-critic architecture where multiple generators produce independent answers, then an evaluator agent scores and selects the best output. This approach improves quality and reduces single-model brittleness. It's costlier (multiple LLM calls) but pays off when correctness or creativity matters more than latency.
|
| 4 |
+
|
| 5 |
+
**Template ID:** `ai-native-generator-critic-architecture`
|
| 6 |
+
**Kind:** architecture
|
| 7 |
+
**Source domain:** Architecture
|
| 8 |
+
**Primary use case:** agentic
|
| 9 |
+
**Secondary use cases:** ai-orchestration
|
| 10 |
+
**Complexity:** 3/5
|
| 11 |
+
**Nodes:** 9
|
| 12 |
+
**Lanes:** 3
|
| 13 |
+
**Tags:** [ai-native, generator-critic, agentic-ai, tournament-mode, multi-agent, architecture-diagram]
|
| 14 |
+
**Source path:** ``
|
| 15 |
+
**Repo path:** `agentic/architecture/ai-native-generator-critic-architecture`
|
| 16 |
+
|
| 17 |
+
## Files
|
| 18 |
+
- `workflow.fz` — FlowZap Code source
|
| 19 |
+
- `metadata.json` — Structured metadata
|
agentic/architecture/ai-native-generator-critic-architecture/metadata.json
ADDED
|
@@ -0,0 +1,29 @@
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| 1 |
+
{
|
| 2 |
+
"template_id": "ai-native-generator-critic-architecture",
|
| 3 |
+
"workflow_id": "ai-native-generator-critic-architecture",
|
| 4 |
+
"title": "AI-Native Generator-Critic Architecture",
|
| 5 |
+
"kind": "architecture",
|
| 6 |
+
"source_domain": "Architecture",
|
| 7 |
+
"primary_use_case": "agentic",
|
| 8 |
+
"secondary_use_cases": [
|
| 9 |
+
"ai-orchestration"
|
| 10 |
+
],
|
| 11 |
+
"use_cases": [
|
| 12 |
+
"agentic",
|
| 13 |
+
"ai-orchestration"
|
| 14 |
+
],
|
| 15 |
+
"complexity": 3,
|
| 16 |
+
"num_nodes": 9,
|
| 17 |
+
"num_lanes": 3,
|
| 18 |
+
"tags": [
|
| 19 |
+
"ai-native",
|
| 20 |
+
"generator-critic",
|
| 21 |
+
"agentic-ai",
|
| 22 |
+
"tournament-mode",
|
| 23 |
+
"multi-agent",
|
| 24 |
+
"architecture-diagram"
|
| 25 |
+
],
|
| 26 |
+
"description": "A competitive / generator-critic architecture where multiple generators produce independent answers, then an evaluator agent scores and selects the best output. This approach improves quality and reduces single-model brittleness. It's costlier (multiple LLM calls) but pays off when correctness or creativity matters more than latency.",
|
| 27 |
+
"source_path": "",
|
| 28 |
+
"repo_path": "agentic/architecture/ai-native-generator-critic-architecture"
|
| 29 |
+
}
|
agentic/architecture/ai-native-generator-critic-architecture/workflow.fz
ADDED
|
@@ -0,0 +1,27 @@
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| 1 |
+
Input { # Input
|
| 2 |
+
n1: circle label:"Start"
|
| 3 |
+
n2: rectangle label:"Creative brief submitted"
|
| 4 |
+
n1.handle(right) -> n2.handle(left)
|
| 5 |
+
n2.handle(bottom) -> Generators.n3.handle(top) [label="Brief"]
|
| 6 |
+
n2.handle(bottom) -> Generators.n4.handle(top) [label="Brief"]
|
| 7 |
+
n2.handle(bottom) -> Generators.n5.handle(top) [label="Brief"]
|
| 8 |
+
}
|
| 9 |
+
Generators { # Generator Agents
|
| 10 |
+
n3: rectangle label:"Agent A: Draft option 1"
|
| 11 |
+
n4: rectangle label:"Agent B: Draft option 2"
|
| 12 |
+
n5: rectangle label:"Agent C: Draft option 3"
|
| 13 |
+
n3.handle(bottom) -> Evaluator.n6.handle(top) [label="Option 1"]
|
| 14 |
+
n4.handle(bottom) -> Evaluator.n6.handle(top) [label="Option 2"]
|
| 15 |
+
n5.handle(bottom) -> Evaluator.n6.handle(top) [label="Option 3"]
|
| 16 |
+
}
|
| 17 |
+
Evaluator { # Evaluator Agent
|
| 18 |
+
n6: rectangle label:"Score all options"
|
| 19 |
+
n7: diamond label:"Quality threshold met?"
|
| 20 |
+
n8: rectangle label:"Select best output"
|
| 21 |
+
n9: circle label:"Done"
|
| 22 |
+
n6.handle(right) -> n7.handle(left)
|
| 23 |
+
n7.handle(right) -> n8.handle(left) [label="Yes"]
|
| 24 |
+
n7.handle(top) -> Generators.n3.handle(bottom) [label="No - Refine"]
|
| 25 |
+
n8.handle(right) -> n9.handle(left)
|
| 26 |
+
loop [refine until quality threshold met] n3 n4 n5 n6 n7
|
| 27 |
+
}
|
agentic/architecture/ai-native-hierarchical-architecture/README.md
ADDED
|
@@ -0,0 +1,19 @@
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| 1 |
+
# AI-Native Hierarchical Architecture
|
| 2 |
+
|
| 3 |
+
A hierarchical multi-agent architecture that scales orchestration by stacking supervisors and team leads (a tree structure), which mirrors enterprise org structures and helps partition context. This is the 'enterprise-grade agentic AI architecture' when a single orchestrator cannot manage all workers directly. Ideal for large enterprises and multi-domain workflows.
|
| 4 |
+
|
| 5 |
+
**Template ID:** `ai-native-hierarchical-architecture`
|
| 6 |
+
**Kind:** architecture
|
| 7 |
+
**Source domain:** Architecture
|
| 8 |
+
**Primary use case:** agentic
|
| 9 |
+
**Secondary use cases:** ai-orchestration
|
| 10 |
+
**Complexity:** 4/5
|
| 11 |
+
**Nodes:** 16
|
| 12 |
+
**Lanes:** 4
|
| 13 |
+
**Tags:** [ai-native, hierarchical, agentic-ai, enterprise, multi-agent, architecture-diagram]
|
| 14 |
+
**Source path:** ``
|
| 15 |
+
**Repo path:** `agentic/architecture/ai-native-hierarchical-architecture`
|
| 16 |
+
|
| 17 |
+
## Files
|
| 18 |
+
- `workflow.fz` — FlowZap Code source
|
| 19 |
+
- `metadata.json` — Structured metadata
|
agentic/architecture/ai-native-hierarchical-architecture/metadata.json
ADDED
|
@@ -0,0 +1,29 @@
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| 1 |
+
{
|
| 2 |
+
"template_id": "ai-native-hierarchical-architecture",
|
| 3 |
+
"workflow_id": "ai-native-hierarchical-architecture",
|
| 4 |
+
"title": "AI-Native Hierarchical Architecture",
|
| 5 |
+
"kind": "architecture",
|
| 6 |
+
"source_domain": "Architecture",
|
| 7 |
+
"primary_use_case": "agentic",
|
| 8 |
+
"secondary_use_cases": [
|
| 9 |
+
"ai-orchestration"
|
| 10 |
+
],
|
| 11 |
+
"use_cases": [
|
| 12 |
+
"agentic",
|
| 13 |
+
"ai-orchestration"
|
| 14 |
+
],
|
| 15 |
+
"complexity": 4,
|
| 16 |
+
"num_nodes": 16,
|
| 17 |
+
"num_lanes": 4,
|
| 18 |
+
"tags": [
|
| 19 |
+
"ai-native",
|
| 20 |
+
"hierarchical",
|
| 21 |
+
"agentic-ai",
|
| 22 |
+
"enterprise",
|
| 23 |
+
"multi-agent",
|
| 24 |
+
"architecture-diagram"
|
| 25 |
+
],
|
| 26 |
+
"description": "A hierarchical multi-agent architecture that scales orchestration by stacking supervisors and team leads (a tree structure), which mirrors enterprise org structures and helps partition context. This is the 'enterprise-grade agentic AI architecture' when a single orchestrator cannot manage all workers directly. Ideal for large enterprises and multi-domain workflows.",
|
| 27 |
+
"source_path": "",
|
| 28 |
+
"repo_path": "agentic/architecture/ai-native-hierarchical-architecture"
|
| 29 |
+
}
|
agentic/architecture/ai-native-hierarchical-architecture/workflow.fz
ADDED
|
@@ -0,0 +1,45 @@
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| 1 |
+
User { # User
|
| 2 |
+
n1: circle label:"Start"
|
| 3 |
+
n2: rectangle label:"Submit enterprise request"
|
| 4 |
+
n1.handle(right) -> n2.handle(left)
|
| 5 |
+
n2.handle(bottom) -> Supervisor.n3.handle(top) [label="Goal"]
|
| 6 |
+
}
|
| 7 |
+
Supervisor { # Top-Level Supervisor
|
| 8 |
+
n3: rectangle label:"Decompose goal"
|
| 9 |
+
n4: rectangle label:"Delegate to team leads"
|
| 10 |
+
n5: rectangle label:"Aggregate final output"
|
| 11 |
+
n6: circle label:"Done"
|
| 12 |
+
n3.handle(right) -> n4.handle(left)
|
| 13 |
+
n4.handle(bottom) -> LeadA.n7.handle(top) [label="Sub-goal A"]
|
| 14 |
+
n4.handle(bottom) -> LeadB.n10.handle(top) [label="Sub-goal B"]
|
| 15 |
+
n5.handle(right) -> n6.handle(left)
|
| 16 |
+
n5.handle(top) -> User.n2.handle(bottom) [label="Final report"]
|
| 17 |
+
}
|
| 18 |
+
LeadA { # Team Lead A
|
| 19 |
+
n7: rectangle label:"Plan subtasks for A"
|
| 20 |
+
n8: rectangle label:"Dispatch to workers"
|
| 21 |
+
n9: rectangle label:"Consolidate A results"
|
| 22 |
+
n7.handle(right) -> n8.handle(left)
|
| 23 |
+
n8.handle(bottom) -> Workers.n13.handle(top) [label="Task A1"]
|
| 24 |
+
n8.handle(bottom) -> Workers.n14.handle(top) [label="Task A2"]
|
| 25 |
+
n9.handle(top) -> Supervisor.n5.handle(bottom) [label="Result A"]
|
| 26 |
+
}
|
| 27 |
+
LeadB { # Team Lead B
|
| 28 |
+
n10: rectangle label:"Plan subtasks for B"
|
| 29 |
+
n11: rectangle label:"Dispatch to workers"
|
| 30 |
+
n12: rectangle label:"Consolidate B results"
|
| 31 |
+
n10.handle(right) -> n11.handle(left)
|
| 32 |
+
n11.handle(bottom) -> Workers.n15.handle(top) [label="Task B1"]
|
| 33 |
+
n11.handle(bottom) -> Workers.n16.handle(top) [label="Task B2"]
|
| 34 |
+
n12.handle(top) -> Supervisor.n5.handle(bottom) [label="Result B"]
|
| 35 |
+
}
|
| 36 |
+
Workers { # Worker Agents
|
| 37 |
+
n13: rectangle label:"Worker A1 executes"
|
| 38 |
+
n14: rectangle label:"Worker A2 executes"
|
| 39 |
+
n15: rectangle label:"Worker B1 executes"
|
| 40 |
+
n16: rectangle label:"Worker B2 executes"
|
| 41 |
+
n13.handle(top) -> LeadA.n9.handle(bottom) [label="A1 done"]
|
| 42 |
+
n14.handle(top) -> LeadA.n9.handle(bottom) [label="A2 done"]
|
| 43 |
+
n15.handle(top) -> LeadB.n12.handle(bottom) [label="B1 done"]
|
| 44 |
+
n16.handle(top) -> LeadB.n12.handle(bottom) [label="B2 done"]
|
| 45 |
+
}
|
agentic/architecture/ai-native-orchestrator-worker-architecture/README.md
ADDED
|
@@ -0,0 +1,19 @@
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| 1 |
+
# AI-Native Orchestrator-Worker Architecture
|
| 2 |
+
|
| 3 |
+
An orchestrator-worker architecture where an orchestrator agent breaks a goal into subtasks, dispatches to specialized workers, then synthesizes a final response. This is the most common 'agent orchestration' architecture—powerful but the orchestrator can become a bottleneck as the number of workers grows. Frameworks like LangGraph focus on explicit routing/state to manage this.
|
| 4 |
+
|
| 5 |
+
**Template ID:** `ai-native-orchestrator-worker-architecture`
|
| 6 |
+
**Kind:** architecture
|
| 7 |
+
**Source domain:** Architecture
|
| 8 |
+
**Primary use case:** agentic
|
| 9 |
+
**Secondary use cases:** ai-orchestration
|
| 10 |
+
**Complexity:** 3/5
|
| 11 |
+
**Nodes:** 14
|
| 12 |
+
**Lanes:** 4
|
| 13 |
+
**Tags:** [ai-native, orchestrator-worker, agentic-ai, langgraph, multi-agent, architecture-diagram]
|
| 14 |
+
**Source path:** ``
|
| 15 |
+
**Repo path:** `agentic/architecture/ai-native-orchestrator-worker-architecture`
|
| 16 |
+
|
| 17 |
+
## Files
|
| 18 |
+
- `workflow.fz` — FlowZap Code source
|
| 19 |
+
- `metadata.json` — Structured metadata
|
agentic/architecture/ai-native-orchestrator-worker-architecture/metadata.json
ADDED
|
@@ -0,0 +1,29 @@
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| 1 |
+
{
|
| 2 |
+
"template_id": "ai-native-orchestrator-worker-architecture",
|
| 3 |
+
"workflow_id": "ai-native-orchestrator-worker-architecture",
|
| 4 |
+
"title": "AI-Native Orchestrator-Worker Architecture",
|
| 5 |
+
"kind": "architecture",
|
| 6 |
+
"source_domain": "Architecture",
|
| 7 |
+
"primary_use_case": "agentic",
|
| 8 |
+
"secondary_use_cases": [
|
| 9 |
+
"ai-orchestration"
|
| 10 |
+
],
|
| 11 |
+
"use_cases": [
|
| 12 |
+
"agentic",
|
| 13 |
+
"ai-orchestration"
|
| 14 |
+
],
|
| 15 |
+
"complexity": 3,
|
| 16 |
+
"num_nodes": 14,
|
| 17 |
+
"num_lanes": 4,
|
| 18 |
+
"tags": [
|
| 19 |
+
"ai-native",
|
| 20 |
+
"orchestrator-worker",
|
| 21 |
+
"agentic-ai",
|
| 22 |
+
"langgraph",
|
| 23 |
+
"multi-agent",
|
| 24 |
+
"architecture-diagram"
|
| 25 |
+
],
|
| 26 |
+
"description": "An orchestrator-worker architecture where an orchestrator agent breaks a goal into subtasks, dispatches to specialized workers, then synthesizes a final response. This is the most common 'agent orchestration' architecture—powerful but the orchestrator can become a bottleneck as the number of workers grows. Frameworks like LangGraph focus on explicit routing/state to manage this.",
|
| 27 |
+
"source_path": "",
|
| 28 |
+
"repo_path": "agentic/architecture/ai-native-orchestrator-worker-architecture"
|
| 29 |
+
}
|
agentic/architecture/ai-native-orchestrator-worker-architecture/workflow.fz
ADDED
|
@@ -0,0 +1,40 @@
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| 1 |
+
User { # User
|
| 2 |
+
n1: circle label:"Start"
|
| 3 |
+
n2: rectangle label:"Submit complex task"
|
| 4 |
+
n1.handle(right) -> n2.handle(left)
|
| 5 |
+
n2.handle(bottom) -> Orchestrator.n3.handle(top) [label="Task"]
|
| 6 |
+
}
|
| 7 |
+
Orchestrator { # Orchestrator Agent
|
| 8 |
+
n3: rectangle label:"Receive task"
|
| 9 |
+
n4: rectangle label:"Break into subtasks"
|
| 10 |
+
n5: rectangle label:"Dispatch subtasks"
|
| 11 |
+
n6: rectangle label:"Collect results"
|
| 12 |
+
n7: rectangle label:"Synthesize final answer"
|
| 13 |
+
n8: circle label:"Done"
|
| 14 |
+
n3.handle(right) -> n4.handle(left)
|
| 15 |
+
n4.handle(right) -> n5.handle(left)
|
| 16 |
+
n5.handle(bottom) -> Research.n9.handle(top) [label="Research subtask"]
|
| 17 |
+
n5.handle(bottom) -> Code.n11.handle(top) [label="Code subtask"]
|
| 18 |
+
n5.handle(bottom) -> Review.n13.handle(top) [label="Review subtask"]
|
| 19 |
+
n6.handle(right) -> n7.handle(left)
|
| 20 |
+
n7.handle(right) -> n8.handle(left)
|
| 21 |
+
n7.handle(top) -> User.n2.handle(bottom) [label="Response"]
|
| 22 |
+
}
|
| 23 |
+
Research { # Research Agent
|
| 24 |
+
n9: rectangle label:"Search sources"
|
| 25 |
+
n10: rectangle label:"Summarize findings"
|
| 26 |
+
n9.handle(right) -> n10.handle(left)
|
| 27 |
+
n10.handle(top) -> Orchestrator.n6.handle(bottom) [label="Research result"]
|
| 28 |
+
}
|
| 29 |
+
Code { # Code Agent
|
| 30 |
+
n11: rectangle label:"Generate code"
|
| 31 |
+
n12: rectangle label:"Run tests"
|
| 32 |
+
n11.handle(right) -> n12.handle(left)
|
| 33 |
+
n12.handle(top) -> Orchestrator.n6.handle(bottom) [label="Code result"]
|
| 34 |
+
}
|
| 35 |
+
Review { # Review Agent
|
| 36 |
+
n13: rectangle label:"Evaluate quality"
|
| 37 |
+
n14: rectangle label:"Flag issues"
|
| 38 |
+
n13.handle(right) -> n14.handle(left)
|
| 39 |
+
n14.handle(top) -> Orchestrator.n6.handle(bottom) [label="Review result"]
|
| 40 |
+
}
|
agentic/architecture/ai-native-single-agent-architecture/README.md
ADDED
|
@@ -0,0 +1,19 @@
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| 1 |
+
# AI-Native Single Agent Architecture
|
| 2 |
+
|
| 3 |
+
A single-agent AI architecture where one agent handles everything: parsing requests, reasoning, calling tools via MCP, and generating responses. This is the default architecture for prototypes and simple automations—easy to debug but hits context-window limits quickly and is hard to parallelize. Ideal for MVPs and solo builders shipping fast.
|
| 4 |
+
|
| 5 |
+
**Template ID:** `ai-native-single-agent-architecture`
|
| 6 |
+
**Kind:** architecture
|
| 7 |
+
**Source domain:** Architecture
|
| 8 |
+
**Primary use case:** agentic
|
| 9 |
+
**Secondary use cases:** ai-orchestration, mcp
|
| 10 |
+
**Complexity:** 2/5
|
| 11 |
+
**Nodes:** 11
|
| 12 |
+
**Lanes:** 3
|
| 13 |
+
**Tags:** [ai-native, single-agent, agentic-ai, mcp, architecture-diagram]
|
| 14 |
+
**Source path:** ``
|
| 15 |
+
**Repo path:** `agentic/architecture/ai-native-single-agent-architecture`
|
| 16 |
+
|
| 17 |
+
## Files
|
| 18 |
+
- `workflow.fz` — FlowZap Code source
|
| 19 |
+
- `metadata.json` — Structured metadata
|
agentic/architecture/ai-native-single-agent-architecture/metadata.json
ADDED
|
@@ -0,0 +1,30 @@
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| 1 |
+
{
|
| 2 |
+
"template_id": "ai-native-single-agent-architecture",
|
| 3 |
+
"workflow_id": "ai-native-single-agent-architecture",
|
| 4 |
+
"title": "AI-Native Single Agent Architecture",
|
| 5 |
+
"kind": "architecture",
|
| 6 |
+
"source_domain": "Architecture",
|
| 7 |
+
"primary_use_case": "agentic",
|
| 8 |
+
"secondary_use_cases": [
|
| 9 |
+
"ai-orchestration",
|
| 10 |
+
"mcp"
|
| 11 |
+
],
|
| 12 |
+
"use_cases": [
|
| 13 |
+
"agentic",
|
| 14 |
+
"ai-orchestration",
|
| 15 |
+
"mcp"
|
| 16 |
+
],
|
| 17 |
+
"complexity": 2,
|
| 18 |
+
"num_nodes": 11,
|
| 19 |
+
"num_lanes": 3,
|
| 20 |
+
"tags": [
|
| 21 |
+
"ai-native",
|
| 22 |
+
"single-agent",
|
| 23 |
+
"agentic-ai",
|
| 24 |
+
"mcp",
|
| 25 |
+
"architecture-diagram"
|
| 26 |
+
],
|
| 27 |
+
"description": "A single-agent AI architecture where one agent handles everything: parsing requests, reasoning, calling tools via MCP, and generating responses. This is the default architecture for prototypes and simple automations—easy to debug but hits context-window limits quickly and is hard to parallelize. Ideal for MVPs and solo builders shipping fast.",
|
| 28 |
+
"source_path": "",
|
| 29 |
+
"repo_path": "agentic/architecture/ai-native-single-agent-architecture"
|
| 30 |
+
}
|
agentic/architecture/ai-native-single-agent-architecture/workflow.fz
ADDED
|
@@ -0,0 +1,29 @@
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| 1 |
+
User { # User
|
| 2 |
+
n1: circle label:"Start"
|
| 3 |
+
n2: rectangle label:"Send request"
|
| 4 |
+
n1.handle(right) -> n2.handle(left)
|
| 5 |
+
n2.handle(bottom) -> Agent.n3.handle(top) [label="Request"]
|
| 6 |
+
}
|
| 7 |
+
Agent { # Single AI Agent
|
| 8 |
+
n3: rectangle label:"Receive input"
|
| 9 |
+
n4: rectangle label:"Reason and plan"
|
| 10 |
+
n5: rectangle label:"Decide tool call"
|
| 11 |
+
n6: rectangle label:"Process tool result"
|
| 12 |
+
n7: rectangle label:"Generate response"
|
| 13 |
+
n8: circle label:"Done"
|
| 14 |
+
n3.handle(right) -> n4.handle(left)
|
| 15 |
+
n4.handle(right) -> n5.handle(left)
|
| 16 |
+
n5.handle(bottom) -> Tools.n9.handle(top) [label="MCP request"]
|
| 17 |
+
n6.handle(right) -> n7.handle(left)
|
| 18 |
+
n7.handle(right) -> n8.handle(left)
|
| 19 |
+
n7.handle(top) -> User.n2.handle(bottom) [label="Response"]
|
| 20 |
+
loop [retry until goal met] n4 n5 n6 n7
|
| 21 |
+
}
|
| 22 |
+
Tools { # Tool Server (MCP)
|
| 23 |
+
n9: rectangle label:"Receive MCP call"
|
| 24 |
+
n10: rectangle label:"Execute tool"
|
| 25 |
+
n11: rectangle label:"Return result"
|
| 26 |
+
n9.handle(right) -> n10.handle(left)
|
| 27 |
+
n10.handle(right) -> n11.handle(left)
|
| 28 |
+
n11.handle(top) -> Agent.n6.handle(bottom) [label="Tool result"]
|
| 29 |
+
}
|
agentic/architecture/ai-orchestration-competitive-generator-critic/README.md
ADDED
|
@@ -0,0 +1,19 @@
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| 1 |
+
# AI Orchestration - Competitive Generator-Critic
|
| 2 |
+
|
| 3 |
+
A tournament-mode architecture where multiple generator agents produce independent outputs in parallel, then an evaluator agent scores and selects the best. Quality threshold checking with refinement loops. Best when correctness or creativity matters more than latency.
|
| 4 |
+
|
| 5 |
+
**Template ID:** `ai-orchestration-competitive-generator-critic`
|
| 6 |
+
**Kind:** architecture
|
| 7 |
+
**Source domain:** Architecture
|
| 8 |
+
**Primary use case:** agentic
|
| 9 |
+
**Secondary use cases:** ai-orchestration
|
| 10 |
+
**Complexity:** 3/5
|
| 11 |
+
**Nodes:** 10
|
| 12 |
+
**Lanes:** 3
|
| 13 |
+
**Tags:** [ai-native, competitive, generator-critic, tournament, multi-agent, architecture-diagram, orchestration]
|
| 14 |
+
**Source path:** ``
|
| 15 |
+
**Repo path:** `agentic/architecture/ai-orchestration-competitive-generator-critic`
|
| 16 |
+
|
| 17 |
+
## Files
|
| 18 |
+
- `workflow.fz` — FlowZap Code source
|
| 19 |
+
- `metadata.json` — Structured metadata
|
agentic/architecture/ai-orchestration-competitive-generator-critic/metadata.json
ADDED
|
@@ -0,0 +1,30 @@
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| 1 |
+
{
|
| 2 |
+
"template_id": "ai-orchestration-competitive-generator-critic",
|
| 3 |
+
"workflow_id": "ai-orchestration-competitive-generator-critic",
|
| 4 |
+
"title": "AI Orchestration - Competitive Generator-Critic",
|
| 5 |
+
"kind": "architecture",
|
| 6 |
+
"source_domain": "Architecture",
|
| 7 |
+
"primary_use_case": "agentic",
|
| 8 |
+
"secondary_use_cases": [
|
| 9 |
+
"ai-orchestration"
|
| 10 |
+
],
|
| 11 |
+
"use_cases": [
|
| 12 |
+
"agentic",
|
| 13 |
+
"ai-orchestration"
|
| 14 |
+
],
|
| 15 |
+
"complexity": 3,
|
| 16 |
+
"num_nodes": 10,
|
| 17 |
+
"num_lanes": 3,
|
| 18 |
+
"tags": [
|
| 19 |
+
"ai-native",
|
| 20 |
+
"competitive",
|
| 21 |
+
"generator-critic",
|
| 22 |
+
"tournament",
|
| 23 |
+
"multi-agent",
|
| 24 |
+
"architecture-diagram",
|
| 25 |
+
"orchestration"
|
| 26 |
+
],
|
| 27 |
+
"description": "A tournament-mode architecture where multiple generator agents produce independent outputs in parallel, then an evaluator agent scores and selects the best. Quality threshold checking with refinement loops. Best when correctness or creativity matters more than latency.",
|
| 28 |
+
"source_path": "",
|
| 29 |
+
"repo_path": "agentic/architecture/ai-orchestration-competitive-generator-critic"
|
| 30 |
+
}
|
agentic/architecture/ai-orchestration-competitive-generator-critic/workflow.fz
ADDED
|
@@ -0,0 +1,29 @@
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| 1 |
+
Input { # Input
|
| 2 |
+
n1: circle label="Start"
|
| 3 |
+
n2: rectangle label="Creative brief submitted"
|
| 4 |
+
n1.handle(right) -> n2.handle(left)
|
| 5 |
+
n2.handle(bottom) -> Generators.n3.handle(top) [label="Brief"]
|
| 6 |
+
n2.handle(bottom) -> Generators.n4.handle(top) [label="Brief"]
|
| 7 |
+
n2.handle(bottom) -> Generators.n5.handle(top) [label="Brief"]
|
| 8 |
+
}
|
| 9 |
+
|
| 10 |
+
Generators { # Generator Agents
|
| 11 |
+
n3: rectangle label="Agent A: Draft option 1"
|
| 12 |
+
n4: rectangle label="Agent B: Draft option 2"
|
| 13 |
+
n5: rectangle label="Agent C: Draft option 3"
|
| 14 |
+
n3.handle(bottom) -> Evaluator.n6.handle(top) [label="Option 1"]
|
| 15 |
+
n4.handle(bottom) -> Evaluator.n6.handle(top) [label="Option 2"]
|
| 16 |
+
n5.handle(bottom) -> Evaluator.n6.handle(top) [label="Option 3"]
|
| 17 |
+
}
|
| 18 |
+
|
| 19 |
+
Evaluator { # Evaluator Agent
|
| 20 |
+
n6: rectangle label="Score all options"
|
| 21 |
+
n7: diamond label="Quality threshold met?"
|
| 22 |
+
n8: rectangle label="Select best output"
|
| 23 |
+
n9: circle label="Done"
|
| 24 |
+
n6.handle(right) -> n7.handle(left)
|
| 25 |
+
n7.handle(right) -> n8.handle(left) [label="Yes"]
|
| 26 |
+
n7.handle(top) -> Generators.n3.handle(bottom) [label="No - Refine"]
|
| 27 |
+
n8.handle(right) -> n9.handle(left)
|
| 28 |
+
loop [refine until quality threshold met] n3 n4 n5 n6 n7
|
| 29 |
+
}
|
agentic/architecture/ai-orchestration-hierarchical/README.md
ADDED
|
@@ -0,0 +1,19 @@
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| 1 |
+
# AI Orchestration - Hierarchical (Org Chart)
|
| 2 |
+
|
| 3 |
+
An org-chart architecture with multi-level structure. A top-level supervisor manages team leads, who each manage their own pool of specialist workers. Teams within teams. Best for enterprise-scale automation with 10+ specialized agents spanning multiple domains.
|
| 4 |
+
|
| 5 |
+
**Template ID:** `ai-orchestration-hierarchical`
|
| 6 |
+
**Kind:** architecture
|
| 7 |
+
**Source domain:** Architecture
|
| 8 |
+
**Primary use case:** agentic
|
| 9 |
+
**Secondary use cases:** ai-orchestration
|
| 10 |
+
**Complexity:** 4/5
|
| 11 |
+
**Nodes:** 17
|
| 12 |
+
**Lanes:** 5
|
| 13 |
+
**Tags:** [ai-native, hierarchical, org-chart, enterprise, multi-agent, architecture-diagram, orchestration]
|
| 14 |
+
**Source path:** ``
|
| 15 |
+
**Repo path:** `agentic/architecture/ai-orchestration-hierarchical`
|
| 16 |
+
|
| 17 |
+
## Files
|
| 18 |
+
- `workflow.fz` — FlowZap Code source
|
| 19 |
+
- `metadata.json` — Structured metadata
|
agentic/architecture/ai-orchestration-hierarchical/metadata.json
ADDED
|
@@ -0,0 +1,30 @@
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| 1 |
+
{
|
| 2 |
+
"template_id": "ai-orchestration-hierarchical",
|
| 3 |
+
"workflow_id": "ai-orchestration-hierarchical",
|
| 4 |
+
"title": "AI Orchestration - Hierarchical (Org Chart)",
|
| 5 |
+
"kind": "architecture",
|
| 6 |
+
"source_domain": "Architecture",
|
| 7 |
+
"primary_use_case": "agentic",
|
| 8 |
+
"secondary_use_cases": [
|
| 9 |
+
"ai-orchestration"
|
| 10 |
+
],
|
| 11 |
+
"use_cases": [
|
| 12 |
+
"agentic",
|
| 13 |
+
"ai-orchestration"
|
| 14 |
+
],
|
| 15 |
+
"complexity": 4,
|
| 16 |
+
"num_nodes": 17,
|
| 17 |
+
"num_lanes": 5,
|
| 18 |
+
"tags": [
|
| 19 |
+
"ai-native",
|
| 20 |
+
"hierarchical",
|
| 21 |
+
"org-chart",
|
| 22 |
+
"enterprise",
|
| 23 |
+
"multi-agent",
|
| 24 |
+
"architecture-diagram",
|
| 25 |
+
"orchestration"
|
| 26 |
+
],
|
| 27 |
+
"description": "An org-chart architecture with multi-level structure. A top-level supervisor manages team leads, who each manage their own pool of specialist workers. Teams within teams. Best for enterprise-scale automation with 10+ specialized agents spanning multiple domains.",
|
| 28 |
+
"source_path": "",
|
| 29 |
+
"repo_path": "agentic/architecture/ai-orchestration-hierarchical"
|
| 30 |
+
}
|
agentic/architecture/ai-orchestration-hierarchical/workflow.fz
ADDED
|
@@ -0,0 +1,49 @@
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| 1 |
+
User { # User
|
| 2 |
+
n1: circle label="Start"
|
| 3 |
+
n2: rectangle label="Submit enterprise request"
|
| 4 |
+
n1.handle(right) -> n2.handle(left)
|
| 5 |
+
n2.handle(bottom) -> Supervisor.n3.handle(top) [label="Goal"]
|
| 6 |
+
}
|
| 7 |
+
|
| 8 |
+
Supervisor { # Top-Level Supervisor
|
| 9 |
+
n3: rectangle label="Decompose goal"
|
| 10 |
+
n4: rectangle label="Delegate to team leads"
|
| 11 |
+
n5: rectangle label="Aggregate final output"
|
| 12 |
+
n6: circle label="Done"
|
| 13 |
+
n3.handle(right) -> n4.handle(left)
|
| 14 |
+
n4.handle(bottom) -> LeadA.n7.handle(top) [label="Sub-goal A"]
|
| 15 |
+
n4.handle(bottom) -> LeadB.n10.handle(top) [label="Sub-goal B"]
|
| 16 |
+
n5.handle(right) -> n6.handle(left)
|
| 17 |
+
n5.handle(top) -> User.n2.handle(bottom) [label="Final report"]
|
| 18 |
+
}
|
| 19 |
+
|
| 20 |
+
LeadA { # Team Lead A
|
| 21 |
+
n7: rectangle label="Plan subtasks for A"
|
| 22 |
+
n8: rectangle label="Dispatch to workers"
|
| 23 |
+
n9: rectangle label="Consolidate A results"
|
| 24 |
+
n7.handle(right) -> n8.handle(left)
|
| 25 |
+
n8.handle(bottom) -> Workers.n13.handle(top) [label="Task A1"]
|
| 26 |
+
n8.handle(bottom) -> Workers.n14.handle(top) [label="Task A2"]
|
| 27 |
+
n9.handle(top) -> Supervisor.n5.handle(bottom) [label="Result A"]
|
| 28 |
+
}
|
| 29 |
+
|
| 30 |
+
LeadB { # Team Lead B
|
| 31 |
+
n10: rectangle label="Plan subtasks for B"
|
| 32 |
+
n11: rectangle label="Dispatch to workers"
|
| 33 |
+
n12: rectangle label="Consolidate B results"
|
| 34 |
+
n10.handle(right) -> n11.handle(left)
|
| 35 |
+
n11.handle(bottom) -> Workers.n15.handle(top) [label="Task B1"]
|
| 36 |
+
n11.handle(bottom) -> Workers.n16.handle(top) [label="Task B2"]
|
| 37 |
+
n12.handle(top) -> Supervisor.n5.handle(bottom) [label="Result B"]
|
| 38 |
+
}
|
| 39 |
+
|
| 40 |
+
Workers { # Worker Agents
|
| 41 |
+
n13: rectangle label="Worker A1 executes"
|
| 42 |
+
n14: rectangle label="Worker A2 executes"
|
| 43 |
+
n15: rectangle label="Worker B1 executes"
|
| 44 |
+
n16: rectangle label="Worker B2 executes"
|
| 45 |
+
n13.handle(top) -> LeadA.n9.handle(bottom) [label="A1 done"]
|
| 46 |
+
n14.handle(top) -> LeadA.n9.handle(bottom) [label="A2 done"]
|
| 47 |
+
n15.handle(top) -> LeadB.n12.handle(bottom) [label="B1 done"]
|
| 48 |
+
n16.handle(top) -> LeadB.n12.handle(bottom) [label="B2 done"]
|
| 49 |
+
}
|
agentic/architecture/ai-orchestration-orchestrator-worker/README.md
ADDED
|
@@ -0,0 +1,19 @@
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| 1 |
+
# AI Orchestration - Orchestrator-Worker
|
| 2 |
+
|
| 3 |
+
A conductor-style architecture where one orchestrator agent receives a complex task, breaks it into subtasks, dispatches each to specialist worker agents (research, code, review), collects results, and synthesizes the final answer. Best for complex multi-step tasks with dynamic decomposition.
|
| 4 |
+
|
| 5 |
+
**Template ID:** `ai-orchestration-orchestrator-worker`
|
| 6 |
+
**Kind:** architecture
|
| 7 |
+
**Source domain:** Architecture
|
| 8 |
+
**Primary use case:** agentic
|
| 9 |
+
**Secondary use cases:** ai-orchestration
|
| 10 |
+
**Complexity:** 3/5
|
| 11 |
+
**Nodes:** 15
|
| 12 |
+
**Lanes:** 5
|
| 13 |
+
**Tags:** [ai-native, orchestrator-worker, conductor, multi-agent, architecture-diagram, orchestration]
|
| 14 |
+
**Source path:** ``
|
| 15 |
+
**Repo path:** `agentic/architecture/ai-orchestration-orchestrator-worker`
|
| 16 |
+
|
| 17 |
+
## Files
|
| 18 |
+
- `workflow.fz` — FlowZap Code source
|
| 19 |
+
- `metadata.json` — Structured metadata
|
agentic/architecture/ai-orchestration-orchestrator-worker/metadata.json
ADDED
|
@@ -0,0 +1,29 @@
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| 1 |
+
{
|
| 2 |
+
"template_id": "ai-orchestration-orchestrator-worker",
|
| 3 |
+
"workflow_id": "ai-orchestration-orchestrator-worker",
|
| 4 |
+
"title": "AI Orchestration - Orchestrator-Worker",
|
| 5 |
+
"kind": "architecture",
|
| 6 |
+
"source_domain": "Architecture",
|
| 7 |
+
"primary_use_case": "agentic",
|
| 8 |
+
"secondary_use_cases": [
|
| 9 |
+
"ai-orchestration"
|
| 10 |
+
],
|
| 11 |
+
"use_cases": [
|
| 12 |
+
"agentic",
|
| 13 |
+
"ai-orchestration"
|
| 14 |
+
],
|
| 15 |
+
"complexity": 3,
|
| 16 |
+
"num_nodes": 15,
|
| 17 |
+
"num_lanes": 5,
|
| 18 |
+
"tags": [
|
| 19 |
+
"ai-native",
|
| 20 |
+
"orchestrator-worker",
|
| 21 |
+
"conductor",
|
| 22 |
+
"multi-agent",
|
| 23 |
+
"architecture-diagram",
|
| 24 |
+
"orchestration"
|
| 25 |
+
],
|
| 26 |
+
"description": "A conductor-style architecture where one orchestrator agent receives a complex task, breaks it into subtasks, dispatches each to specialist worker agents (research, code, review), collects results, and synthesizes the final answer. Best for complex multi-step tasks with dynamic decomposition.",
|
| 27 |
+
"source_path": "",
|
| 28 |
+
"repo_path": "agentic/architecture/ai-orchestration-orchestrator-worker"
|
| 29 |
+
}
|
agentic/architecture/ai-orchestration-orchestrator-worker/workflow.fz
ADDED
|
@@ -0,0 +1,44 @@
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| 1 |
+
User { # User
|
| 2 |
+
n1: circle label="Start"
|
| 3 |
+
n2: rectangle label="Submit complex task"
|
| 4 |
+
n1.handle(right) -> n2.handle(left)
|
| 5 |
+
n2.handle(bottom) -> Orchestrator.n3.handle(top) [label="Task"]
|
| 6 |
+
}
|
| 7 |
+
|
| 8 |
+
Orchestrator { # Orchestrator Agent
|
| 9 |
+
n3: rectangle label="Receive task"
|
| 10 |
+
n4: rectangle label="Break into subtasks"
|
| 11 |
+
n5: rectangle label="Dispatch subtasks"
|
| 12 |
+
n6: rectangle label="Collect results"
|
| 13 |
+
n7: rectangle label="Synthesize final answer"
|
| 14 |
+
n8: circle label="Done"
|
| 15 |
+
n3.handle(right) -> n4.handle(left)
|
| 16 |
+
n4.handle(right) -> n5.handle(left)
|
| 17 |
+
n5.handle(bottom) -> Research.n9.handle(top) [label="Research subtask"]
|
| 18 |
+
n5.handle(bottom) -> Code.n11.handle(top) [label="Code subtask"]
|
| 19 |
+
n5.handle(bottom) -> Review.n13.handle(top) [label="Review subtask"]
|
| 20 |
+
n6.handle(right) -> n7.handle(left)
|
| 21 |
+
n7.handle(right) -> n8.handle(left)
|
| 22 |
+
n7.handle(top) -> User.n2.handle(bottom) [label="Response"]
|
| 23 |
+
}
|
| 24 |
+
|
| 25 |
+
Research { # Research Agent
|
| 26 |
+
n9: rectangle label="Search sources"
|
| 27 |
+
n10: rectangle label="Summarize findings"
|
| 28 |
+
n9.handle(right) -> n10.handle(left)
|
| 29 |
+
n10.handle(top) -> Orchestrator.n6.handle(bottom) [label="Research result"]
|
| 30 |
+
}
|
| 31 |
+
|
| 32 |
+
Code { # Code Agent
|
| 33 |
+
n11: rectangle label="Generate code"
|
| 34 |
+
n12: rectangle label="Run tests"
|
| 35 |
+
n11.handle(right) -> n12.handle(left)
|
| 36 |
+
n12.handle(top) -> Orchestrator.n6.handle(bottom) [label="Code result"]
|
| 37 |
+
}
|
| 38 |
+
|
| 39 |
+
Review { # Review Agent
|
| 40 |
+
n13: rectangle label="Evaluate quality"
|
| 41 |
+
n14: rectangle label="Flag issues"
|
| 42 |
+
n13.handle(right) -> n14.handle(left)
|
| 43 |
+
n14.handle(top) -> Orchestrator.n6.handle(bottom) [label="Review result"]
|
| 44 |
+
}
|
agentic/architecture/ai-orchestration-parallel-fan-out/README.md
ADDED
|
@@ -0,0 +1,19 @@
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| 1 |
+
# AI Orchestration - Parallel Fan-Out (Map-Reduce)
|
| 2 |
+
|
| 3 |
+
A map-reduce style architecture where a coordinator fans out tasks to multiple parallel worker agents (style check, security audit, performance analysis), gathers all results, and makes an aggregate decision. Best for PR reviews, code reviews, and multi-dimensional analysis.
|
| 4 |
+
|
| 5 |
+
**Template ID:** `ai-orchestration-parallel-fan-out`
|
| 6 |
+
**Kind:** architecture
|
| 7 |
+
**Source domain:** Architecture
|
| 8 |
+
**Primary use case:** agentic
|
| 9 |
+
**Secondary use cases:** ai-orchestration
|
| 10 |
+
**Complexity:** 3/5
|
| 11 |
+
**Nodes:** 9
|
| 12 |
+
**Lanes:** 3
|
| 13 |
+
**Tags:** [ai-native, parallel-fan-out, map-reduce, coordinator, multi-agent, architecture-diagram, orchestration]
|
| 14 |
+
**Source path:** ``
|
| 15 |
+
**Repo path:** `agentic/architecture/ai-orchestration-parallel-fan-out`
|
| 16 |
+
|
| 17 |
+
## Files
|
| 18 |
+
- `workflow.fz` — FlowZap Code source
|
| 19 |
+
- `metadata.json` — Structured metadata
|
agentic/architecture/ai-orchestration-parallel-fan-out/metadata.json
ADDED
|
@@ -0,0 +1,30 @@
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| 1 |
+
{
|
| 2 |
+
"template_id": "ai-orchestration-parallel-fan-out",
|
| 3 |
+
"workflow_id": "ai-orchestration-parallel-fan-out",
|
| 4 |
+
"title": "AI Orchestration - Parallel Fan-Out (Map-Reduce)",
|
| 5 |
+
"kind": "architecture",
|
| 6 |
+
"source_domain": "Architecture",
|
| 7 |
+
"primary_use_case": "agentic",
|
| 8 |
+
"secondary_use_cases": [
|
| 9 |
+
"ai-orchestration"
|
| 10 |
+
],
|
| 11 |
+
"use_cases": [
|
| 12 |
+
"agentic",
|
| 13 |
+
"ai-orchestration"
|
| 14 |
+
],
|
| 15 |
+
"complexity": 3,
|
| 16 |
+
"num_nodes": 9,
|
| 17 |
+
"num_lanes": 3,
|
| 18 |
+
"tags": [
|
| 19 |
+
"ai-native",
|
| 20 |
+
"parallel-fan-out",
|
| 21 |
+
"map-reduce",
|
| 22 |
+
"coordinator",
|
| 23 |
+
"multi-agent",
|
| 24 |
+
"architecture-diagram",
|
| 25 |
+
"orchestration"
|
| 26 |
+
],
|
| 27 |
+
"description": "A map-reduce style architecture where a coordinator fans out tasks to multiple parallel worker agents (style check, security audit, performance analysis), gathers all results, and makes an aggregate decision. Best for PR reviews, code reviews, and multi-dimensional analysis.",
|
| 28 |
+
"source_path": "",
|
| 29 |
+
"repo_path": "agentic/architecture/ai-orchestration-parallel-fan-out"
|
| 30 |
+
}
|
agentic/architecture/ai-orchestration-parallel-fan-out/workflow.fz
ADDED
|
@@ -0,0 +1,31 @@
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| 1 |
+
Trigger { # Trigger
|
| 2 |
+
n1: circle label="Start"
|
| 3 |
+
n2: rectangle label="PR submitted for review"
|
| 4 |
+
n1.handle(right) -> n2.handle(left)
|
| 5 |
+
n2.handle(bottom) -> Coordinator.n3.handle(top) [label="PR payload"]
|
| 6 |
+
}
|
| 7 |
+
|
| 8 |
+
Coordinator { # Coordinator Agent
|
| 9 |
+
n3: rectangle label="Fan out to reviewers"
|
| 10 |
+
n4: rectangle label="Gather all reviews"
|
| 11 |
+
n5: diamond label="All passed?"
|
| 12 |
+
n6: rectangle label="Approve PR"
|
| 13 |
+
n7: rectangle label="Request changes"
|
| 14 |
+
n8: circle label="Done"
|
| 15 |
+
n3.handle(bottom) -> Reviewers.n9.handle(top) [label="Style check"]
|
| 16 |
+
n3.handle(bottom) -> Reviewers.n10.handle(top) [label="Security audit"]
|
| 17 |
+
n3.handle(bottom) -> Reviewers.n11.handle(top) [label="Perf analysis"]
|
| 18 |
+
n4.handle(right) -> n5.handle(left)
|
| 19 |
+
n5.handle(right) -> n6.handle(left) [label="Yes"]
|
| 20 |
+
n5.handle(bottom) -> n7.handle(top) [label="No"]
|
| 21 |
+
n6.handle(right) -> n8.handle(left)
|
| 22 |
+
}
|
| 23 |
+
|
| 24 |
+
Reviewers { # Parallel Review Agents
|
| 25 |
+
n9: rectangle label="Style Agent"
|
| 26 |
+
n10: rectangle label="Security Agent"
|
| 27 |
+
n11: rectangle label="Performance Agent"
|
| 28 |
+
n9.handle(top) -> Coordinator.n4.handle(bottom) [label="Style report"]
|
| 29 |
+
n10.handle(top) -> Coordinator.n4.handle(bottom) [label="Security report"]
|
| 30 |
+
n11.handle(top) -> Coordinator.n4.handle(bottom) [label="Perf report"]
|
| 31 |
+
}
|
agentic/architecture/context-shared-memory/README.md
ADDED
|
@@ -0,0 +1,19 @@
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| 1 |
+
# Context Management - Shared Memory
|
| 2 |
+
|
| 3 |
+
Multi-agent coordination pattern where an orchestrator breaks work into subtasks, specialist agents pull from and push to a shared state store, and the orchestrator composes the final answer from that shared state. Multi-agent setups feel coherent instead of each assistant having its own inconsistent memory.
|
| 4 |
+
|
| 5 |
+
**Template ID:** `context-shared-memory`
|
| 6 |
+
**Kind:** architecture
|
| 7 |
+
**Source domain:** Architecture
|
| 8 |
+
**Primary use case:** agentic
|
| 9 |
+
**Secondary use cases:** context-management
|
| 10 |
+
**Complexity:** 3/5
|
| 11 |
+
**Nodes:** 9
|
| 12 |
+
**Lanes:** 4
|
| 13 |
+
**Tags:** [context-management, shared-memory, multi-agent, orchestrator, architecture-diagram]
|
| 14 |
+
**Source path:** ``
|
| 15 |
+
**Repo path:** `agentic/architecture/context-shared-memory`
|
| 16 |
+
|
| 17 |
+
## Files
|
| 18 |
+
- `workflow.fz` — FlowZap Code source
|
| 19 |
+
- `metadata.json` — Structured metadata
|
agentic/architecture/context-shared-memory/metadata.json
ADDED
|
@@ -0,0 +1,28 @@
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| 1 |
+
{
|
| 2 |
+
"template_id": "context-shared-memory",
|
| 3 |
+
"workflow_id": "context-shared-memory",
|
| 4 |
+
"title": "Context Management - Shared Memory",
|
| 5 |
+
"kind": "architecture",
|
| 6 |
+
"source_domain": "Architecture",
|
| 7 |
+
"primary_use_case": "agentic",
|
| 8 |
+
"secondary_use_cases": [
|
| 9 |
+
"context-management"
|
| 10 |
+
],
|
| 11 |
+
"use_cases": [
|
| 12 |
+
"agentic",
|
| 13 |
+
"context-management"
|
| 14 |
+
],
|
| 15 |
+
"complexity": 3,
|
| 16 |
+
"num_nodes": 9,
|
| 17 |
+
"num_lanes": 4,
|
| 18 |
+
"tags": [
|
| 19 |
+
"context-management",
|
| 20 |
+
"shared-memory",
|
| 21 |
+
"multi-agent",
|
| 22 |
+
"orchestrator",
|
| 23 |
+
"architecture-diagram"
|
| 24 |
+
],
|
| 25 |
+
"description": "Multi-agent coordination pattern where an orchestrator breaks work into subtasks, specialist agents pull from and push to a shared state store, and the orchestrator composes the final answer from that shared state. Multi-agent setups feel coherent instead of each assistant having its own inconsistent memory.",
|
| 26 |
+
"source_path": "",
|
| 27 |
+
"repo_path": "agentic/architecture/context-shared-memory"
|
| 28 |
+
}
|
agentic/architecture/context-shared-memory/workflow.fz
ADDED
|
@@ -0,0 +1,46 @@
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| 1 |
+
Orchestrator {
|
| 2 |
+
n1: circle label="Complex task arrives"
|
| 3 |
+
n2: rectangle label="Request shared context"
|
| 4 |
+
n3: rectangle label="Create research subtask"
|
| 5 |
+
n4: rectangle label="Create action subtask"
|
| 6 |
+
n5: rectangle label="Receive findings and results"
|
| 7 |
+
n6: rectangle label="Compile final answer"
|
| 8 |
+
n1.handle(right) -> n2.handle(left)
|
| 9 |
+
n2.handle(bottom) -> SharedMemory.n7.handle(top) [label="Read state"]
|
| 10 |
+
n3.handle(right) -> n4.handle(left)
|
| 11 |
+
n3.handle(bottom) -> Researcher.n9.handle(top) [label="Research task"]
|
| 12 |
+
n4.handle(bottom) -> Operator.n13.handle(top) [label="Action task"]
|
| 13 |
+
n5.handle(right) -> n6.handle(left)
|
| 14 |
+
Researcher.n12.handle(top) -> n5.handle(left) [label="Finding"]
|
| 15 |
+
Operator.n17.handle(top) -> n5.handle(right) [label="Result"]
|
| 16 |
+
}
|
| 17 |
+
|
| 18 |
+
Researcher {
|
| 19 |
+
n9: rectangle label="Receive research task"
|
| 20 |
+
n10: rectangle label="Read shared memory"
|
| 21 |
+
n11: rectangle label="Analyze with context"
|
| 22 |
+
n12: rectangle label="Return finding"
|
| 23 |
+
n9.handle(right) -> n10.handle(left)
|
| 24 |
+
n10.handle(right) -> n11.handle(left)
|
| 25 |
+
n11.handle(right) -> n12.handle(left)
|
| 26 |
+
n10.handle(bottom) -> SharedMemory.n7.handle(left) [label="Read state"]
|
| 27 |
+
}
|
| 28 |
+
|
| 29 |
+
Operator {
|
| 30 |
+
n13: rectangle label="Receive action task"
|
| 31 |
+
n14: rectangle label="Read shared memory"
|
| 32 |
+
n15: rectangle label="Execute with context"
|
| 33 |
+
n16: rectangle label="Write result to memory"
|
| 34 |
+
n17: rectangle label="Return result"
|
| 35 |
+
n13.handle(right) -> n14.handle(left)
|
| 36 |
+
n14.handle(right) -> n15.handle(left)
|
| 37 |
+
n15.handle(right) -> n16.handle(left)
|
| 38 |
+
n16.handle(bottom) -> SharedMemory.n8.handle(left) [label="Write state"]
|
| 39 |
+
n15.handle(bottom) -> n17.handle(top)
|
| 40 |
+
}
|
| 41 |
+
|
| 42 |
+
SharedMemory {
|
| 43 |
+
n7: rectangle label="Resolve memory request"
|
| 44 |
+
n8: rectangle label="Update shared state"
|
| 45 |
+
n7.handle(right) -> n8.handle(left)
|
| 46 |
+
}
|
agentic/devops/mcp-agent-mesh/README.md
ADDED
|
@@ -0,0 +1,19 @@
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| 1 |
+
# MCP Agent Mesh Architecture
|
| 2 |
+
|
| 3 |
+
A multi-agent mesh pattern where agents communicate through a shared context broker backed by MCP. Enables coordinated tool access and state synchronization across multiple specialized agents (planner, coder, reviewer, operator). Supports both orchestrated and choreographed interaction patterns.
|
| 4 |
+
|
| 5 |
+
**Template ID:** `mcp-agent-mesh`
|
| 6 |
+
**Kind:** architecture
|
| 7 |
+
**Source domain:** DevOps
|
| 8 |
+
**Primary use case:** agentic
|
| 9 |
+
**Secondary use cases:** mcp
|
| 10 |
+
**Complexity:** 4/5
|
| 11 |
+
**Nodes:** 10
|
| 12 |
+
**Lanes:** 4
|
| 13 |
+
**Tags:** [mcp, agent-mesh, shared-context, multi-agent, broker, architecture-diagram, production-grade]
|
| 14 |
+
**Source path:** ``
|
| 15 |
+
**Repo path:** `agentic/devops/mcp-agent-mesh`
|
| 16 |
+
|
| 17 |
+
## Files
|
| 18 |
+
- `workflow.fz` — FlowZap Code source
|
| 19 |
+
- `metadata.json` — Structured metadata
|
agentic/devops/mcp-agent-mesh/metadata.json
ADDED
|
@@ -0,0 +1,30 @@
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| 1 |
+
{
|
| 2 |
+
"template_id": "mcp-agent-mesh",
|
| 3 |
+
"workflow_id": "mcp-agent-mesh",
|
| 4 |
+
"title": "MCP Agent Mesh Architecture",
|
| 5 |
+
"kind": "architecture",
|
| 6 |
+
"source_domain": "DevOps",
|
| 7 |
+
"primary_use_case": "agentic",
|
| 8 |
+
"secondary_use_cases": [
|
| 9 |
+
"mcp"
|
| 10 |
+
],
|
| 11 |
+
"use_cases": [
|
| 12 |
+
"agentic",
|
| 13 |
+
"mcp"
|
| 14 |
+
],
|
| 15 |
+
"complexity": 4,
|
| 16 |
+
"num_nodes": 10,
|
| 17 |
+
"num_lanes": 4,
|
| 18 |
+
"tags": [
|
| 19 |
+
"mcp",
|
| 20 |
+
"agent-mesh",
|
| 21 |
+
"shared-context",
|
| 22 |
+
"multi-agent",
|
| 23 |
+
"broker",
|
| 24 |
+
"architecture-diagram",
|
| 25 |
+
"production-grade"
|
| 26 |
+
],
|
| 27 |
+
"description": "A multi-agent mesh pattern where agents communicate through a shared context broker backed by MCP. Enables coordinated tool access and state synchronization across multiple specialized agents (planner, coder, reviewer, operator). Supports both orchestrated and choreographed interaction patterns.",
|
| 28 |
+
"source_path": "",
|
| 29 |
+
"repo_path": "agentic/devops/mcp-agent-mesh"
|
| 30 |
+
}
|
agentic/devops/mcp-agent-mesh/workflow.fz
ADDED
|
@@ -0,0 +1,41 @@
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| 1 |
+
Orchestrator { # Orchestrator Agent
|
| 2 |
+
n1: circle label="Complex task received"
|
| 3 |
+
n2: rectangle label="Decompose into subtasks"
|
| 4 |
+
n3: rectangle label="Assign subtask to Agent B"
|
| 5 |
+
n4: rectangle label="Receive subtask result"
|
| 6 |
+
n5: rectangle label="Request shared context"
|
| 7 |
+
n6: rectangle label="Compile final response"
|
| 8 |
+
n1.handle(right) -> n2.handle(left)
|
| 9 |
+
n2.handle(right) -> n3.handle(left)
|
| 10 |
+
n3.handle(bottom) -> Worker.n7.handle(top) [label="Subtask assignment"]
|
| 11 |
+
n4.handle(right) -> n5.handle(left)
|
| 12 |
+
n5.handle(bottom) -> Broker.n11.handle(top) [label="Context request"]
|
| 13 |
+
n6.handle(left) -> n2.handle(bottom) [label="Next iteration"]
|
| 14 |
+
}
|
| 15 |
+
|
| 16 |
+
Worker { # Worker Agent
|
| 17 |
+
n7: rectangle label="Receive subtask"
|
| 18 |
+
n8: rectangle label="Fetch shared context"
|
| 19 |
+
n9: rectangle label="Call MCP tool"
|
| 20 |
+
n10: rectangle label="Return result to orchestrator"
|
| 21 |
+
n7.handle(right) -> n8.handle(left)
|
| 22 |
+
n8.handle(bottom) -> Broker.n11.handle(left) [label="Context request"]
|
| 23 |
+
n8.handle(right) -> n9.handle(left)
|
| 24 |
+
n9.handle(bottom) -> MCPServer.n13.handle(top) [label="MCP tool call"]
|
| 25 |
+
n10.handle(top) -> Orchestrator.n4.handle(bottom) [label="Subtask result"]
|
| 26 |
+
}
|
| 27 |
+
|
| 28 |
+
Broker { # Shared Context Broker
|
| 29 |
+
n11: rectangle label="Resolve context request"
|
| 30 |
+
n12: rectangle label="Return shared state"
|
| 31 |
+
n11.handle(right) -> n12.handle(left)
|
| 32 |
+
n12.handle(top) -> Orchestrator.n6.handle(bottom) [label="Context to orchestrator"]
|
| 33 |
+
n12.handle(left) -> Worker.n9.handle(top) [label="Context to worker"]
|
| 34 |
+
}
|
| 35 |
+
|
| 36 |
+
MCPServer { # MCP Server
|
| 37 |
+
n13: rectangle label="Execute tool"
|
| 38 |
+
n14: rectangle label="Return tool output"
|
| 39 |
+
n13.handle(right) -> n14.handle(left)
|
| 40 |
+
n14.handle(top) -> Worker.n10.handle(bottom) [label="Tool output"]
|
| 41 |
+
}
|
ai-orchestration/architecture/ai-orchestration-event-driven-mesh/README.md
ADDED
|
@@ -0,0 +1,19 @@
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| 1 |
+
# AI Orchestration - Event-Driven Mesh (Kafka-First)
|
| 2 |
+
|
| 3 |
+
An event-driven agent mesh architecture using a Kafka-style event broker. Multiple agents subscribe to topics (orders, alerts, analytics), process events independently, and publish results back to the bus. Best for real-time event processing and decoupled service architectures.
|
| 4 |
+
|
| 5 |
+
**Template ID:** `ai-orchestration-event-driven-mesh`
|
| 6 |
+
**Kind:** architecture
|
| 7 |
+
**Source domain:** Architecture
|
| 8 |
+
**Primary use case:** ai-orchestration
|
| 9 |
+
**Secondary use cases:** mcp
|
| 10 |
+
**Complexity:** 3/5
|
| 11 |
+
**Nodes:** 13
|
| 12 |
+
**Lanes:** 5
|
| 13 |
+
**Tags:** [ai-native, event-driven, kafka, agent-mesh, pub-sub, architecture-diagram, orchestration]
|
| 14 |
+
**Source path:** ``
|
| 15 |
+
**Repo path:** `ai-orchestration/architecture/ai-orchestration-event-driven-mesh`
|
| 16 |
+
|
| 17 |
+
## Files
|
| 18 |
+
- `workflow.fz` — FlowZap Code source
|
| 19 |
+
- `metadata.json` — Structured metadata
|
ai-orchestration/architecture/ai-orchestration-event-driven-mesh/metadata.json
ADDED
|
@@ -0,0 +1,30 @@
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| 1 |
+
{
|
| 2 |
+
"template_id": "ai-orchestration-event-driven-mesh",
|
| 3 |
+
"workflow_id": "ai-orchestration-event-driven-mesh",
|
| 4 |
+
"title": "AI Orchestration - Event-Driven Mesh (Kafka-First)",
|
| 5 |
+
"kind": "architecture",
|
| 6 |
+
"source_domain": "Architecture",
|
| 7 |
+
"primary_use_case": "ai-orchestration",
|
| 8 |
+
"secondary_use_cases": [
|
| 9 |
+
"mcp"
|
| 10 |
+
],
|
| 11 |
+
"use_cases": [
|
| 12 |
+
"ai-orchestration",
|
| 13 |
+
"mcp"
|
| 14 |
+
],
|
| 15 |
+
"complexity": 3,
|
| 16 |
+
"num_nodes": 13,
|
| 17 |
+
"num_lanes": 5,
|
| 18 |
+
"tags": [
|
| 19 |
+
"ai-native",
|
| 20 |
+
"event-driven",
|
| 21 |
+
"kafka",
|
| 22 |
+
"agent-mesh",
|
| 23 |
+
"pub-sub",
|
| 24 |
+
"architecture-diagram",
|
| 25 |
+
"orchestration"
|
| 26 |
+
],
|
| 27 |
+
"description": "An event-driven agent mesh architecture using a Kafka-style event broker. Multiple agents subscribe to topics (orders, alerts, analytics), process events independently, and publish results back to the bus. Best for real-time event processing and decoupled service architectures.",
|
| 28 |
+
"source_path": "",
|
| 29 |
+
"repo_path": "ai-orchestration/architecture/ai-orchestration-event-driven-mesh"
|
| 30 |
+
}
|
ai-orchestration/architecture/ai-orchestration-event-driven-mesh/workflow.fz
ADDED
|
@@ -0,0 +1,39 @@
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| 1 |
+
Source { # Event Sources
|
| 2 |
+
n1: circle label="Start"
|
| 3 |
+
n2: rectangle label="User action event"
|
| 4 |
+
n3: rectangle label="System alert event"
|
| 5 |
+
n1.handle(right) -> n2.handle(left)
|
| 6 |
+
n2.handle(bottom) -> Broker.n4.handle(top) [label="Publish event"]
|
| 7 |
+
n3.handle(bottom) -> Broker.n4.handle(top) [label="Publish event"]
|
| 8 |
+
}
|
| 9 |
+
|
| 10 |
+
Broker { # Event Broker (Kafka / Pub-Sub)
|
| 11 |
+
n4: rectangle label="Event bus receives event"
|
| 12 |
+
n5: rectangle label="Route to subscribers"
|
| 13 |
+
n4.handle(right) -> n5.handle(left)
|
| 14 |
+
n5.handle(bottom) -> Orders.n6.handle(top) [label="topic: orders"]
|
| 15 |
+
n5.handle(bottom) -> Alerts.n8.handle(top) [label="topic: alerts"]
|
| 16 |
+
n5.handle(bottom) -> Analytics.n10.handle(top) [label="topic: analytics"]
|
| 17 |
+
}
|
| 18 |
+
|
| 19 |
+
Orders { # Order Processing Agent
|
| 20 |
+
n6: rectangle label="Parse order event"
|
| 21 |
+
n7: rectangle label="Execute fulfillment"
|
| 22 |
+
n6.handle(right) -> n7.handle(left)
|
| 23 |
+
n7.handle(bottom) -> Broker.n4.handle(top) [label="Publish: order.completed"]
|
| 24 |
+
}
|
| 25 |
+
|
| 26 |
+
Alerts { # Alert Triage Agent
|
| 27 |
+
n8: rectangle label="Classify severity"
|
| 28 |
+
n9: rectangle label="Route to on-call or auto-resolve"
|
| 29 |
+
n8.handle(right) -> n9.handle(left)
|
| 30 |
+
n9.handle(bottom) -> Broker.n4.handle(top) [label="Publish: alert.resolved"]
|
| 31 |
+
}
|
| 32 |
+
|
| 33 |
+
Analytics { # Analytics Agent
|
| 34 |
+
n10: rectangle label="Aggregate metrics"
|
| 35 |
+
n11: rectangle label="Update dashboard"
|
| 36 |
+
n12: circle label="Stored"
|
| 37 |
+
n10.handle(right) -> n11.handle(left)
|
| 38 |
+
n11.handle(right) -> n12.handle(left)
|
| 39 |
+
}
|