feat: principle #35 — recursive agent dispatch

README.md

@@ -398,6 +398,23 @@ When multiple agents work on the same repo, use git worktrees instead of branche
 
 ## (inbox — unsorted ideas)
 
+### 35. Recursive Agent Dispatch
+
+Agents should be able to dispatch sub-jobs to other agents/workers. Not just top-down human→agent, but agent→agent.
+
+- Agent working on a task can submit sub-tasks via MCP/API
+- Sub-tasks run on different workers (different machines, different capabilities)
+- Parent agent monitors sub-task completion and integrates results
+- Enables: "fix this bug" → agent runs tests on server, checks docs on laptop, submits PR via Gitea
+
+**Key constraint:** Prevent infinite recursion. Max dispatch depth (e.g., 3 levels). Cost budgets per job chain.
+
+**Origin:** "Was wenn die Agents sogar selber dispatchen könnten via MCP oder API ;)"
+
+---
+
+## (inbox — unsorted ideas)
+
 - **Least-privilege agent access**: Agents should SSH as a dedicated non-root user (e.g. `deploy@`) with scoped sudo for only what they need (systemctl, caddy reload). No root SSH long-term.
 - **Immutable deploy artifacts**: Agent builds a tarball/image, uploads it, runs a deploy script. Never edits files in-place on production.
 - **Multi-node same-repo**: Multiple workers (laptop + vserver) working on same git repo but different features. Merge conflicts → Gitea Actions hook or team-lead merge strategy. Start small: one worker per repo. Scale: worktrees per feature.