Vision: agent-swarm-os — control plane for agent-swarm infrastructure (fresh codebase; TreeGent as reference, not refactor target) #32

New issue

Closed

opened 2026-10-31 13:52:14 +00:00 by heike · 1 comment

heike commented

2026-10-31 13:52:14 +00:00

Member

DECIDED DIRECTION for the project (manager ruling 2026-10-30), filed by heike. The destination is an agent-swarm-os on a fresh codebase; the current codebase remains the running product until a successor reaches parity. Not a refactor of this repo — a successor to it, and this issue is the record of that direction.

A hyper-modular system — kind of an "agent-swarm-os": management / orchestration / whatever you call it. Like Kubernetes, but for agent-swarm infra, setup, management. A much grander idea that would definitely need a fresh codebase.

The concept: a control-plane layer for multi-agent infrastructure — declarative desired-state for swarms of agents, their hosts, model providers, and the external systems they use (storage, mail, VCS, MCP gateways, third-party harnesses); reconcilers that provision/heal/upgrade; policy + approval gates and cost metering as first-class control-plane concerns. TreeGent is the AIO product and stays; this is the generalization, built clean.

Why it connects to our existing ideas: #12 (MCP), #9 (external harnesses), #13 (messaging bridges), #28 (overlay devices) are all instances of the extension surface such an OS would standardize — adapter/operator contracts over anything with an admin API (Nextcloud/Dropbox for storage, any mail provider, any VCS, arbitrary systems).

Known hard parts (the manager's own list, to be answered by the exploration, not assumed away):

Setup complexity — an OS for swarms must be easier to stand up than the sum of its parts, or it loses to the AIO it replaces.
User-friendly adapter authoring.
Security: admin API keys that provision accounts across a user's major systems, centralized = prime attack target. Needs a serious threat model (per-adapter credential isolation, least-privilege provisioning vs usage tokens, audit, break-glass).

Exploration doc: a grounded architecture exploration (core-vs-peripheral split, adapter contract, security architecture, k8s-analogy stress test incl. where the analogy breaks: long-lived stateful conversational agents, LLM nondeterminism, cost as scheduling input, org-structure identity; competitive scan of the agent-orchestration niche; build-or-not recommendation with MVP shape) is being produced and will be attached as a comment when ready.

Status: DECIDED DIRECTION. The open work is what and how — MVP shape, sequencing, what carries over from this codebase, when to start — not whether. The exploration attached below answers those; current-codebase work continues in the meantime.

**DECIDED DIRECTION for the project (manager ruling 2026-10-30), filed by heike. The destination is an agent-swarm-os on a fresh codebase; the current codebase remains the running product until a successor reaches parity. Not a refactor of this repo — a successor to it, and this issue is the record of that direction.** > A hyper-modular system — kind of an "agent-swarm-os": management / orchestration / whatever you call it. Like Kubernetes, but for agent-swarm infra, setup, management. A much grander idea that would definitely need a fresh codebase. **The concept:** a control-plane layer for multi-agent infrastructure — declarative desired-state for swarms of agents, their hosts, model providers, and the external systems they use (storage, mail, VCS, MCP gateways, third-party harnesses); reconcilers that provision/heal/upgrade; policy + approval gates and cost metering as first-class control-plane concerns. TreeGent is the AIO product and stays; this is the generalization, built clean. **Why it connects to our existing ideas:** #12 (MCP), #9 (external harnesses), #13 (messaging bridges), #28 (overlay devices) are all instances of the extension surface such an OS would standardize — adapter/operator contracts over anything with an admin API (Nextcloud/Dropbox for storage, any mail provider, any VCS, arbitrary systems). **Known hard parts (the manager's own list, to be answered by the exploration, not assumed away):** 1. Setup complexity — an OS for swarms must be easier to stand up than the sum of its parts, or it loses to the AIO it replaces. 2. User-friendly adapter authoring. 3. Security: admin API keys that provision accounts across a user's major systems, centralized = prime attack target. Needs a serious threat model (per-adapter credential isolation, least-privilege provisioning vs usage tokens, audit, break-glass). **Exploration doc:** a grounded architecture exploration (core-vs-peripheral split, adapter contract, security architecture, k8s-analogy stress test incl. where the analogy breaks: long-lived stateful conversational agents, LLM nondeterminism, cost as scheduling input, org-structure identity; competitive scan of the agent-orchestration niche; build-or-not recommendation with MVP shape) is being produced and will be attached as a comment when ready. **Status: DECIDED DIRECTION.** The open work is *what and how* — MVP shape, sequencing, what carries over from this codebase, when to start — not *whether*. The exploration attached below answers those; current-codebase work continues in the meantime.

heike commented

2026-10-31 13:55:59 +00:00

Author

Member

Closing — the manager did not want this filed under TreeGent; filed in error. The idea lives outside this repo.

heike closed this issue

2026-10-31 13:55:59 +00:00

No labels

No milestone

No project

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference: NSTERN/TreeGent#32

No description provided.

Rows
Columns