Skimmed the repo, this is basically the irreducible core of an agent: small loop, provider abstraction, tool dispatch, and chat gateways . The LOC reduction (99%, from 400k to 4k) mostly comes from leaving out RAG pipelines, planners, multi-agent orchestration, UIs, and production ops.

▲

baby 4 hours ago | parent | next [-]

RAG seems odd when you can just have a coding agent manage memory by managing folders. Multi agent also feels weird when you have subagents.

▲

rando77 3 hours ago | parent | next [-]

I've been leaning towards multi agent because sub agent relies on the main agent having all the power and using it responsibly.

▲

PlatoIsADisease 2 hours ago | parent | prev | next [-]

Interesting.

I guess RAG is faster? But I'm realizing I'm outdated now.

	▲	lxgr 2 hours ago \| parent [-]
		No, RAG is definitely preferable once your memory size grows above a few hundred lines of text (which you can just dump into the context for most current models), since you're no longer fighting context limits and needle-in-a-haystack LLM retrieval performance problems.

▲

antirez 4 hours ago | parent | prev [-]

Totally useless indeed.

▲

naasking 2 hours ago | parent | prev | next [-]

Unless I'm misunderstanding what they are, planners seem kind of important.

	▲	johaugum 23 minutes ago \| parent [-]
		As you mentioned, that depends on what you mean by planners. An LLM will implicitly decompose a prompt into tasks and then sequentially execute them, calling the appropriate tools. The architecture diagram helpfully visualizes this [0] Here though, planners means autonomous planners that exist as higher level infrastructure, that does external task decomposition, persistent state, tool scheduling, error recovery/replanning, and branching/search. Think a task like “Prompt: “Scan repo for auth bugs, run tests, open PR with fixes, notify Slack.” that just runs continuously 24/7, that would be beyond what nanobot could do. However, something like “find all the receipts in my emails for this year, then zip and email them to my accountant for my tax return” is something nanobot would do. [0] https://github.com/HKUDS/nanobot/blob/main/nanobot_arch.png

▲

m00dy 3 hours ago | parent | prev [-]

RAG is broken when you have too much data.

▲

plingamp 2 hours ago | parent | next [-]

Specifically when the document number reaches around 10k+, a phenomenon called "Semantic Collapse" occurs.

https://dho.stanford.edu/wp-content/uploads/Legal_RAG_Halluc...

▲

thunky 3 hours ago | parent | prev | next [-]

Gemini with Google search is RAG using all public data, and it isn't broken.

▲

fhd2 2 hours ago | parent [-]

It's not tool use with natural language search queries? That's what I'd expect.

	▲	kaicianflone 2 hours ago \| parent [-]
		It is tool use with natural language search queries but going down a layer they are searched on a vector DB, very similar to RAG. Essentially Google RankBrain is the very far ancestor to RAG before compute and scaling.

▲

PlatoIsADisease 2 hours ago | parent | prev [-]

Cant you make thresholds higher?

Hmm... I guess not, you might want all that data.

Super interesting topic. Learning a lot.