swrly

This is a great question. We handle it with session state that persists across turns — the agent's memory scope can be set to "agent" (persists across runs) vs "swirl" (one run only). For truly long-running conversations, we store context in agent memories with importance scoring, so the agent can recall relevant context days later without carrying the full history. It's not perfect yet but it works for most production patterns we've seen.

Parallel workers in git worktrees is clever. We have a similar pattern with fan-out/fan-in — you can split an array across parallel agent executions and collect results. The SQLite-structured JSON output approach is interesting for coordination. We use template variables + scratchpad (Redis-backed shared state) for inter-agent data flow. Different trade-offs — yours gives you more control at the cost of more infrastructure.

Interesting — I hadn't looked into AGNO closely. The isolation and control plane approach sounds solid. How do you handle observability? That's been one of the harder parts for us — knowing exactly which agent produced which output when something goes wrong in a multi-step pipeline.

Also curious if you're running agents on triggers (webhooks, cron) or mostly manual execution?

I agree, YouTube search is completely useless when we really need it. Especially with fizzy search!