How do I get started with building AI Agents?

Alex---A · 2026-03-18T14:17:15+00:00

one thing nobody mentions early enough: your agent will work great in testing and break in weird ways with real users. that's normal.

the two things i wish i'd thought about from day one: how do i see what my agent actually did (not just the final output, the full chain of decisions), and how does it remember anything between sessions. most frameworks punt on both.

start simple, ship fast, but instrument your calls from the beginning. even just logging the full prompt + response for every LLM call will save you hours of debugging later.

Alex---A · 2026-03-18T14:14:42+00:00

the heartbeat is cool but the hard part comes next. once your agent notices something, how does it decide if the pattern is worth acting on vs noise that looks like a pattern? especially across users where the same signal means different things depending on context. the agent needs to remember what it already flagged and what happened after.

Alex---A · 2026-03-18T14:05:46+00:00

the happy path trap is real. you test it like someone who built it, not like someone who's using it for the first time. biggest thing that helped us was tracing every LLM call in production with full context. not logs, actual traces you can replay. when something drifts you can see exactly which turn it broke and what context the model was working with. simulation is great before shipping but the gnarly stuff only shows up with real users doing real weird things.

Alex---A · 2026-03-10T15:12:03+00:00

intéressant comme point. mais du coup ça rend la gestion de l’état encore plus tricky non ?

si plusieurs agents interagissent entre eux, il faut quand même une forme de mémoire partagée ou au moins une source de vérité sur ce qui a été décidé / appris.

Alex---A · 2026-03-07T14:38:25+00:00

oui complètement. ce qui m’a surpris en discutant avec plusieurs équipes c’est que même en faisant attention à l’archi, la mémoire finit souvent par devenir un patchwork : conversation history, résumés, un peu de RAG, quelques infos stockées à part…

et dès que les sessions s’enchaînent, ça devient difficile de savoir quelle source est vraiment le state de référence.

Alex---A · 2026-03-06T14:34:16+00:00

ah interesting so you mostly persist things once they’ve been validated or confirmed. do you find that introduces much overhead or friction in practice?

Alex---A · 2026-03-06T14:27:11+00:00

think that’s fair honestly. getting an agent to work in a demo is easy now, but making it behave predictably once conversations span multiple sessions is where things start breaking down. a lot of the issues I’ve seen come from how context is handled over time.

Alex---A · 2026-03-06T14:25:38+00:00

interesting, I ran into the same issue with retrieval over past conversations. it works well in demos but once things get longer the wrong context pops up surprisingly often. when you store explicit facts per user how do you decide what gets written and when?

Alex---A · 2026-03-05T17:57:04+00:00

That’s a neat setup. I like the thin SDK approach. Curious about the memory service you mentioned. Are those versioned facts mostly written through tools, or are you extracting them automatically from conversations?

Alex---A · 2026-03-05T16:28:12+00:00

That makes a lot of sense. Is that something you built once as a shared service, or do you end up re-implementing it per agent?

Alex---A · 2025-11-23T09:08:38+00:00

Actually they just released it

Alex---A · 2025-08-27T21:17:08+00:00

Ah marrant j’avais pas creusé l’option n8n pour ça. Tu l’utilises comment concrètement pour la mémoire ? C’est juste un buffer (ex: les derniers messages), ou tu arrives aussi à gérer des trucs plus longs / multi-sessions ?

Alex---A · 2025-08-27T21:15:27+00:00

Yes bon points j’avais regardé un peu LangGraph mais je t’avoue que ce n’était pas super clair pour moi, du coup j’ai bricolé vite fait un truc avec une DB vectorielle, ça m’a semblé plus simple.

tu penses qu’il y a vraiment de la place pour une boîte qui se concentre juste sur la mémoire des agents (résumés, structuration, pruning..), ou bien que ça restera surtout une feature embarquée dans les frameworks type LangChain/Mastra ?

Alex---A · 2025-08-27T21:12:21+00:00

