Daniel @indentfour

Unpopular opinion: tool-calling via LLM is a last resort, not a default. If the flow is predictable, make it deterministic. Linear graph, defined transitions, no model deciding what happens next. Save the autonomy for the parts where you genuinely can't enumerate the options upfront. Most agents don't need to be agents.

RAG systems are usually much better at finding one specific fact buried in 10,000 documents than synthesising an accurate answer from 10 sources that slightly disagree. Needle in a haystack: surprisingly good. Conflicting information across sources: surprisingly bad.

The AI Engineering Gap: AI vendor pitches seems to always be about connectivity: plug into your system, integrate with 40 tools etc. The real problem is actually getting outputs that are genuinely useful, accurate and trustworthy enough to act on. Connection is usually a solved problem. Useful outcomes are not.

@OnchainLu And for learning to become an AI engineer focus on simple solutions but learn how to deploy them to production as a priority.

@0xlelouch_ The busted eval is a better interview than any framework quiz. You can learn LangGraph fundamentals faster than you can learn to read a trace and work backwards from a bad output.

@sairahul1 Good summary but still worth checking out the book. Of the 21 chapters, three are non-negotiable for production systems: Exception Handling, Guardrails and Evaluation / Monitoring. They're in Part 3 and 4 which means most people probably won't get there.

The hardest part of building AI systems isn't the AI. It's deciding what "correct" looks like when two sources say different things and your system has to pick one. That's not a technical problem. It's an epistemic problem.

Links: → Headroom: github.com/chopratejas/he… → PixelRAG: github.com/StarTrail-org/…

Two packages worth bookmarking this week: Headroom sits between your agent and your LLM and compresses everything going in: tool outputs, RAG chunks, logs etc. before it hits the context window. 60–95% fewer tokens, same answers. PixelRAG renders pages as screenshot tiles instead of parsing the HTML. Traditional scrapers miss anything behind a JS component but PixelRAG sees what the browser sees. Beats text-based RAG by 18% on QA benchmarks including on text-only questions.

@akshay_pachaar This is a really interesting approach to getting around traditional scrapers not being able to see things rendered in JavaScript components. I assume there’s still some issues with dynamic / personalised pages but still closes a big gap.

Claude Code creator: "Loops are as big a step as move from source code to agents. Loops - step from agents to the next thing. 30% of my code is fully written by loops right now." in a 40-minute fireside chat, Boris Cherny reveals his actual working setup. Loops + dynamic workflows + routines, and more. Watch the full episode, then read the article on loop engineering below.

Codez @0xCodez

3 weeks ago

x.com/i/article/2064…

129 1K 7K 8.0M 21K

Steps 1–7 are learnable. Step 8 (MLOps) is where people actually stall. Not because it's harder but because you're suddenly dealing with broken infra and silent failures instead of clean tutorials. Different skill entirely. It's also the biggest differentiator available to a junior AI engineer right now.

Everyone's racing to give their agent more tools and more autonomy. Half the bugs disappear when you remove both. Spent ages debugging unpredictable tool-calling behaviour. Ripped it out and replaced it with a linear graph flow and it was much more predictable. Still not perfect but at least debuggable. LLM autonomy is expensive to debug and hard to trust in production. If you can hardcode the path, hardcode it.

LangGraph has an incredibly useful interrupt_before parameter. It lets you pause the graph before a node executes and hand control back to a human. Practical use: before your agent calls an external API, deletes a record or sends an email it pauses and shows the human what's about to happen. This gives them the opportunity to approve or redirect. This is how you build agents that are actually safe to deploy. Not by making them smarter but by making them stoppable. Human-in-the-loop isn't a limitation.

@DanKornas Love that you've included CRAG here. Most content doesn't go beyond retrieval and summarisation but fact-checking loops are critical in production.

With LangGraph, a linear graph is just a fancy pipeline. Add conditional routing and the agent can decide what to do next: retry, escalate, call a different tool or exit. A useful pattern is to use a dedicated router node. Its only job is to inspect state and return the next destination. Simple but powerful.

Conditional edges in LangGraph are where most tutorials stop. They're also where most agents actually start being useful. A linear graph is just a fancy pipeline. Add conditional routing and the agent can decide: retry, escalate, call a different tool, or exit early. That's the difference between a demo and something you'd put in front of a user. One pattern that works: use a dedicated "router" node. Its only job is to inspect state and return the next destination. Keep it dumb. Keep it testable.

@LangChain @benchling @nlarusstone Interesting way to think about it. In software you read the spec, reason about it, predict the output. With LLMs you run experiments, observe behaviour, form hypotheses, test again ....

@mdancho84 Couldn't agree more. The resources.md alone is gold.

Most people building with LangGraph don't need a multi-agent setup. One well-structured graph with clear state and conditional routing handles most real-world agent tasks. Multi-agent gets suggested because it sounds more impressive. Not because the problem requires it. The complexity cost is real: more failure points, harder to trace, slower to debug. Before you add a second agent, ask: is this actually two different reasoning processes, or just one process with more steps? Usually it's the second one.