Enginyeria de context: per què sobreviurà al Marketplace d'agents

Les tres capes — i quines es commoditzen

Qualsevol sistema d'IA empresarial viu en tres capes. Fins ara parlàvem de les tres com si fossin el mateix, barrejades en el discurs comercial. La consolidació d'abril obliga a separar-les.

Per què la capa de context no es ven al Marketplace

Tres raons operatives, no filosòfiques:

1. És propietat del client per definició. Les dades curades són les teves dades. Les relacions documentades són el teu coneixement del domini. Les instruccions operatives són les teves polítiques. Un Marketplace pot vendre plantilles, exemples, frameworks — no pot vendre l'específic de la teva empresa, perquè no el té. Si t'ofereixen un agent «ja entrenat amb el context del teu sector», o (a) t'estan venent un genèric que hauràs de personalitzar igualment, o (b) t'estan venent el context d'un competidor del qual es van endur dades en un projecte anterior, cosa que és problema legal abans que tècnic.

2. No és estandarditzable. La diferència entre dues empreses que venen assegurances és exactament el que cadascuna considera «client premium»: el llindar, els criteris, les excepcions, les polítiques de retenció. Aquesta definició no és en cap manual sectorial. És en com opera concretament la teva empresa. Un agent pre-built amb un context estandarditzat pot cobrir el 20% genèric — el 80% que decideix la teva rendibilitat continua sent teu. I construir aquest 80% és enginyeria, no configuració.

3. Requereix disciplina enginyeril específica. Aquesta és la part on context engineering ≠ prompt engineering, ni data engineering, ni MLOps. Hi ha decisions tècniques concretes — quina informació es reté, quan expira, què es porta sota demanda, què es deixa fora deliberadament, què s'invalida quan canvia el negoci — que tenen impacte operatiu directe (latència, cost cloud) i de negoci (quines decisions automatitzades són possibles). Aquestes decisions són una disciplina d'enginyeria pròpia, amb els seus propis anti-patrons, el seu propi cost d'error, la seva pròpia corba d'aprenentatge.

A aquesta disciplina l'anomenem enginyeria de context. La desenvolupem com a concepte en una altra peça; aquí toca la seva arquitectura. A continuació hi ha com es dissenya.

Les 5 capes de l'enginyeria de context

Quan algú diu «context engineering», normalment està pensant en RAG. RAG és una tècnica dins de la capa 4. L'enginyeria de context, vista com a arquitectura, té cinc capes, i dissenyar les cinc explícitament és el que separa un agent que funciona en producció d'un que es queda en pilot.

Capa 1: instruccions curades

Són les polítiques operatives codificades en llenguatge natural — l'equivalent al manual de l'empleat. Què fa, què no fa, quin to fa servir, quins casos escala, quines decisions no pren mai sense humà. No és el system prompt gran. És un cos curat, versionat, amb responsable de manteniment, amb procés de canvi.

La diferència operativa: quan el legal canvia una política de retenció de dades, saps exactament quin document del cos curat actualitzar i quins tests passar abans del redeploy. Sense això, les polítiques viuen al system prompt com un sol bloc irrevisable, i cada canvi trenca tres coses que ningú havia provat.

Capa 2: memòria de treball

És el context de la sessió actual — el que l'agent recorda dins d'una conversa. Acotada per torns o per minuts, no per mesos. És la capa que decideix quan l'agent «oblida» el que li acabes de dir fa quatre missatges.

