No incremental node/edge team-graph edit: teams_save needs the full ~110k nodes array the agent can't even load

Editing a large agent team over MCP is close to impossible today. To ADD 2 nodes + 3 edges to an 11-persona team (~108k chars of stepInstructions + customSystemPrompt), the only path is teams_save with the COMPLETE nodes array: there is no incremental add-node, and nodePatches only edits an EXISTING node (it rejects an unknown id and never touches edges). Worse, teams_get returns ~110k that the agent's file reader cannot paginate, because each persona is one single long string, so the agent cannot even load the graph into context to re-emit it.

Investigation was read-only, via the live MCP tools (teams_get, teams_save with dryRun, nodePatches) and capabilities_get({topic:"teams"}). Measured 2026-09-11 on a scope:global team.

Workaround I had to use: a structural teams_save of stubs, then a per-node refill via nodePatches with ASCII-escaped JSON. It worked, but it is fragile and expensive, and it left the global team showing stub personas for minutes.

Requests, ordered by value:

1. Incremental structural ops: add/remove NODES and EDGES without resending the whole graph (e.g. addNodes/removeNodes/addEdges/removeEdges, or extend nodePatches to upsert a node by id + a new edgePatches).
2. Structure-only read: a teams_get projection that OMITS the big fields (stepInstructions/customSystemPrompt), or a per-node get, so an agent can reason over topology without pulling 100k+ it cannot paginate.
3. Pagination / a higher result cap on teams_get and teams_save for large graphs.

Impact: today adding one node to a global team risks corrupting the other personas mid-edit.

AgentsRoom diagnostics

• App version: 1.171.0
• OS: linux 7.0.0-31-generic (x64)
• Agent CLI: claude
• MCP server: 1.22.0
• App language: system

Problem to solve

Adding or removing a single node or edge in a large team forces resending the entire nodes array via teams_save. There is no incremental op: nodePatches edits an EXISTING node only, never an edge, and rejects an unknown id. And teams_get returns the full graph (~110k for an 11-persona team) with each persona as one long string, which the agent's file reader cannot paginate, so the agent cannot even load the graph to re-emit it. Net effect: editing one node of a scope:global team risks corrupting the other personas mid-edit.

Proposed behavior

1. Incremental structural ops: addNodes / removeNodes / addEdges / removeEdges, OR extend nodePatches to upsert a node by id, plus a new edgePatches for edges, so a node/edge change never resends the whole graph.
2. A structure-only teams_get projection that omits stepInstructions and customSystemPrompt (or a per-node get), so topology can be read without the big fields.
3. Pagination, or a higher result cap, on teams_get and teams_save for large graphs, since the full return also overflows the tool-result cap today.

Who benefits

Anyone editing a large or scope:global agent team over MCP, especially an agent driving team-graph changes programmatically. Small teams are fine today; the wall is hit around 10+ nodes with rich stepInstructions/customSystemPrompt, where the full graph exceeds what a single tool result or file read can carry, so even reading the graph to re-emit it becomes impossible.

Acceptance criteria

An agent can add or remove a node or an edge in a large team with a single targeted call, and can read the team's topology without pulling 100k+ of prompt text it cannot paginate. No stub-and-refill workaround, and no window in which a scope:global team is left half-edited with stub personas.