Enduring Relevance of the Original Article
Multiple users emphasize the lasting value and insightful nature of the original "Building Effective AI Agents" article. "Yes, but it's held up really well in my opinion! I use this piece constantly as a reference and I don't feel it's aged. It reframed Anthropic as 'the practical partner' in the development of AI tools," says "nahsra". "simonw" calls it "one of the better pieces on this topic, especially since it clearly defines which definition of 'AI agents' they are using at the start!" and further highlights the distinction between "agents" and "workflows" in the article.
The "Just Write It" Approach vs. Frameworks and Libraries
A significant theme revolves around the debate between using pre-built frameworks and libraries versus directly coding agent logic. "rockwotj" suggests, "Just write the for loop to react to tool calls? It’s not very much code." However, "koakuma-chan" counters that complex agent behaviors such as hand-offs and concurrent tool calls might necessitate creating a framework anyway: "You could write that yourself, but you would be inventing your own framework."
This sentiment extends to a discussion about LLM abstraction libraries versus frameworks. "miki123211" advocates for using a library like litellm to abstract over different LLMs. However, "XenophileJKO," arguing from experience with "systems serving massive user bases with LLMs," believes that "the ability to swap out APIs just isn't the bottleneck... like ever. It is always the behavioral issues or capability differences between models. The frameworks just usually add more complexity, obscurity, and API misalignment." "XenophileJKO" concludes: "So by default to get your V0 product off the ground (if you are not a complete startup), just use the API. That is my advice."
Orchestration and Multi-Agent Systems
Several users discuss the orchestration of agents, especially regarding tool calls and concurrency. "simonw" mentions that "Several models support parallel tool calls now where the model can say 'Run these three tools' and your harness can chose to run them in parallel or sequentially before passing the results back to the model." "ankit219" describes Anthropic's approach, noting that "it's one main LLM (you are sending query to - orchestrator) which calls other LLMs via tool calls. The tools are capable of calling llms too, and can have specific instructions, but mostly just the orchestrator deciding what they should be researching on, and assigns them specific subqueries."
"AvAn12" raises concerns about concurrency issues, asking, "How do agents deal with task queueing, race conditions, and other issues arising from concurrency?" "cmsparks" suggests that "the actor model maps really well onto building agents. An instance of an actor = an instance of an agent. Agent to agent communication is just tool calling (via MCP or some other RPC)."
"Agents" vs. "Workflows": A Question of Definition and Structure
The discussion touches upon the distinction between agents and workflows, challenging whether the definitions provided in the original article remain relevant. "kodablah" states: "I believe the definition of workflows in this article is inaccurate. Workflows in modern engines do not take predefined code paths, and agents are effectively the same as workflows in these cases."
However, "sothatsit" argues that the difference lies in the level of structure: "Workflows have a lot more structure and rules about information and control flow. Agents, on the other hand, are often given a set of tools and a prompt. They are much more free-form." "simonw" criticizes "kodablah" for assuming a specific definition of "workflow" tied to software like Airflow, noting that Anthropic is free to define the word in their own context and offers up a generic definition for reference.
As "gregorymichael" succinctly puts it, "One of my favorite AI How-tos in the last year. Barry and Erik spend 80% of the post saying ~”eh, you probably don’t need agents. Just build straightforward deterministic workflows with if-statements instead.”"
Centralized vs. Decentralized Architectures for Agents
A thought-provoking segment delves into the potential of decentralized architectures for AI agents, contrasting them with centralized platforms. "pyman" asks, "Should the people developing AI agent protocols be exploring decentralised architectures, using technologies like blockchain and peer-to-peer networks to distribute models and data? What are the trade-offs of relying on centralised orchestration platforms owned by large companies like Amazon, Cloudfare or NVIDIA?"
"daxfohl" argues that centralized systems are generally preferable for corporations due to "efficiency," "control," and ease of use. However, "daxfohl" concedes that decentralized solutions could offer individuals "more control and transparency," particularly in verifying agent interactions. "pyman" counters that as agents become more autonomous and coordinate across platforms, a "shared, trustless layer" might become necessary. "If agents become more autonomous and start coordinating across platforms owned by different companies, it might make sense to have some kind of shared, trustless layer (maybe not blockchain but something distributed, auditable and neutral)."
LLM Tool Calling Reliability and Methods
The reliability of LLMs in generating correct tool calls is also discussed. "svachalek" states, "I'm not sure we're at 'great' yet. Gemini 2.5 pro fails maybe 50% of the time for me at even generating a syntactically successful tool call." "simonw" asks if "svachalek" is using Gemini's native tool calling mechanisms or prompting the model with specific formats. "mediaman" asks for recommendations, stating "I've actually had good luck having them create XML, even though you're 'supposed' to use the native tool calling in a JSON schema. There seems to be far fewer issues with getting JSON syntax correct." "simonw" recommends using the native tool calling and provides a link to a GitHub commit showcasing its implementation.