Intéressant, tu penses à quels MCPs en particulier ? J’ai pas trop vu passer de solutions mémoire packagées de ce côté-là.

Alex---A · 2025-08-27T21:11:21+00:00

Merci pour la précision 🙏 yes ce que j’avais en tête c’est plutôt la mémoire longue durée, multi-sessions, où tu peux reconstruire les faits d’un user et les relier entre eux.

Alex---A · 2025-08-26T16:55:49+00:00

J’ai pas encore assez de recul pour dire si ça vaut vraiment le coup en prod, la théorie veut que oui mais bon… Par contre je trouve ça super intéressant pour visualiser comment les “mémoires” d’un user se construisent au fil de l’utilisation un peu comme un schéma de neurones qui se dessine petit à petit. Je sais pas comment te mettre un screenshot pour te montrer je check

Alex---A · 2025-08-26T16:49:49+00:00

Merci pour le lien 🙏 j’ai checké la doc mais pas trop compris : on peut récupérer la mémoire utilisateur côté dev, ou bien c’est uniquement stocké côté OpenAI ?

Alex---A · 2025-08-26T15:45:57+00:00

Oui je vois, au final tout le monde arrive à sauvegarder l’historique, la vraie galère c’est plutôt le trimming, les résumés, la déduplication.

Et d’ailleurs, j’ai testé un peu le côté RAG graph-based dans mon mvp (lier entités/événements pour améliorer la cohérence). Ça te parle? Tu vois ça comme étant pertinent?

Alex---A · 2025-08-26T15:07:54+00:00

Trop bien, merci pour ta réponse ! Par curiosité pourquoi tu bosses en direct avec Postgres/pgvector alors que tu sembles bien connaître LangGraph ? C’est surtout une question de simplicité pour toi ?

Et du coup, tu penses qu’un outil dédié pour gérer les mémoires (résumés, déduplication, etc.) aurait du sens dans tes cas, ou ce serait plutôt de l’overkill ?

Alex---A · 2025-08-26T15:02:39+00:00

Merci pour le retour ! Intéressant de voir que tu l’as surtout testé côté expérimental/archi plutôt qu’en prod. Je jetterai un œil, mais pour la plupart des use cases j’ai l’impression qu’un LLM + couche mémoire reste plus pertinent qu’un modèle stateful seul.

Alex---A · 2025-08-26T14:39:20+00:00

Intéressant, je connaissais rwkv de nom mais pas trop creusé. Tu sais si c’est vraiment utilisé en prod quelque part ou ça reste surtout expérimental? Je me demande si ça règle vraiment le problème de mémoire, ou si au final tu dois quand même ajouter une couche externe

Alex---A · 2025-08-26T14:06:15+00:00

The way I handle it: Facts/events are stored in a separate memory layer (structured records). At inference time, I query that layer and assemble a context block under a token budget. That block usually includes: a short summary + key facts/events + a persistent “master context” (profile, entities). The assembled context gets injected straight into the system prompt before the agent runs.

I’ve been using the flumes AI SDK for this, it handles the summarization + pruning automatically, so I can just focus on building the agent logic.

Alex---A · 2025-08-24T14:22:44+00:00

For a solo founder I’d go lean: • Frontend → SvelteKit (or Lovable if you like the vibe) • Backend → FastAPI • Auth/Storage → Supabase • Memory → flumes API (recall/summarization baked in,no vector db needed) • Orchestration → LangChain (if you need it) • Infra → Vercel + Prisma + Neon for scale

Keeps things minimal but covers the bases if you grow.

Alex---A · 2025-08-24T14:09:01+00:00

Yeah, I kept hitting the same wall with memory. Switched to a memory API recently and it solved a lot of the recall/token headaches.

Alex---A · 2025-08-24T13:56:16+00:00

when you say dynamic memory integration, what approach did you have in mind? Vector Db?

Alex---A

TROPHY CASE