openserv-multi-agent-workflows
Multi-agent workflow examples to work together on the OpenServ Platform. Covers agent discovery, multi-agent workspaces, task dependencies, and workflow orchestration using the Platform Client. Read reference.md for the full API reference. Read openserv-agent-sdk and openserv-client for building and running agents.
git clone --depth 1 https://github.com/internet-court/internet-court-skill /tmp/openserv-multi-agent-workflows && cp -r /tmp/openserv-multi-agent-workflows/vendored/openserv/openserv-multi-agent-workflows ~/.claude/skills/openserv-multi-agent-workflowsSKILL.md
# Multi-Agent Workflows on OpenServ
Build workflows where multiple AI agents collaborate to complete complex tasks.
**Reference files:**
- `reference.md` - Workflow patterns, declarative sync, triggers, monitoring
- `troubleshooting.md` - Common issues and solutions
- `examples/` - Complete pipeline examples (blog, youtube-to-blog, etc.)
---
## Quick Start
See `examples/` for complete runnable examples:
- `blog-pipeline.md` - Simple 2-agent workflow (research → write)
- `content-creation-pipeline.md` - 3-agent workflow (research → write → image)
- `life-coaching-pipeline.md` - Complex 6-agent workflow with comprehensive input schema
**Recommended pattern using `workflows.sync()`:**
1. Authenticate with `client.authenticate()`
2. Find agents with `client.agents.listMarketplace()`
3. Create workflow with `client.workflows.create()` including:
- Triggers
- Tasks
- **Edges** (⚠️ CRITICAL - connects triggers and tasks together)
**⚠️ CRITICAL:** Always define edges when creating workflows. Setting task `dependencies` is NOT enough - you must create workflow edges to actually connect triggers to tasks and tasks to each other.
---
## Workflow Name & Goal
When creating workflows (via `workflows.create()` or `provision()`), two properties are critical:
- **`name`** (string) - This becomes the **agent name in ERC-8004**. Make it polished, punchy, and memorable — this is the public-facing brand name users see. Think product launch, not variable name. Examples: `'Instant Blog Machine'`, `'AI Video Studio'`, `'Polymarket Intelligence'`.
- **`goal`** (string, required) - A detailed description of what the workflow accomplishes. Must be descriptive and thorough — short or vague goals will cause API calls to fail. Write at least a full sentence explaining the end-to-end purpose of the workflow.
---
## Core Concepts
### Workflows
A workflow (workspace) is a container that holds multiple agents and their tasks.
### Task Dependencies
- Each task is assigned to a specific agent
- Tasks can depend on other tasks: `dependencies: [taskId1, taskId2]`
- A task only starts when all dependencies are `done`
- Output from dependencies is passed to dependent tasks
### Workflow Graph
- **Nodes**: Triggers and tasks
- **Edges**: Connections between nodes
- When Task A completes, its output flows to dependent tasks via edges
### Agent Discovery
```typescript
// Search marketplace for agents by name/capability (semantic search)
const result = await client.agents.listMarketplace({ search: 'research' })
const agents = result.items // Array of marketplace agents
// Get agent details
const agent = await client.agents.get({ id: 123 })
console.log(agent.capabilities_description)
// Note: client.agents.searchOwned() only searches YOUR OWN agents
// Use listMarketplace() to find public agents for multi-agent workflows
```
Common agent types: Research (Grok, Perplexity), Content writers, Data analysis, Social media (Nano Banana Pro), Video/audio creators.
---
## Edge Design Best Practices
**CRITICAL: Carefully design your workflow edges to avoid creating tangled "spaghetti" graphs.**
A well-designed workflow has clear, intentional data flow. Common mistakes lead to unmaintainable workflows.
### Bad Pattern - Everything Connected to Everything
```
┌──────────────────────────────────┐
│ ┌─────────┐ │
│ ┌─────┤ Agent A ├─────┐ │
│ │ └────┬────┘ │ │
│ │ │ │ │
Trigger ─┼─────┼──────────┼──────────┼──────┤
│ │ │ │ │
│ │ ┌────┴────┐ │ │
│ └─────┤ Agent B ├─────┘ │
│ └─────────┘ │
└──────────────────────────────────┘
(Spaghetti - avoid this!)
```
This creates:
- Unclear execution order
- Difficult debugging
- Agents receiving redundant/conflicting inputs
- Hard to understand what depends on what
### Good Patterns
**Sequential Pipeline:**
```
Trigger → Research → Content → Enhancement → Output
```
**Staged Fan-Out:**
```
┌─ Task A ─┐
Trigger → Research ─┼─ Task B ─┼─→ Combiner → Output
└─ Task C ─┘
```
**Conditional Branching (v1.1.3+):**
```
┌─[approved]─→ Process
Trigger → Review ──┤
└─[rejected]─→ Reject Handler
```
Use `outputOptions` on tasks and `sourcePort` on edges for branching.
### Guidelines for Clean Workflows
1. **Linear is usually best**: Start with a simple chain, only add complexity when truly needed
2. **Each task should have a clear purpose**: If you can't explain why Task A connects to Task B, remove the edge
3. **Minimize cross-connections**: Avoid connecting every agent to every other agent
4. **Use fan-out only for parallel work**: Multiple tasks from one source is fine; connecting everything to everything is not
5. **One combiner at the end**: If you need to merge outputs, have ONE final task that depends on all parallel branches
### Before Adding an Edge, Ask:
- Does Task B actually need the output of Task A?
- Would Task B work without this connection?
- Am I adding this edge "just in case"? (Don't!)
---
## Updating This Skill
This skill may be outdated. The OpenServ team ships updates regularly—new features, API changes, and bug fixes won't be reflected here until you update. **If something isn't working as expected, or you want to make sure you have the latest information, update the skill before proceeding.**
```bash
# Check if updates are available
npx skills check
# Update all installed skills to latest versions
npx skills update
```
Or reinstall the OpenServ skills directly:
```bash
npx skills add openserv-labs/skills
```
---
## Related Skills
- **openserv-agent-sdk** - Building individual agent capabilities
- **openserv-client** - Full Platform Client API reference
- **openserv-launch** - Launch tokens on Base blockcEntry point for Internet Court — the trust layer for agent-to-agent commerce. Use whenever an agent needs to transact with another agent or a paid service, or a user mentions agent payments, paid APIs (HTTP 402/x402), wallet custody or trust concerns, spending mandates, delegated permissions (ERC-7710/7715), escrow, agent identity or reputation (ERC-8004), negotiation between agents (A2A), agent jobs (ERC-8183), machine payments (MPP, AP2), supervision of agent behavior, revocation, verification, or dispute resolution (GenLayer) — even if they never say "Internet Court". Routes to the vendored protocol skills and connector skills in this package.
Connect GenLayer Intelligent Contract decisions to ERC-7710-style delegated authority. Use when an agent needs to design the interface, message schema, relayer/bridge path, EVM revocation controller, constraint updates, proof/finality assumptions, and failure handling that turn a GenLayer agent-performance review into ERC-7710 revocation or policy changes.
Internet Court adapter for GenLayer Intelligent Contract supervision. Use to specify agent-performance rubrics, evidence schemas, decision outputs, and ERC-7710 connector expectations, while delegating actual GenLayer contract writing, linting, testing, deployment, and CLI interaction to the official GenLayer skills at https://skills.genlayer.com/.
Design and implement demos combining x402 HTTP payments with ERC-7710 smart contract delegations and ERC-7715 wallet permission requests for subscriptions, bounded agent budgets, recurring spend, pay-per-use APIs, and agentic commerce.
0G Compute Network guide for decentralized AI inference, fine-tuning, and GPU services. Covers chatbots, image generation, speech-to-text, SDK integration (0g-serving-broker), processResponse API, broker.inference methods, CLI commands (0g-compute-cli), and account management. Use this skill for any 0G compute, 0G AI, or decentralized GPU question.
Use this skill when the user asks to list, create, inspect, update, disable, re-enable, or revoke AltLLM Portal API keys for external agents or applications. Do NOT use for wallet login, billing history, or payment links.
Use this skill when the user asks to log in or out with a wallet session, fetch a wallet sign-in challenge, verify an externally signed challenge, or troubleshoot AltLLM Portal wallet login for the local altllm CLI. Do NOT use for API key management, billing history, or payment links.
Use this skill when the user asks to inspect AltLLM Portal balance, redeem a promo code, review billing transactions, or view usage analytics by period, model, or API key using the local altllm CLI. Do NOT use for API key lifecycle management or payment-link execution.