Live data from Hacker News

Cord: Coordinating Trees of AI Agents

june.kim

11–20 of 93 posts

Re: Cord: Coordinating Trees of AI Agents

#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 demand. Shallow libraries and frameworks are dead.

Re: Cord: Coordinating Trees of AI Agents

#12
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

This approach seems interesting, but in my experience, a single "agent" with proper context management is better than a complicated agent graph. Dealing with hand-off (+ hand back) and multiple levels of conversations just leaves too much room for critical information to get siloed.

If you have a narrow task that doesn't need full context, then agent delegation (putting an agent or inference behind a simple tool call) can be effective. A good example is to front your RAG with a search() tool with a simple "find the answer" agent that deals with the context and can run multiple searches if needed.

I think the PydanticAI framework has the right approach of encouraging Agent Delegation & sequential workflow first and trying to steer you away graphs[0]

[0]:https://ai.pydantic.dev/graph/

Re: Cord: Coordinating Trees of AI Agents

#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 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"
depends_on is also based on context query but in this case it's a map where keys are subagent conversation ids that are blockers to perform this handed over task and value is context query what to extract to inject.

Re: Cord: Coordinating Trees of AI Agents

#14
Historically, Claude code used sequential planning with linear dependencies using tools like TodoWrite, TodoRead. There are open source MCP equivalents of TodoWrite.

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.

Re: Cord: Coordinating Trees of AI Agents

#16
post #12
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

This approach seems interesting, but in my experience, a single "agent" with proper context management is better than a complicated agent graph. Dealing with hand-off (+ hand back) and multiple levels of conversations just leaves too much room for critical information to get siloed. If you have a narrow task that doesn't need full context, then agent delegation (putting an agent or inference behind a simple tool call…

This isnt true for big code bases. Subagents or orchestration become vital for context handholding

Re: Cord: Coordinating Trees of AI Agents

#17
post #16
post #12

Earlier quoted context omitted.

This approach seems interesting, but in my experience, a single "agent" with proper context management is better than a complicated agent graph. Dealing with hand-off (+ hand back) and multiple levels of conversations just leaves too much room for critical information to get siloed. If you have a narrow task that doesn't need full context, then agent delegation (putting an agent or inference behind a simple tool call…

This isnt true for big code bases. Subagents or orchestration become vital for context handholding

yeah i think sub agents are needed, missed that in my comment

Re: Cord: Coordinating Trees of AI Agents

#19
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

I don’t think so. The harness matters a lot for the task at hand, and some harnesses are much better than others for some kinds of problems.
Post reply on HN