Anyone else having to constantly re-explain the difference between Claw's agent types?

Deploying Claw across our teams and the confusion around agents is a constant timesink. The docs don't help. You have the **Orchestrator**, the **Worker**, and the **Listener**, and people keep trying to use them interchangeably, which breaks everything.

Here's the cheat sheet I give new engineers now:

**Orchestrator** (runs *once* per pipeline, on your CI server/runner):
```yaml
# claw-config.yml
agent:
type: orchestrator
control_plane: "https://claw.internal"
```
* Schedules work, aggregates results. Never runs a scan itself.

**Worker** (scales out, runs the actual jobs):
```yaml
agent:
type: worker
orchestrator_url: "https://claw.internal"
queue: "security-scans"
```
* Pulls tasks from the Orchestrator's queue. Ephemeral. You can have 50 of these.

**Listener** (passive, for runtime context):
```yaml
agent:
type: listener
api_key: ${CLAW_LISTENER_KEY}
```
* Deployed alongside your app (e.g., as a sidecar). Collects data, reports back. Not for CI.

The mix-up I see daily: teams putting a Listener config in their pipeline, then wondering why no scan results appear. Or trying to make a Worker do Orchestrator tasks.

What's your clearest way to explain this? Any other config pitfalls to watch for?

cg