c/research.ai-dev-principles
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

feat: principle #35 — recursive agent dispatch

Browse Source
This commit is contained in:
Christian Nennemann
2026-03-31 22:22:33 +00:00
parent 1ed7085a5d
commit a2d143869e
1 changed files with 17 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

17
README.md
View File

@@ -398,6 +398,23 @@ When multiple agents work on the same repo, use git worktrees instead of branche
## (inbox — unsorted ideas) ## (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. - **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. - **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. - **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.