## Evals zijn functies, geen producten Ik ben vanavond op deze coding agents meetup met OAI, Any, GDM, Cursor, Factory, Delphi, Exa, @theo enz. Een verrassende conclusie van dit panel, als ik misschien zo vrij mag zijn om te parafraseren, was dat theo zei dat er te veel evals startups zijn en thariq, nate en romain allemaal verrassend instemden dat ja, je moet doorgaan met het bouwen van meer agents, maak je geen zorgen over de biglab agents, zij zijn ook in wezen kleine interne startups, en je zult waarschijnlijk een andere kijk hebben en de wereld moet het zien. DAN en alleen DAN zul je goede evals bouwen.

er zijn een heleboel "houd het simpel, dommerik" agent engineering meningen die rondgaan en het in wezen reduceren tot "agent = llm + tools + loop + doel" dit is een minimaal levensvatbare agent, en dat is geweldig! maar de reden dat deze definitie te minimalistisch is om nuttig te zijn, is omdat het je doet vergeten wat agents GOED maakt: - planning - geheugen - vertrouwen/auth - evaluaties* in februari heb ik alle reacties op Simon's verzoeken om definities onderzocht en ze al voor je geclusterd. met bonus acroniem om TE STOPPEN MET HET VERGETEN VAN GEHEUGEN EN PLANNING EN AUTH STROOM "agent = llm + Intent + Geheugen + Planning + Auth/vertrouwen + Controle stroom + Tool gebruik" *aha! je dacht dat ik meneer haat evaluaties ben? omdat je alleen in binaire termen denkt?

het is een beetje ironisch dat we het MxN -> M+N probleem hebben opgelost met MCP en dat het volgende dat iedereen nu doet, het lanceren van hun eigen MCP-registers is (ik tel er momenteel minstens 6) babel weende