Subagents: one prompt in, one result out, no memory of the others

knowledge/workflows/README.md names three things people mean by "agent" and puts this one first, because everything else in this course is built on top of it: "A single agent call. One prompt, one subagent, one job — read this file, do this transcription, verify this claim. Every agent(...) call inside a script below is one of these. They have no memory of each other unless a script hands them each other's output." The article this whole skill traces back to says the same thing in fewer words: "An agent is one prompt in, one result out, with no memory of any other agent unless something explicitly hands it that agent's output." That's the entire primitive. Everything a Workflow script does — the pipeline/parallel choice, the adversarial-verify pattern, the whole idea of "several agents checking each other" — is orchestration built around that one fact: an agent knows exactly what it's told and nothing else.

This module's own module file is itself an instance of the primitive it's describing. The five module files that make up this course, and the build script and course registration that make them reachable, were produced by exactly one subagent — this one. It read the two lesson files that already existed in this repository, read a different course's build script to copy its structure exactly, and wrote everything else from that, with no memory of whatever session spawned it beyond the single task prompt it was given. That's not a special case. It's the ordinary way this repository gets course content written.

#Structured output turns a subagent's answer into data, not prose to parse

agent(prompt, opts) spawns one subagent and returns its result — a string by default, or, when opts.schema is a JSON Schema, a validated object instead. The mechanism is what makes this reliable rather than a hopeful convention: "the subagent is forced to call a StructuredOutput tool and agent() returns the validated object — no parsing needed," and a schema mismatch triggers a retry at the tool-call layer instead of a downstream JSON.parse crash three steps later, in code that has no idea why the string it received doesn't look like JSON. That single design choice is why a Workflow script can safely map a synthesis agent's findings array straight into a fix phase without anyone hand-writing a regex to extract "how many findings were there" out of a paragraph.

#Isolation is a feature when a script uses it on purpose

The reason to spawn a fresh subagent instead of continuing in the same context isn't speed alone — it's that a subagent with a narrow prompt and no inherited reasoning genuinely reasons differently than one that's already invested in an answer. agent-orchestration's own rules make this explicit for the adversarial-verify case specifically: a verifying agent should be spawned "with a clean context that does not include the first agent's own reasoning trace or self-report — a verifier that inherits the claim-maker's context inherits its blind spot before it even starts." A subagent that never saw the first agent's confident explanation for why its finding is correct has nothing to be talked out of. That's the entire value of "no memory of each other" turned into a deliberate design choice rather than treated as a limitation to work around — the Workflows module's adversarial-verify pattern and the Honest Limits module's account of same-model reviewer bias both build directly on this fact.

#What "no shared memory" costs when two agents write to the same file

Isolation cuts both ways. The Workflows module's parallel() example shows the real version of this cost, and the fix: 27 agents auditing 27 separate lesson files were each explicitly told not to write their own findings straight to a shared glossary file, because "a separate consolidation step adds these afterward so 27 agents aren't all racing to edit the same shared glossary file concurrently." No agent in that batch had any way of knowing what any other agent in the same batch was about to write — that's what "no memory of each other" means in practice — so the script, not the agents, had to be the thing enforcing that only one write ever landed. This repository's own convention for human-and-agent sessions sharing one working tree states the identical rule at a different scale: give each writing agent — or each writing session — an isolated worktree and explicit file ownership, and re-check a shared file immediately before editing it rather than trusting how it looked at the start of a long session. The mechanism is the same collision in both cases: something with no visibility into a concurrent writer's in-flight changes is about to overwrite them, and the fix is never "hope it doesn't happen" — it's a barrier, a single designated writer, or an isolated scope that makes the collision structurally impossible instead of merely unlikely.

#The concurrency and cost that come with spawning one

A subagent isn't free, and a real workflow queues against real limits: a concurrency cap "documented at 16 or fewer running at once, depending on the machine," and a hard ceiling of 1,000 agent calls in a single workflow's lifetime. Those numbers matter most exactly when isolation is working as intended — every extra subagent spawned for a clean-context verification pass, every extra worker given its own narrow slice of a large job, is a full separate call against that budget. The Workflows module goes further into what that trade actually costs and when it's worth paying. What this module establishes is the unit the whole budget is denominated in: not "how much work," but how many separate prompt-in-result-out calls, each starting from nothing but what it was told.