Mal dissenyada, aquesta capa o dispara la factura (tot l'historial a cada crida) o perd informació crítica (resum agressiu que llença la dada que importa). Ben dissenyada, té política explícita de què es manté literal, què es resumeix, què es descarta — i aquesta política és revisable.

Capa 3: memòria episòdica

És el context entre sessions — el que l'agent recorda d'interaccions passades amb el mateix client, el mateix projecte, el mateix dossier. Dies, setmanes, mesos.

Aquí és on més empreses s'equivoquen: o no la implementen (cada conversa arrenca de zero, frustrant l'usuari) o la implementen sense TTL ni invalidació (l'agent segueix fent servir informació desactualitzada de fa sis mesos). La política de retenció i invalidació és el cor d'aquesta capa.

Capa 4: retrieval policy

És la política de «què es porta al context quan es necessita» — sobre quin corpus, amb quin criteri de rellevància, amb quin límit. Aquí viu RAG, però RAG és una implementació, no una política.

La política decideix preguntes reals: es porta el document més recent, el més rellevant semànticament, o tots dos amb un pes? Es prioritza un document signat sobre un draft? Què es fa quan hi ha contradicció entre dues fonts? Sense política explícita, RAG funciona els primers tres mesos i comença a fallar quan el corpus creix i la cadència d'actualització canvia.

Capa 5: invalidació i expiració

És la política de quan el context deixa de ser vàlid. La capa més oblidada i la que més errors en producció provoca.

Una política de client va canviar al març: l'agent segueix citant la versió de desembre? Un producte va ser retirat del catàleg: l'agent segueix oferint-lo? Un empleat va sortir de l'empresa: l'agent segueix esmentant-lo com a contacte?

Aquesta capa requereix TTL explícit per tipus d'informació, mecanisme d'invalidació sota demanda (push) quan alguna cosa canvia, i auditoria de què s'està servint en producció. Sense aquesta capa, tota la resta de la feina es degrada amb el temps de manera silenciosa.

El contracte de cost per petició

Les cinc capes anteriors estan connectades per una decisió que determina si la teva factura cloud creix linealment amb l'ús o explota: quina capa paga què, amb quin límit per petició.

Una petició típica a un agent ben dissenyat activa: una porció d'instruccions curades (capa 1), l'extracte rellevant de memòria de treball (capa 2), una porció acotada de memòria episòdica (capa 3), un o dos documents recuperats (capa 4), tot sota polítiques de TTL (capa 5).

La matemàtica que espanta el CFO: si cada capa pot consumir 10.000 tokens, una petició pot arribar fàcilment a 50.000 tokens — i a 50.000 peticions per dia són 2.500 milions de tokens diaris. Multiplicat pel preu del model, són xifres que apareixen al comitè de Q3 amb un signe d'exclamació.

El contracte de cost obliga a decidir, abans d'implementar: quant pot consumir cada capa per petició, quan es prefereix truncar a portar més, quan es prefereix baixar a un model més barat a canvi de més context. Aquestes decisions es prenen en dissenyar l'arquitectura — no es descobreixen quan arriba la factura. És l'angle que desenvolupem en el cost real d'IA en producció: la diferència entre pilot i escala no és lineal.

Tres anti-patrons que veiem recurrentment

Com s'introdueix en un brownfield

No cal llençar res. Pla de migració en quatre setmanes, executable sense parar producció.

A les quatre setmanes: agent amb arquitectura documentada, factura predictible i capacitat real d'iterar. No és el destí final — és el punt des del qual es pot construir.

El que el Marketplace no pot comprar

Quan el comitè de direcció rebi la proposta de l'integrador amb el catàleg de 1.000+ agents pre-built, la pregunta correcta no és «aquest agent cobreix el nostre cas?». És: «si comprem aquest agent, qui construirà les cinc capes de context sobre les nostres dades? Amb quina metodologia? Qui és propietari de la capa de context a l'any 3?».

Si les respostes són «l'integrador, la seva metodologia, ells en són propietaris», el que estàs comprant no és un agent. És una dependència.

El que el Marketplace ven — models cognitius accessibles, plans de control estandarditzats, agents pre-built — és valuós i barat. El que el Marketplace no pot vendre és el context específic de la teva empresa dissenyat amb disciplina arquitectònica. I això és el 80% de la feina i el 100% de la diferenciació.

Si el teu pròxim RFP d'IA t'ajuda a separar l'un de l'altre, ja tenim el següent pas publicat: Enginyeria de context: 7 preguntes per al teu RFP d'IA — el brief del comprador que aplica aquest criteri a la taula d'avaluació.