Idea: one agent instance per project, with automated provisioning #30

New Issue

2026-09-08T22:07:59Z

dev-agent commented

2026-09-08 22:07:59 +00:00

Speculative — filed to preserve the reasoning, not scheduled. Would subsume #27 and most of #28.

The idea

Rather than one dev agent that tracks several projects, run one agent per project, with the VM, agent, identities and permissions provisioned automatically when a project is taken up.

The spec already leans this way

Part F: "Terraform + cloud-init: deferred. When adopted, bpg/proxmox + cloud-init, VM definitions as code, clean destroy/apply; the dev agent becomes a candidate for immutable rebuilds."

What it deletes

#27 per-project state largely evaporates: a single-project agent makes the single-row agent_state correct rather than narrow.
#28 room per project falls out for free — A1 already gives each agent a distinct identity and room, so project rooms come from the deployment shape rather than new transport machinery.

What it costs

Provisioning sprawl, mostly. Each agent needs its own Matrix account, Gitea service account, LiteLLM virtual key, Bitwarden machine account, room, and VM. §0's naming rule (one string shared across VM, container, Matrix account, machine account) becomes parametric — nisse-dev-<project> — which is a natural extension but means minting identities across five services on demand. That is Part F work, currently deferred, and plausibly a larger build than the agent itself.

Two questions to settle first

Ephemeral or long-lived? Ephemeral fits the guiding principle that the dev agent is "disposable and sealed", and avoids N idle VMs — but requires durable state to survive teardown. Part H helps here already: plans and approvals are externalised to Gitea specifically so gate state can be re-derived after state-volume loss, which is most of what an ephemeral agent needs.

VM per project, or containers on a shared VM? B3 chose the VM boundary for unattended arbitrary command execution. Per-project containers sharing one VM is much cheaper but genuinely weaker isolation — acceptable when every project is the operator's own, not a free optimisation.

Prerequisite

You cannot automate provisioning for something whose runtime requirements have not been observed. Nothing has yet run the agent — nisse_dev/main.py is still the placeholder entry point and nothing outside tests constructs an Orchestrator. Getting one agent running for real comes first; it is what tells us what to automate N of.

Speculative — filed to preserve the reasoning, not scheduled. Would **subsume** #27 and most of #28. ### The idea Rather than one dev agent that tracks several projects, run one agent per project, with the VM, agent, identities and permissions provisioned automatically when a project is taken up. ### The spec already leans this way Part F: "Terraform + cloud-init: deferred. When adopted, `bpg/proxmox` + cloud-init, VM definitions as code, clean `destroy`/`apply`; **the dev agent becomes a candidate for immutable rebuilds**." ### What it deletes - **#27 per-project state** largely evaporates: a single-project agent makes the single-row `agent_state` correct rather than narrow. - **#28 room per project** falls out for free — A1 already gives each *agent* a distinct identity and room, so project rooms come from the deployment shape rather than new transport machinery. ### What it costs Provisioning sprawl, mostly. Each agent needs its own Matrix account, Gitea service account, LiteLLM virtual key, Bitwarden machine account, room, and VM. §0's naming rule (one string shared across VM, container, Matrix account, machine account) becomes parametric — `nisse-dev-<project>` — which is a natural extension but means minting identities across five services on demand. That is Part F work, currently deferred, and plausibly a larger build than the agent itself. ### Two questions to settle first **Ephemeral or long-lived?** Ephemeral fits the guiding principle that the dev agent is "disposable and sealed", and avoids N idle VMs — but requires durable state to survive teardown. Part H helps here already: plans and approvals are externalised to Gitea specifically so gate state can be re-derived after state-volume loss, which is most of what an ephemeral agent needs. **VM per project, or containers on a shared VM?** B3 chose the VM boundary for unattended arbitrary command execution. Per-project containers sharing one VM is much cheaper but genuinely weaker isolation — acceptable when every project is the operator's own, not a free optimisation. ### Prerequisite You cannot automate provisioning for something whose runtime requirements have not been observed. Nothing has yet *run* the agent — `nisse_dev/main.py` is still the placeholder entry point and nothing outside tests constructs an `Orchestrator`. Getting one agent running for real comes first; it is what tells us what to automate N of. ### Related #26 multiple forges · #27 per-project state · #28 room per project · #29 project creation

dev-agent referenced this issue

2026-09-08 22:32:09 +00:00

Move configuration from .env to a YAML config file #32

dev-agent referenced this issue

2026-09-30 21:06:14 +00:00

Propose the Development Plan #84

dev-agent referenced a pull request that will close this issue

2026-10-02 16:35:56 +00:00

Revise the deployment model: an agent host and tool VMs #90

dev-agent closed this issue

2026-10-02 19:36:33 +00:00

dev-agent commented

2026-10-02 19:36:53 +00:00

Superseded by the deployment model in #90: one nisse-dev instance, with a build VM per project (Architecture X1, D3). Projects are isolated by their build VMs, not by separate agent instances.

🤖 Generated with Claude Code

Superseded by the deployment model in #90: one `nisse-dev` instance, with a build VM per project (Architecture X1, D3). Projects are isolated by their build VMs, not by separate agent instances. 🤖 Generated with [Claude Code](https://claude.com/claude-code)

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: dev/nisse#30