---
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