Dynamic agent networks

With the static agent_<name> tool, you can give one agent to another as a tool — but which sub-agent gets called is fixed in the prompt flow. A network is the dynamic version of this: a router LLM (supervisor) decides on every turn, looking at the intermediate results so far, which one of the registered agents gets which task — or writes the final answer once enough has been gathered. It is the supervisor.network() pattern.

GNL's difference is determinism: every decision the router makes freezes into the <runId>:net:route:<i> key via CAS (applying the "freeze the winner" pattern from withModelFallbackto routing). When a run crashes and is resumed, the router is not called again — frozen decisions are read back, the same path is taken. Sub-agent step results also freeze to <runId>:net:step:<i>, so a completed sub-agent is skipped entirely on resume (the same synergy as the two-level durability in agent-as-tool).

Networks are defined in the createGnl configuration, under networks: . Each network takes a router model plus a list of registered agent names it can route to — when picking an agent, the router sees each agent's description(single source of truth; the same one used for agent-as-tool).

import { createGnl } from '@gnldev/durable';

const gnl = createGnl({
  storage,
  agents: {
    researcher: { model, description: 'Gathers facts from the web / a knowledge base' },
    writer: { model, description: 'Toplanan olgulardan taslak yazar' },
    critic: { model, description: 'Reviews the draft and asks for corrections' },
  },
  networks: {
    editorial: {
      router: candidateModels,           // spec / obje / fallback zinciri / dinamik
      agents: ['researcher', 'writer', 'critic'],
      system: 'Write a good article; loop with the critic when needed.',
      maxIterations: 6,                   // ceiling on routing turns (default 6)
    },
  },
});

A network runs durably via gnl.runNetwork(name, ...) . Sub-agent call semantics are identical to agent-tool: model fallback freezes to a nested runId, run limits are inherited exactly the same way. Each sub-agent writes to its own nested journal (net:<runId>:<i>) → mid-crash resume is covered at the sub-agent level too.

const res = await gnl.runNetwork('editorial', {
  runId: 'r1',
  task: 'Write three paragraphs explaining the GNL exactly-once guarantee.',
});
// res => { runId, text, steps: [{ i, agent, task, text }], iterations, interrupts }

If a sub-agent hits a guard and is suspended (interrupts populated), that step is not frozen — the interruption propagates upward and gets marked suspended: { i, agent, task } . When called again after approval with the same runId , the router doesn't run since the route decision is already frozen; the sub-agent resumes from its own journal, and the step freezes only once it completes.

Studio's GET /runs/:id/network endpoint reads the route and step records from the journal and returns the network's dynamic tree (the Networks view). This is derived after the fact: getNetworkTrace extracts router decisions and executed steps from the journal — no live instrumentation needed, complete even after a crash.

import { getNetworkTrace } from '@gnldev/durable';

const tree = await getNetworkTrace(journal, 'r1');
// tree => { routes: [{ i, decision }], steps: [{ i, agent, task, text }] }