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

51–60 of 93 posts

Re: Cord: Coordinating Trees of AI Agents

#51

Post by botusaurus »

tovej wrote: post #46
sriku wrote: post #11

We built something like this by hand without much difficulty for a product concept. We'd initially used LangGraph but we ditched it and built our own out of revenge for LangGraph wasting our time with what could've simply been an ordinary python function. 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…

This is one of the worst takes I've ever heard. There's a reason industries have standards. If you replace established libraries with vibecoded alternatives you will have: - less documentation - less tested code - no guarantees it's doing the right thing - a dice roll for whether it works this time on this project - a bad time in general

langchain is stuck in innovator dilemma - it was built for gpt 3.5, or 4, it needs a different design for todays models, but cant evolve because of existing users and backward compatibility

just like jQuery still exists and is being actively developed

Re: Cord: Coordinating Trees of AI Agents

#52

Post by athrowaway3z »

Every time i see some new orchestrator framework worth more than a few hundred loc i cringe so hard. Reddit is flooded with them on the daily and HN has them on the front page occasionally.

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.

Re: Cord: Coordinating Trees of AI Agents

#53

Post by onion2k »

bofadeez wrote: post #39

One agent can't even be trusted to think autonomously much less a tree of them

Trust is not objective. It's built between parties over time by looking at actions and the results of those actions. In other words, it's entirely subjective based on what's happened between the parties involved. You haven't built that trust with AI agents, or the agents have done things to lose that trust (assuming you've tried), but others have. You can't just dismiss their experience as invalid compared to your own.

Re: Cord: Coordinating Trees of AI Agents

#56

Post by bizzletk »

AxiomLab wrote: post #49

[dead]

The article addresses this:

> This made sense when agents were unreliable. You’d never let GPT-3 decide how to decompose a project. But current models are good at planning. They break problems into subproblems naturally. They understand dependencies. They know when a task is too big for one pass.

> So why are we still hardcoding the decomposition?

Re: Cord: Coordinating Trees of AI Agents

#57

Post by chris_nielsen »

sulam wrote: post #27
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.

This is the comment I was looking for. In the last month or so this is how Claude Code represents tasks, as a DAG of objectives, built from plan mode.

Yeah exactly. I noticed Claude start doing exactly this a month ago too. It recursively breaks problems down while allowing you to either change direction at each level or keep going. This is where claude jumped up to be legitimately better at solving real world problems than a substantial amount of developers. I can only assume the other AI companies are just going to copy the approach shortly too.

Re: Cord: Coordinating Trees of AI Agents

#58

Post by kimjune01 »

sriku wrote: post #11

We built something like this by hand without much difficulty for a product concept. We'd initially used LangGraph but we ditched it and built our own out of revenge for LangGraph wasting our time with what could've simply been an ordinary python function. 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…

i noticed the same, so in the README, I describe `cord` as a protocol:

``` This repo is one implementation of the Cord protocol. The protocol itself — five primitives, dependency resolution, authority scoping, two-phase lifecycle — is independent of the backing store, transport, and agent runtime. You could implement Cord with Redis pub/sub, Postgres for multi-machine coordination, HTTP/SSE instead of stdio MCP, or non-Claude agents. See RFC.md for the full protocol specification. ```

Re: Cord: Coordinating Trees of AI Agents

#59

Post by kimjune01 »

simianwords wrote: post #47

Why can’t you just give access to all tools to all subagents? That’s more general than what you’ve done. Surely it can figure out how to backtrack or keep context? But I do like you approach and I feel this is the next step.

context rot. The human equivalent is saying, why cant the CEO write all the code and reply to all the emails

Re: Cord: Coordinating Trees of AI Agents

#60

Post by kimjune01 »

tovej wrote: post #43

This is a vibeslop project with a vibeslop write-up. 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…

no solution is final, but if you have a better working solution, please share!
Post reply on HN