Per l'equip de Kiwop · Agència Digital especialitzada en Desenvolupament de Programari i Intel·ligència Artificial aplicada per a clients globals a Europa i EUA · Publicat el 20 d'abril de 2026 · Última actualització: 20 d'abril de 2026
TL;DR — Una arquitectura API-First dissenya el sistema des dels seus contractes màquina-llegibles abans que des de qualsevol interfície humana. Quan el consumidor principal deixa de ser un navegador i passa a ser un agent IA, això separa els productes que sobreviuen dels que no. Aquesta guia recull els sis principis, els patrons que funcionen, els quatre antipatrons que maten l'adopció i el cas real de Nexo — el nostre SaaS que exposa MCP com a contracte natiu.
Cada setmana arriba la mateixa trucada des d'un comitè tècnic: "Volem obrir el nostre producte a agents IA, però el nostre backend es va dissenyar per a una SPA". La resposta honesta mai no és "munteu un endpoint REST i ja està". La resposta correcta comença per una pregunta: la vostra arquitectura està pensada perquè el consumidor principal sigui una màquina, o perquè sigui un humà amb ratolí? Si és això segon, cada nou agent que connecteu pagarà l'impost del mismatch — latència, scraping fràgil, reintents mal gestionats, comptes compartits entre humans i bots. API-First no és un estil de codi; és la decisió arquitectònica que elimina aquest impost des del primer dia.
Què és l'arquitectura API-First (definició operativa)
Una arquitectura API-First és aquella en què cada contracte màquina-llegible — la seva forma, la seva versió, la seva autenticació, la seva observabilitat — es dissenya i es valida abans que qualsevol interfície d'usuari que el consumeixi. El backend no exposa "el que la SPA necessita avui"; exposa un contracte públic, tipat, versionat, documentat i descobrible, del qual qualsevol client (web, mòbil, tercers, agents IA) consumeix allò que l'interessa.
La distinció clau no és tècnica sinó de seqüència. En API-First, el contracte és l'artefacte primari — es revisa en PR, es publica com a OpenAPI o AsyncAPI, es versiona com a llibreria independent. La UI ve després i l'agent ve després. Tots són clients del mateix primer ciutadà.
API-First vs API-Design-First vs Code-First
Tres termes que es fan servir intercanviablement però signifiquen coses diferents:
- Code-First: el codi va primer. El contracte (OpenAPI, gRPC, GraphQL schema) es genera a partir del codi. Ràpid per començar, car per mantenir. El contracte queda sempre un pas enrere.
- API-Design-First: el contracte es dissenya com a document humà-llegible abans d'escriure codi. Útil per coordinar equips grans, però no garanteix que el consumidor principal sigui una màquina.
- API-First: el contracte màquina-llegible és l'artefacte primer, últim i sempre. Es dissenya com a producte amb el seu propi roadmap, SLA, changelog i suport. La UI és un client més.
La nostra recomanació per a qualsevol plataforma que vulgui exposar-se a agents IA: API-First amb API-Design-First com a ritual d'equip. El contracte viu al seu propi repo o package, es revisa en PR, es publica versionat semànticament.
Per què amb agents IA l'API ÉS la UI
Històricament la UI era el producte i l'API era un extra. Les empreses invertien en disseny d'interacció, proves A/B de botons, fluxos d'onboarding visual. L'API existia com a backdoor per a integracions o SDK, però el pressupost de producte era a la pantalla.
Amb agents IA aquesta jerarquia s'inverteix. Un agent no veu la teva capçalera, no clica el teu CTA, no aprecia la teva animació de loading. L'únic que veu és el contracte — i si el contracte és ambigu, està mal versionat o té endpoints que tornen HTML quan havien de tornar JSON, l'agent falla silenciosament o pitjor, inventa respostes.
L'API ja no és un backdoor. És la front door. Tot el pressupost de producte que abans anava a polir la UI, ara ha d'anar a polir el contracte: noms de camps clars, exemples a la documentació, errors estructurats, paginació consistent, idempotència explícita. Un producte amb una API dolenta però bona UI encara es podia vendre a humans. Un producte amb una API dolenta en un món d'agents no arriba a la primera integració.
Per què els agents IA trenquen el paradigma UI-first
Els agents no naveguen, invoquen contractes tipats
Un humà navegant descobreix el teu producte pel flux: entra pel home, llegeix una feature, clica a "començar", omple un formulari, confirma per correu. Cada pas li dona context per al següent.
Un agent IA fa exactament el contrari: parteix d'una intenció concreta ("reserva una reunió amb la Marta dijous"), enumera les eines disponibles, tria la que millor encaixa, construeix els paràmetres i crida. No hi ha flux. Hi ha invocació directa. Això significa que cada endpoint ha de ser autocontingut: la seva descripció a OpenAPI ha de ser suficient perquè un model entengui què fa, quan fer-lo servir i amb quins paràmetres, sense haver vist cap pantalla prèvia.
La conseqüència arquitectònica és brutal. Endpoints que en una SPA formaven part d'un flux guiat ("primer POST /cart, després POST /cart/items, després POST /checkout") s'han de repensar o documentar explícitament com a seqüència, amb errors que deixin clar el pas següent. Els "passos implícits" que l'humà feia mentalment, ara els ha de fer el protocol.
El cost real del scraping vs l'API ben dissenyada
La temptació és òbvia: ja que el lloc web existeix i funciona, per què construir una API nova? Posem un browser-use o un puppeteer al davant i que l'agent faci clics. És barat, ràpid, no requereix tocar el backend. És també la decisió que destrueix projectes.
El scraping-as-backend té tres costos que no apareixen fins mesos després. Primer, és fràgil: qualsevol canvi al DOM trenca l'agent, i com que l'equip de frontend no sap que hi ha agents depenent del DOM, els canvis són constants. Segon, és lent: un tool call contra una API ben dissenyada es resol en 200-400 ms; el mateix pas via browser triga 8-15 segons carregant CSS, JS i esperant que els selectors apareguin. Tercer, és car: executar un navegador headless per petició multiplica per 20-50 el cost d'infraestructura respecte a servir JSON.
Una API dissenyada per a agents costa més en fase de disseny, però s'amortitza a la primera integració real. Les empreses que arriben a Kiwop amb un any de "solució temporal" amb scraping arriben sempre amb el mateix símptoma: el cost de manteniment ha igualat el cost estimat de construir l'API bé des del principi.
El pivot de Salesforce després de gairebé tres dècades
El febrer de 2026, Marc Benioff, CEO de Salesforce, ho va dir sense embuts: "APIs are the new UI". Vint-i-set anys després de fundar una companyia que va definir què era "el SaaS", Salesforce reconeix públicament que el navegador ja no és el punt de contacte principal del seu producte. El seu focus es desplaça a que els agents IA consumeixin directament les seves dades, els seus workflows, les seves tasks — via API.
No és una declaració disruptiva, és una confirmació tardana. Les empreses que construeixen plataformes noves avui ja assumeixen que la primera integració real serà amb un agent, no amb un humà. El moviment de Salesforce és el senyal que fins i tot les incumbents més grans estan acceptant la mateixa realitat. Si el 2028 un producte SaaS encara té la seva millor DX darrere del navegador, és perquè arribarà tard al cicle.
Els sis principis d'una API-First llesta per a agents
1. Contractes versionats amb OpenAPI 3.1+
Tota API-First comença per un contracte OpenAPI 3.1 (o AsyncAPI 3 per a l'event-driven) publicat com a artefacte versionat semànticament. No com a PDF generat al final del sprint. No com a fitxer flotant a Confluence. Com a package publicat amb changelog, que qualsevol consumidor pot fixar en una versió concreta i actualitzar amb intenció.
La versió va a l'URL (/v2/...) o al header (Accept-Version); tant és el mecanisme mentre sigui explícit i el servidor pugui servir dues versions en paral·lel durant la deprecation window. Per a agents IA això és crític: un model après sobre la v1 de la teva API no s'ha de trencar perquè hagis afegit un camp a la v2.
2. Idempotència per defecte
Els agents reintenten. Molt. Per timeouts, per saturació de context, per polítiques de retry del propi harness. Una API-First assumeix idempotència com a contracte: tot POST que genera efecte col·lateral accepta una capçalera Idempotency-Key (UUID generat pel client) i garanteix que dues crides amb la mateixa key produeixen un sol efecte.
La regla s'estén als PATCH, DELETE i operacions costoses. Sense idempotència, el primer timeout de xarxa crea una comanda duplicada, un correu enviat dues vegades o una reserva duplicada. Amb idempotència, l'agent pot reintentar amb tranquil·litat i la teva lògica de negoci no depèn de la sort.
3. Observabilitat granular: qui, què, quan, a quin cost
Quan el trànsit principal deixa de ser humà, els dashboards clàssics ("usuaris actius") ja no representen res. El que importa és: quin agent ha cridat quina tool, amb quins paràmetres, quant ha trigat, quants tokens ha consumit al model que l'ha cridat, i si el resultat ha estat útil (l'agent ha reintentat o ha tirat endavant).
Les capçaleres User-Agent, X-Agent-Name, X-Model-Id ara són obligatòries, no opcionals. El logging estructurat inclou trace_id que es propaga des del LLM fins al backend final. I les mètriques per tool — p50, p95, p99 de latència, taxa d'error, taxa de retry — són l'equivalent nou dels KPI de producte.
4. Autenticació tipada: OAuth + scopes per agent
Cada agent que consumeix la teva API ha de tenir la seva pròpia identitat diferent de la de l'humà que l'ha autoritzat. Això s'implementa amb OAuth 2.1 + scopes granulars: l'humà delega al seu agent un subconjunt explícit de permisos (calendar.read, calendar.write:2026-05, files.read:project-x), i cada token queda traçable fins al parell (humà, agent, timestamp).
La conseqüència pràctica: dos agents del mateix humà són dues identitats diferents. Un pot ser revocat sense trencar l'altre. I els logs del backend poden respondre la pregunta que ningú no es feia fa dos anys — "quin agent de quin humà ha fet aquesta acció a les 3 de la matinada?".
5. Rate-limiting dual: per client i per capacitat
El rate-limiting clàssic (X peticions per minut per token) no funciona amb agents perquè un agent ben fet pot generar ràfegues legítimes de centenars de tool calls en segons per complir una tasca complexa. L'API ha de combinar dos límits: un límit per client (per protegir l'agent de bucles) i un límit per capacitat (per protegir el backend de la suma de tots els agents).
Els errors 429 Too Many Requests han d'incloure Retry-After i distingir clarament entre "torna-ho a intentar en 2 segons" i "aquesta operació està bloquejada per a tu durant 10 minuts per abús". Aquesta diferència és el que permet a l'agent raonar sobre com adaptar-se.
6. Descobribilitat: MCP + OpenAPI + docs autogenerades
Una API-First moderna hauria de ser descobrible per tres canals complementaris. OpenAPI publicat en un endpoint predictible (/.well-known/openapi.json) per al consum d'eines de dev i SDK. MCP server exposant les mateixes capacitats com a tools llestes per connectar amb Claude, ChatGPT o qualsevol agent que parli el protocol. I docs per a humans autogenerades a partir del mateix contracte, per quan el developer de l'altre costat necessita mirar amb ulls humans.
Els tres canals consumeixen el mateix contracte. Si la documentació i l'OpenAPI es desincronitzen, és perquè hi ha alguna cosa mal arquitectònicament — el contracte no és l'artefacte primari.
La capa específica per a agents — MCP, WebMCP, A2A
OpenAPI et dona la base, però perquè un agent consumeixi el teu producte amb fricció zero existeix una capa de protocols específica. MCP (Model Context Protocol) és l'estàndard per exposar tools a un agent que corre en un harness (Claude, ChatGPT, Cursor). WebMCP fa el mateix des del navegador, perquè la teva web pública exposi accions a l'agent de l'usuari. A2A (Agent-to-Agent) orquestra la comunicació entre agents, no entre agent i tools.
No competeixen amb OpenAPI: el complementen. En producció, OpenAPI és la veritat del backend; MCP i WebMCP són adaptadors fins que tradueixen aquest contracte al format que els harnesses esperen. Cobrim la comparativa tècnica i quan fer servir cadascun a MCP, WebMCP i A2A: quin protocol triar per als teus agents IA.
Patrons arquitectònics que funcionen
API Gateway + Service Mesh amb policy-as-code
Tota API-First seriosa passa per un gateway que aplica polítiques abans d'arribar al backend: autenticació, rate-limiting, observabilitat, enrichment de capçaleres, transformació entre versions. El nostre stack recomanat: Kong, Tyk o AWS API Gateway per al perímetre; Istio o Linkerd per al service mesh intern. Les polítiques es defineixen com a codi (YAML versionat a git), no com a clics a la consola del vendor.
La separació importa: el gateway es preocupa de "quin client pot cridar quin endpoint"; el mesh es preocupa de "quin servei pot parlar amb quin servei dins del cluster". Barrejar les dues responsabilitats és el camí més curt cap a una arquitectura que ningú no entén en sis mesos.
Backend-for-Frontend ≠ Backend-for-Agent
El patró BFF (Backend-for-Frontend) va néixer perquè cada UI (web, mòbil, smart TV) tingués el seu propi endpoint optimitzat. La temptació és aplicar-lo també als agents: construir un "BFA" (Backend-for-Agent) que agregui crides per minimitzar round-trips.
No ho facis sense pensar-t'ho dues vegades. Un agent no és una UI amb latència humana; és un client que raona. Si agregues massa, l'agent perd granularitat — no pot combinar tools com vol. Si agregues massa poc, malgasta context en calls innecessaris. La decisió correcta depèn del cas: les tools de lectura es poden beneficiar d'endpoints agregats (GET /dashboard que retorna usuari + permisos + últimes accions); les tools d'escriptura han de ser atòmiques i compositives (POST /bookings aïllat, sense side-effects ocults).
Event-driven amb Kafka, NATS o Redis Streams
Els agents disparen feines que triguen. Generar un informe, processar una comanda, entrenar un model — operacions de segons a minuts. Exposar-les com a REST síncron obliga l'agent a sostenir la connexió i consumir context esperant.
L'alternativa és event-driven: l'agent envia un POST /jobs que retorna un job_id en menys de 100 ms, després consulta l'estat via GET /jobs/{id} o se subscriu a un canal d'esdeveniments. Kafka o NATS per a volum alt; Redis Streams per a setups lleugers. El patró allibera l'agent de bloquejar-se i permet al teu backend absorbir pics sense caure.
CQRS per separar escriptura sorollosa (agents) de lectura crítica (humans)
Quan els agents passen a ser majoria del trànsit d'escriptura, els humans que llegeixen el mateix producte comencen a patir contenció: queries lentes, invalidacions de cache constants, dashboards que triguen a carregar. CQRS (Command Query Responsibility Segregation) separa el model que escriu del model que llegeix: els agents envien commands a una write-side optimitzada per a consistència; els humans consumeixen d'una read-side optimitzada per a lectura ràpida, alimentada per esdeveniments des de la write-side.
No és gratis — afegeix complexitat i eventual consistency. Però per sobre de cert volum de trànsit agent, és l'única manera de mantenir la UX humana intacta.
Antipatrons que maten la teva adopció per agents
Antipatró 1 — Exposem la UI amb cookies, "i ja està"
El primer reflex d'un equip apurat és delegar a un browser-use o Playwright les accions de l'agent. Funciona a la demo, falla en producció a la primera rotació del DOM. Qualsevol canvi visual del frontend (A/B test d'un botó, refactor de selectors) trenca l'agent silenciosament. El deute és invisible fins que és tard — moment en el qual el cost de reconstruir l'API "bé" és el triple.
Antipatró 2 — API sense versionat explícit
Tenir una API a /api/... sense prefix de versió funciona fins al primer canvi breaking. A partir d'aquí, tots els agents en producció es trenquen alhora. Els equips que aposten per "sempre backwards compatible" acaben acumulant 15 anys de deute al mateix endpoint. La disciplina correcta és versionat des del primer commit, amb deprecation windows documentades al changelog.
Antipatró 3 — Docs escrites només per a humans
Pàgines boniques a Mintlify o ReadMe amb gifs i tutorials són inútils per a un agent. L'agent consumeix OpenAPI cru, JSON Schema, tipus TypeScript o una descripció MCP. Si aquest artefacte màquina-llegible no existeix o està desactualitzat, l'agent inventa. La doc humana es genera del contracte; no al revés.
Antipatró 4 — Autenticació barrejada: sessió humana + token agent al mateix endpoint
Un error comú en equips que migren des de productes humans: reutilitzar la sessió de cookie de l'usuari perquè el seu agent cridi l'API "com si fos ell". Resultat: impossible distingir qui fa què als logs, impossible revocar un agent sense tombar la sessió humana, impossible limitar scopes diferents per origen.
La separació correcta: sessió humana amb cookie HttpOnly per a la UI; tokens OAuth amb scopes per als agents; cadascun amb el seu propi endpoint d'autenticació i el seu propi audit trail.
Cas real — Nexo com a servidor MCP
Nexo és el nostre SaaS propi de workspace per a equips. Va començar com una app Laravel + React + Inertia.js orientada a humans (documentació tècnica: Nexo: anatomia tècnica del nostre SaaS multi-tenant). Quan vam decidir obrir-lo a agents IA, vam prendre una decisió arquitectònica que va condicionar tota la resta: no exposaríem REST "i punt"; exposaríem directament un servidor MCP a sobre del mateix domini que ja servia la UI.
Arquitectura headless de Nexo
El backend de Nexo té un sol domini de negoci (workspaces, projectes, tasques, notes, agents). Sobre aquest domini corren tres transports diferents que comparteixen el mateix contracte:
- Inertia.js + React per a la UI humana (sessió cookie, optimista, client enriquit)
- REST + OpenAPI 3.1 per a integracions clàssiques (Zapier, Make, SDK propi)
- MCP server per al consum directe des de Claude, ChatGPT i qualsevol agent amb client MCP
El domini és el mateix. El que canvia és la capa de transport i la identitat del client. Això significa que quan un agent crea una tasca via MCP, aquesta tasca apareix immediatament a la UI humana del mateix workspace, amb l'usuari correcte com a propietari i amb l'agent clarament etiquetat com a actor.
Per què MCP en lloc de REST "i punt"
Podríem haver exposat només REST i deixar que cada integrador construís el seu propi wrapper MCP. Vam optar per exposar MCP natiu per tres raons:
- El contracte MCP captura la intenció millor que REST genèric. Una tool MCP es descriu amb nom, descripció, paràmetres tipats i exemples — el LLM no ha de deduir quin de vint endpoints REST fer servir; el veu literal.
- L'ecosistema MCP creix més ràpid que qualsevol SDK propietari. Claude, ChatGPT, Cursor, Windsurf, VS Code, Cline — tots parlen MCP. Si exposem MCP, tots ens consumeixen el dia u.
- L'observabilitat és gratis. Els harnesses MCP ja reporten quina tool s'ha cridat i amb quin resultat. Ens estalviem construir el nostre propi dashboard d'adopció per agent.
Mètriques objectiu (projeccions de disseny)
Les xifres següents són objectius de disseny calibrats contra implementacions comparables, no lectures en producció a gran escala encara. Les publiquem com a referència de què és raonable esperar d'una arquitectura MCP-first ben feta:
Valors calibrats en tests interns i contra literatura comparable; es refinaran amb dades de producció a mesura que escalem.
Lliçons de primera mà
El que ja sabem després de dissenyar i operar la capa MCP de Nexo, i que no era a cap paper quan vam començar:
- El cost arquitectònic real no és escriure MCP; és refactoritzar el teu backend perquè els endpoints siguin granulars, idempotents i compositius. El MCP server en si són ~600 línies de TypeScript. El dur és que la teva capa de negoci aguanti el que els agents li demanen.
- L'audit trail per agent canvia converses amb clients. Quan un client B2B veu al seu dashboard "el teu agent Claude ha canviat l'estat de 14 tasques divendres", la conversa passa de "puc confiar en això?" a "vull donar accés a més agents".
- Els scopes OAuth granulars venen. La primera objecció tècnica a vendes era sempre "i si l'agent se'n va de mare?". Tenir una resposta tipada — "aquest agent només pot llegir el projecte X fins al 31 de maig" — desbloqueja la signatura.
Quan NO migrar a API-First
La migració a API-First és cara i no sempre compensa. Tres casos en què la nostra recomanació honesta és no fer-ho:
- Producte sense cas d'ús agentic real. Si el teu producte és un ERP intern fet servir per 30 empleats i cap no construirà agents, una migració API-first no et donarà ROI. Inverteix en altres coses.
- Volum insuficient per amortitzar l'overhead. Si el teu trànsit total és de 100 peticions al dia, la complexitat afegida (gateway, versionat, OpenAPI estricte, MCP) pesa més que el benefici. Primer valida que hi ha demanda.
- Equip sense maduresa DevEx. API-First requereix cultura de contracte com a producte: changelog disciplinat, tests de contract, SLA documentats. Sense aquesta cultura, el contracte es desincronitza en sis mesos i tota la feina es perd. Abans de migrar, inverteix en la cultura.
Si encaixes en algun dels tres, millor continuar amb el teu stack actual i revisitar-lo d'aquí un any.
Roadmap de migració — per on començar
Setmana 1 — Inventari i auditoria
Llista tots els endpoints actuals del teu backend. Agrupa'ls per verb HTTP, per consumidor (web, mòbil, intern), per freqüència d'ús. Marca quins tenen versionat explícit, quins retornen errors estructurats, quins tenen idempotència. Aquesta auditoria sol revelar que el 70% del codi viu al 20% dels endpoints — aquests són els candidats prioritaris a convertir en API-first.
Mes 1 — Versionat + OpenAPI + auth neta
Publica OpenAPI 3.1 com a artefacte versionat per als endpoints crítics. Migra l'autenticació a OAuth 2.1 amb scopes granulars. Separa la identitat humana de la identitat agent. No intentis reescriure tot; comença per un domini acotat (per exemple, només el mòdul de "reserves" o "factures") i tracta'l com a prova.
Trimestre 1 — MCP server per a un cas d'ús
Tria un cas d'ús concret i construeix un MCP server que l'exposi. No intentis cobrir tot el producte; cobreix el 20% d'eines que genera el 80% del valor. Publica el MCP server com a open-source si té sentit (guanya mindshare), o tancat però documentat.
Any 1 — Composable + observabilitat completa
Migra la resta del backend al model composable. Implementa CQRS on el trànsit d'escriptura agent ho justifiqui. Instrumenta mètriques per tool, dashboards d'adopció per agent, alertes per degradació de latència. En aquest punt, l'arquitectura API-First deixa de ser un projecte i passa a ser la manera de treballar de l'equip.
Preguntes freqüents
Què és API-First en una línia?
Una arquitectura en què el contracte màquina-llegible es dissenya, versiona i publica abans que qualsevol interfície humana que el consumeixi.
És el mateix que headless?
No. Headless significa "sense capa de presentació acoblada al backend" — és una propietat estructural. API-First és una disciplina de disseny: el contracte va primer. Tota arquitectura API-First és headless, però no tota headless és API-First (pots tenir headless amb un contracte pèssim).
Necessito MCP si ja tinc REST?
No estrictament, però MCP accelera brutalment l'adopció per agents. Si els teus clients consumiran el teu producte via Claude, ChatGPT o Cursor, exposar MCP natiu els estalvia construir el seu propi adaptador. La cobertura tècnica és a MCP, WebMCP i A2A: protocols per a agents IA.
Com es monetitza una API consumida per agents?
El model clàssic (preu per usuari) no encaixa — un agent no és un usuari. Els models que funcionen: preu per volum (peticions o tokens consumits), preu per valor entregat (nombre d'accions completades), preu per agent connectat (llicència per bot). Algunes plataformes cobren per tier d'agent segons criticitat.
Quant costa migrar d'UI-First a API-First?
Depèn del punt de partida, però una migració honesta per a una plataforma SaaS mitjana (50-200 endpoints) està entre 3 i 9 mesos amb un equip dedicat. El cost més gran no és tècnic sinó cultural — acordar que el contracte és l'artefacte primari.
Què passa amb el meu SEO si deixo de tenir UI?
API-First no significa eliminar la UI pública. La UI es queda per a humans i SEO; el que afegeixes és la capa API/MCP per a agents. L'interessant és que amb WebMCP pots exposar accions directes als agents IA que visiten la teva web, cosa que obre noves superfícies d'adquisició.
Conclusió
Una arquitectura API-First no és un luxe tècnic ni una moda; és la manera de construir producte quan el consumidor principal deixa de ser un humà i passa a ser un agent. El pivot públic de Salesforce el 2026 és la confirmació tardana d'una cosa que els equips que construeixen avui ja donen per descomptada: l'API és la front door i la UI és un client més.
A Kiwop — Agència Digital especialitzada en Desenvolupament de Programari i Intel·ligència Artificial aplicada per a clients globals a Europa i EUA — hem construït Nexo amb aquest model des del primer dia, i ajudem equips tècnics a diagnosticar la seva arquitectura actual i dibuixar el camí més curt fins a API-First sense trencar el que ja funciona. Si estàs considerant la migració, sol·licita una auditoria d'arquitectura API-first o fes un cop d'ull als nostres serveis de desenvolupament d'agents IA, consultoria d'intel·ligència artificial i integració de LLM.
I si t'ha interessat la direcció tècnica, continua el fil amb els posts del cluster: MCP, WebMCP i A2A: protocols per a agents IA, agents IA en producció: patrons i antipatrons, Nexo: anatomia tècnica del nostre SaaS multi-tenant i d'OpenClaw a PA amb Claude Code i MCP.
