Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Cord: Coordinating Trees of AI Agents

june.kim

Post reply on HN
Print view View original

31–40 of 93 posts

Re: Cord: Coordinating Trees of AI Agents

#32

Post by eshaham78 »

kimjune01 wrote: post #29
kgc wrote: post #18

Claude basically does this now (including deciding when to use subagents, tools, and agent teams). I built a similar thing a month ago and saw the writing on the wall.

I agree, Claude does spawn subagents but subagents don't spawn sub-subagents.

[dead]

Re: Cord: Coordinating Trees of AI Agents

#33

Post by kimjune01 »

jamilton wrote: post #7

Feels very AI written in a way that makes it annoying to read with all the repetitive short sentences. Neat concept though, would be cool to see some tests of performance on some tasks.

thanks, I would've hand-written the whole thing myself but I was way too eager to get it out the door!

Re: Cord: Coordinating Trees of AI Agents

#35

Post by kimjune01 »

dcre wrote: post #8

Not exactly a surprise Claude did this out of the box with minimal prompting considering they’ve presumably been RLing the hell out of it for agent teams: https://code.claude.com/docs/en/agent-teams

interestingly, I discovered that running `claude` sessions inside `claude` is disabled by default via env vars.

Re: Cord: Coordinating Trees of AI Agents

#36

Post by kimjune01 »

mikert89 wrote: post #9

all of these frameworks will go away once the model gets really smart. it will just be tool search, tools, and the model in the short run, ive found the open ai agents one to be the best

If context window is infinite and performance isn't constrained, the subagent stuff isn't necessary. Until then, harnesses are for context management and parallelism.

Re: Cord: Coordinating Trees of AI Agents

#37

Post by kimjune01 »

vlmutolo wrote: post #6

I wonder if the “spawn” API is ever preferable over “fork”. Do we really want to remove context if we can help it? There will certainly be situations where we have to, but then what you want is good compaction for the subagent. “Clean-slate” compaction seems like it would always be suboptimal.

context rot and bias removal would be two good reasons to start a freshly spawned agent.

Re: Cord: Coordinating Trees of AI Agents

#38

Post by kimjune01 »

aleksiy123 wrote: post #21
vlmutolo wrote: post #6

I wonder if the “spawn” API is ever preferable over “fork”. Do we really want to remove context if we can help it? There will certainly be situations where we have to, but then what you want is good compaction for the subagent. “Clean-slate” compaction seems like it would always be suboptimal.

This is my question also but a bit different. Is there any reason to explicitly have this binary decision. Instead of single primitive where the parent dynamically defines the childs context. Naturally resulting in either spawn or fork or anything in between.

That actually sounds even better than the binary. Thanks for the suggestion!

Re: Cord: Coordinating Trees of AI Agents

#40

Post by kimjune01 »

mirekrusin wrote: post #13

Nice one. 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 deci…

Thank you for the suggestion, I will explore this in the next iteration. I'm learning how to translate how humans do context management into how agents should do them
Post reply on HN