I can forgive (even root for) someone who puts in the effort themselves to understand a problem and write about it, even if they fall short or miss. They have skin in the game. I have little patience for someone who doesn't understand the disproportionate burden generated content places on the READER.

I can certainly tell they've put the model through the ringer to be terse and use simple language, etc. But I am struggling to separate the human ideas from the vibed ones, and the tone of the whole thing is the usual LLM elevator pitch with "hushed reverence" * "movie trailer cadence".

But "spawn/fork" is just a different way of labeling the fairly-well-understood tactic (I won't call it a strategy) of just how much context to provide sub-agents. Claude Code already "spawns" everytime it does an explore. It can do this concurrently, too.

Beyond that, they seem to express wonder at how well models can use tools:

> In the example above, the agent chose spawn for the independent research tasks and fork for the analysis that needs everything. It made this choice on its own — the model understands the distinction intuitively.

Emphasis mine. They (or the model whose output they blindly published) are anthropomorphizing software that is already designed to work this way. They gave it "fork" and "spawn" tools. Are they claiming they didn't describe exactly how they were supposed to be used in the tool spec?

You should also try to make context query the first class primitive.

Context query parameter can be natural language instruction how to compact current context passed to subagent.

When invoking you can use values like "empty" (nothing, start fresh), "summary" (summarizes), "relevant information from web designer PoV" (specific one, extract what's relevant), "bullet points about X" etc.

This way LLM can decide what's relevant, express it tersly and compaction itself will not clutter current context – it'll be handled by compaction subagent in isolation and discarded on completion.

What makes it first class is the fact that it has to be built in tool that has access to context (client itself), ie. it can't be implemented by isolated MCP because you want to avoid rendering context as input parameter during tool call, you just want short query.

Ie. you could add something like:

  handover(prompt, context_query, depends_on: { conversation_id_1: "result", conversation_id_2: "just result number" }) -> conversation_id"

If you leave agent interaction unconstrained, the probabilistic variance compounds into chaos. By encapsulating non-deterministic nodes within a rigidly defined graph structure, you regain control over the state machine. Coordination requires deterministic boundaries.

I've been playing with a closely related idea of treating the context as a graph. Inspired by the KGoT paper - https://arxiv.org/abs/2504.02670

I call this "live context" because it's the living brain of my agents

Neat concept though, would be cool to see some tests of performance on some tasks.

My current setup is this;

- `tmux-bash` / `tmux-coding-agent`

- `tmux-send` / `tmux-capture`

- `semaphore_wait`

The other tools all create lockfiles and semaphore_wait is a small inotify wrapper.

They're all you need for 3 levels of orchestration. My recent discovery was that its best to have 1 dedicated supervisor that just semaphore_wait's on the 'main' agent spawning subagents. Basically a smart Ralph-wiggum.

https://github.com/offline-ant/pi-tmux if anybody is intrested.

I’ve found both the open source TodoWrite and building your own TodoWrite with a backing store surprisingly effective for Planning and avoiding developer defined roles and developer defined plans/workflows that the author calls in the blog for AI-SRE usecases. It also stops the agent from looping indefinitely.

Cord is a clever model and protocol for tree-like dependencies using the Spawn and Fork model for clean context and prior context respectively.

Into a general purpose markup language + runtime for multi step LLM invocations. Although efforts so far have gotten nowhere. I have some notes on my GitHub profile readme if anyone curious: https://github.com/colbyn

Here’s a working example: https://github.com/colbyn/AgenticWorkflow

(I really dislike the ‘agentic’ term since in my mind it’s just compilers and a runtime all the way down.)

But that’s more serial procedural work, what I want is full blown recursion, in some generalized way (and without liquid templating hacks that I keep restoring to), deeply needed nested LLM invocations akin to how my dataset generation pipeline works.

PS

Also I really dislike prompt text in source code. I prefer to factor in out into standalone prompt files. Using the XML format in my case.

Never again committing to any "framework", especially when something like Claude Code can write one for you from scratch exactly for what you want.

We have code on demand. Shallow libraries and frameworks are dead.

Trees? Trees aren't expressive enough to capture all dependency structures. You either need directed acyclical graphs or general directed graphs (for iterative problems).

Based on the terminology you use, it seems you've conflated the graphs used in task scheduling with trees used in OS process management. The only reason process trees are trees are for OS-specific reasons (need for a single initializing root process, need to propagate process properties safely) . But here you're just solving a generic problem, trees are the wrong data structure.

- You have no metrics for what this can do - No reason given for why you use trees (the text just jumps from graph to trees at one point) - None of the concepts are explained, but it's clearly just the UNIX process model applied to task management (and you call this 60 year old idea "genuinely new"!)

https://github.com/mikeyobrien/ralph-orchestrator

The tasks tool is designed to validate a DAG as input, whose non-blocked tasks become cheap parallel subagent spawns using Erlang/OTP.

It works quite well. The only problem I’ve faced is getting it to break down tasks using the tool consistently. I guess it might be a matter of experimenting further with the system prompt.

[1]: https://github.com/matteing/opal

in the short run, ive found the open ai agents one to be the best

https://github.com/waynenilsen/crumbler

This uses recursive task decomposition but is single thread by design. Honestly fast enough for me and makes it easier to reason about

Brainfile - An open protocol for agent-to-agent task coordination.

https://brainfile.md/

Well worth a look imo

Opencode getting fork was such a huge win. It's great to be able to build something out, then keep iterating by launching new forks that still have plenty of context space available, but which saw the original thing get built!

But I do like you approach and I feel this is the next step.

cord - The #1 AI-Powered Job Search Platform for people in tech