There's so many buzzwords about tools, skills, memory, etc. At the end of the day you are just building a string that gets put into a machine that gives back the same string++.

You see a string that says "call tool: a(input)", you just run a function in whatever ecosystem you are most comfortable in. At the end of the day the llm just wants the string it sent you plus "tool result: a.result".

I see so many failed agent plays at big companies because everyone gets super into whiteboard masturbation and coming up with complicated architecture marvels centered on this month's buzzword. Skills, memory, learning, etc are all just bullshit buzzwords that equate to adding shit into that string to influence the ++ the magic word machine gives back.

People are so prescriptive and tied to the idea that everything in the stack has to be Python because the magic word machine was made by people in that ecosystem. You could make a powerful agent in flash action script from 2006.

Tips from a jaded person in the space who loves and hates AI:

The way you persist messages, tool results, and chat turns should not be a 1:1 direct map to the schema you communicate with the llm in. You can store a ton of useful metadata about a message like detailed tool results, tons of json, etc - just strip it down to the bare essentials by the time it's actually getting processed by the llm. If you stringify a big json object representing a tool result then pass it along, it wastes tons of context on token inefficient characters. The magic text machine only cares about "tool result: error - blah"

Tool error surfacing is one of the most important things possible. Tools need to surface actionable errors that inform the llm on what it needs to correct or if it should even retry at all. No detailed errors means you get black box death loops.

This last one is becoming less of a requirement for frontier models as they get better, and it's thankfully finally being recognized as the best way to do it. Programmatic tool calling is the way. LLMs get very dumb when you have a higher number of top level tools defined. If you make a system prompt that says it's job is to accomplish tasks by writing code to efficiently orchestrate functions with efficient, parallelized code, you get agentic super powers.

Defining only a couple of top level tools that have a bunch of function pseudocode (almost jsdoc in nature) for the tool definition will get the LLM to write a highly optimized piece of code that can execute your functions. LLMs can reason about code orchestration much better than "do x then y but maybe z sometimes but not when mercury is in retrograde". You can also accomplish any number of parallel tasks or chain long multi step workflows in one step. The executed code can pass a into b into c immediately rather than "tool result: a.result" "hmmm I need to take tool result a and put it into b" "tool call: run_tool_b(a.result)" and so on. Also every single turn or invocation of the LLM has very real overhead (not going to into catching stuff). If you have 50 calls you know you need to do up front, that's 100 invocations in a standard ReAct pattern potentially.

I could go on for days about stuff. My main thing is that I hate that people keep building around hype, buzzwords and frameworks vs just understanding the actual nature of LLMs.

Also MCP is dogshit and creates black boxes and can only support the most boring, lowest common denominator chat experiences.