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

Don't Build Multi-Agents

cognition.ai

Post reply on HN
Print view View original

21–30 of 95 posts

Re: Don't Build Multi-Agents

#21

Post by photochemsyn »

Don't hide your content from people using NoScript, how about that for starters...

And oh great, another Peter Thiel company booted to the top of HN, really?

> "Cognition AI, Inc. (also known as Cognition Labs), doing business as Cognition, is an artificial intelligence (AI) company headquartered in San Francisco in the US State of California. The company developed Devin AI, an AI software developer...Originally, the company was focused on cryptocurrency, before moving to AI as it became a trend in Silicon Valley following the release of ChatGPT... With regards to fundraising, the company was backed by Peter Thiel's Founders Fund which provided $21 million of funding to it in early 2024, valuing the company at $350 million.[2] In April 2024, Founders Fund led a $175 million investment into Cognition valuing the company at $2 billion making it a Unicorn."

The bubble's gonna pop, and you'll have so much egg on your face. This stuff is just compilers with extra compute and who got rich off compilers? VC people...

Re: Don't Build Multi-Agents

#22

Post by antonvs »

WalterSear wrote: post #19
behnamoh wrote: post #2

How is this fundamentally any different than Erlang/Elixir concepts of supervisors controlling their child processes? It seems like the AI industry keeps re-discovering several basic techniques that have been around since the 80s. I'm not surprised—most AI "engineers" are not really good software engineers; they're often "vibe engineers" who don't read academic papers on the subject and keep re-inventing the wheel. I…

Apart from requiring entirely the opposite solution? With respect, if there's an AI bubble, I can't see it for all the sour grapes, every time it's brought up, anywhere.

A lot of it seems to be resistance to change. People are afraid their skillset may be losing relevance, and instead of making any effort to adapt, they try to resist the change.

Re: Don't Build Multi-Agents

#23

Post by antonvs »

downrightmike wrote: post #4
behnamoh wrote: post #2

How is this fundamentally any different than Erlang/Elixir concepts of supervisors controlling their child processes? It seems like the AI industry keeps re-discovering several basic techniques that have been around since the 80s. I'm not surprised—most AI "engineers" are not really good software engineers; they're often "vibe engineers" who don't read academic papers on the subject and keep re-inventing the wheel. I…

I blame managers that get all giddy about reducing head count. Sure this year, you get a -1% on developer time (seniors believe they get a 20% increase when its really a decrease for using AI) But then next year and the year after, the technical debt will be to the point where they just need to throw out the code and start fresh. Then the head count must go up. Typical short term gains for long term losses/bankruptcy

> seniors believe they get a 20% increase when its really a decrease for using AI

There’s no good evidence to support that claim. Just one study which looked at people with minimal AI experience. Essentially, the study found that effective use of AI has a learning curve.

Re: Don't Build Multi-Agents

#24

Post by sputknick »

This is very similar to the conclusion I have been coming to over the past 6 months. Agents are like really unreliable employees, that you have to supervise, and correct so often that its a waste of time to delegate to them. The approach I'm trying to develop for myself is much more human centric. For now I just directly supervise all actions done by an AI, but I would like to move to something like this: https://github.com/langchain-ai/agent-inbox where I as the human am the conductor of work agents do, then check in with me for further instructions or correction.

Re: Don't Build Multi-Agents

#26

Post by CuriouslyC »

We're in the context engineering stone age. You the engineer shouldn't be trying to curate context, you should be building context optimization/curation engines. You shouldn't be passing agents context like messages, they should share a single knowledge store with the parent, and the context optimizer should just optimally pack their context for the task description.

Re: Don't Build Multi-Agents

#27

Post by peab »

curl-up wrote: post #3

In the context compression approach, why aren't the agents labeled as subagents instead? The compressed context is basically a "subtask". This is my main issue with all these agentic frameworks - they always conviniently forget that there is nothing "individual" about the thing they label "an agent" and draw a box around. Such "on demand" agents, spawned directly from previos LLM output, are never in any way substant…

Yeah, i agree with thinking of things as a single agent + tools.

From the perspective of the agent, whether the tools are deterministic functions, or agents themselves, is irrelevant.

Re: Don't Build Multi-Agents

#28

Post by nickreese »

CuriouslyC wrote: post #26

We're in the context engineering stone age. You the engineer shouldn't be trying to curate context, you should be building context optimization/curation engines. You shouldn't be passing agents context like messages, they should share a single knowledge store with the parent, and the context optimizer should just optimally pack their context for the task description.

Is there a framework for this?

Re: Don't Build Multi-Agents

#29

Post by colonCapitalDee »

edoceo wrote: post #17
colonCapitalDee wrote: post #10

I'm building a simple agent accessible over SMS for a family member. One of their use cases is finding recipes. A problem I ran into was that doing a web search for recipes would pull tons of web pages into the context, effectively clobbering the system prompt that told the agent to format responses in a manner suited for SMS. I solved this by creating a recipe tool that uses a sub-agent to do the web search and retu…

Are you in USA? How to get around those 10DLC limits on typical SMS/API things (eg Twilio). Or did you go through that process (which seems a lot for a private use-case)

I am in the USA! Although these days that exclamation point doesn't feel great...

I'm using an old Android phone (Pixel 2 from 2017), a 5$ a month unlimited SMS plan from Tello, and https://github.com/capcom6/android-sms-gateway. For bonus points (I wanted to roll my own security, route messages from different numbers to prod and ppe instances of my backend, and dedup messages) I built a little service in Go that acts as an intermediary between my backend and android-sms-gateway. I deploy this service to my android device using ADB, android-sms-gateway talks to it, and it talks to my backend. I also rooted the android device so I could disable battery management for all apps (don't do this if you want to walk around with the phone of course). It works pretty well!

I plan to open-source this eventually TM, but first I need to decouple my personal deployment infra from the bits useful to everyone else

Re: Don't Build Multi-Agents

#30

Post by CuriouslyC »

mreid wrote: post #8

Is it concerning to anyone else that the "Simple & Reliable" and "Reliable on Longer Tasks" diagrams look kind of like the much maligned waterfall design process?

Waterfall is just a better process with agents. Agile is garbage when inserting yourself in the loop causes the system to drop to 10% velocity.
Post reply on HN