romfast/echo-core
2
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
Files
553a137206e1d5f24ab8b4a3f3af087aaa29247a
echo-core/memory/kb/youtube/2026-09-10_agent-context-prin-sql.md
Marius Mutu 553a137206 chore(kb): note noi (youtube, facebook, fișe grup sprijin, email) + tool scout_voluntar_check 
Reindexare KB, timestamps cron/habits actualizate din rulările automate.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
2026-09-10 08:53:49 +00:00

2.4 KiB
Raw Blame History

title: "Why your agent should manage it's context through SQL" url: https://youtu.be/uMudSbZ79-A date: 2026-09-10 tags: [@work, insights]

TL;DR

Lewis Ellis (Conductor, ex-YC) argumentează că a da unui agent AI acces direct la SQL (pe un read replica, cu limite) bate abordările clasice (RAG/vector search, MCP-uri multiple, embeddings): un singur tool (SQL) face ce făceau înainte 20 de tool-uri diferite. Agenții scriu SQL mai bine decât oamenii pentru că "brute-forcează" fără să obosească (join-uri complicate, WHERE cu 12 condiții, citesc 100 de rânduri ca să înțeleagă schema) — lucruri pe care oamenii nu au răbdare să le facă. Siguranța se obține exact ca la echipele de data science: read replica, rol read-only, timeout-uri mici, limite pe numărul de rânduri/dimensiunea rezultatului, audit log, și views limitate (scope automat per tenant) în loc de acces "arbitrary SQL" real.

Idei cheie

  • Un tool SQL bine limitat (read replica + read-only role + timeouts + row limits + audit log) e mai simplu și mai eficient decât o grămadă de MCP-uri/tool-uri specializate.
  • Views = "skill-uri SQL native": când agentul repetă mereu același join complicat, definești un view — de la 10-20 tool call-uri la unul singur.
  • Rezultatele SQL ca CSV (nu JSON) înjumătățesc tokenii consumați per query.
  • Orice sursă externă (Slack, alte API-uri cu rate-limit) poate fi oglindită într-o bază de date locală ca agentul să nu mai lovească limitele providerului — "owning your context" = pune totul într-o bază de date pe care o controlezi.
  • Erorile de query nu sunt o problemă — le dai înapoi agentului, se auto-corectează; frecvența erorilor îți arată unde lipsește context sau unde ai nevoie de un view nou.
  • Praguri practic: schema + semantica coloanelor undeva la ~100k tokeni ca punct de plecare rezonabil; dacă schema depășește contextul, faci views curate și separi agenții pe seturi de tabele.

Relevanță pentru Echo/Marius

Nu e ceva de aplicat acum — ROA folosește Oracle, nu un flow agentic peste bază de date live. Dar tiparul e relevant conceptual pentru orice viitor agent care ar interoga direct Oracle/SQLite (de ex. extindere la roa2web sau dashboard): rol read-only + view-uri curate + limite, în loc de RAG sau MCP-uri multiple, dacă vreodată apare nevoia ca un agent să interogheze liber date de business.

Linkuri: https://youtu.be/uMudSbZ79-A