Webcompatibiliteit voor agenten verschuift van een add-on naar een standaardvereiste

Een normaal stukje inhoud verschijnt in de browser, maar kan vaak niet volledig worden gelezen wanneer het wordt doorgegeven aan het agentprogramma. Het feit dat de pagina kan worden geopend, betekent niet dat de pagina ook daadwerkelijk kan worden geconsumeerd; Het feit dat het door mensen kan worden gezien, betekent niet dat het op een stabiele manier door machines kan worden gelezen, geverifieerd en gevolgd.

Vroeger werd dit gezien als een bijzaak, zoals ‘de sitemap invullen’ of ‘wat gestructureerde gegevens toevoegen aan de artikelpagina’. Het is geen hoek meer. Zodra een openbare site te maken krijgt met AI-crawlers, geautomatiseerd ophalen en op agenten gebaseerde workflows, zijn de compatibele objecten niet langer alleen browsers en zoekmachines, maar ook een type client dat pagina’s kan splitsen op basis van semantiek, kan springen op basis van links en kan doorgaan met de uitvoering op basis van status. Als een pagina alleen vriendelijk is voor menselijke lezers, maar vol valkuilen voor dergelijke klanten, zal deze eruit gaan zien als een website met onvolledige compatibiliteit.

Het feit dat de pagina kan worden geopend, betekent niet dat de pagina kan worden gelezen.

Het eerste probleem is meestal niet de kwaliteit van de inhoud, maar de manier waarop de inhoud wordt weergegeven.

Als een pagina hoofdtekst in de weergave aan de clientzijde insluit, sleutelvelden in accordeonpanelen verbergt, paginering omzet in een scrollstroom zonder expliciete URL’s, en tabellen omzet in afbeeldingen, kan het agentprogramma alleen maar op giswerk vertrouwen. Voor mensen kan een verkeerde gok betekenen dat een paragraaf wordt gemist; voor een machine kan een verkeerde inschatting ervoor zorgen dat daaropvolgende acties op een dwaalspoor terechtkomen, en een paar stappen in de toekomst zullen alleen maar verdergaan volgens het verkeerde begrip.

Dit type probleem is vooral duidelijk op documentensites en inhoudssites. Menselijke lezers volgen de visuele laag en vullen zelf de context aan; agenten niet. Wat de agent ziet is het DOM, de kopteksthiërarchie, koppelingsrelaties, formulierbesturingselementen, statuscodes en doorzoekbare tekst. Als de hoofdtekst wordt losgekoppeld van deze basissignalen, zal de pagina in een ongemakkelijke staat verschijnen: hij ziet er modern uit, maar is in werkelijkheid onstabiel.

Bij het migreren van applicaties met één pagina in het verleden werd deze laag vaak als eerste zichtbaar. Het eerste scherm verschijnt en de interactie is mogelijk, maar de machine legt de shell vast en de echte tekst verschijnt pas als het script is voltooid. Gecombineerd met lazyloading, oneindig scrollen en verschillende “uitbreiden en bekijken”-ontwerpen, zal de inhoudspagina een reeks toevallige gebeurtenissen worden. Voor browsergebruikers is het slechts een kleine vertraging; voor agenten is het een keten van onbetrouwbare vermeldingen.

Wat de machine wil is een stabiele toegang, geen visuele inhoud.

Door de site ‘agent-ready’ te maken, wordt in wezen een laag compatibiliteit toegevoegd, in plaats van een nieuwe truc toe te voegen.

Het meest waardevolle aspect van deze compatibiliteitslaag is niet om de pagina er “uit te laten zien alsof deze voor machines is”, maar om duidelijk de meest fundamentele feiten weer te geven: welke pagina dit is, waar de tekst staat, wat de huidige status is, of deze kan blijven springen en wat moet worden geretourneerd als deze mislukt. Zolang deze feiten onstabiel zijn, zullen agenten herhaaldelijk de grenzen opzoeken.

De meest waardevolle dingen om als eerste mee om te gaan op inhoudssites zijn meestal deze dingen:

• De tekst moet rechtstreeks toegankelijk zijn vanuit de HTML, zonder afhankelijk te zijn van scripts om deze te raden
• De titelhiërarchie moet stabiel zijn en de visuele stijl mag de semantische structuur niet vervangen.
• Paginering, filtering en zoekresultaten moeten deelbare URL’s hebben, en mogen niet alleen in de front-end-status bestaan
• Afbeeldingen, tabellen en codeblokken moeten leesbare alternatieve tekst of originele tekst hebben
• De basisexports van canonical, sitemap en feed moeten schoon zijn en niet gemengd met een heleboel tijdelijke parameters.

Dit klinken misschien als clichés, maar hun betekenis is nu veranderd. In het verleden werden deze toegevoegd omwille van zoekmachines en toegankelijkheid; nu worden deze toegevoegd zodat de agent de inhoud stabiel kan lokaliseren, de relatie tussen pagina’s kan bepalen en zonder handmatige aanwijzingen door kan gaan naar de volgende stap. Ze wijzen allemaal op hetzelfde: de pagina moet worden behandeld als een definitieve invoer van een andere klant, in plaats van als een eenmalig visueel resultaat.

Dit is de reden waarom “het toevoegen van een AI-knop” niet echt helpt. De knop zelf maakt de pagina niet gebruiksvriendelijker. In het beste geval verpakt het een actie gewoon in een nieuw item. Als de onderste laag nog steeds afhankelijk is van de visuele lay-out en de tijdelijke status om het begrip te behouden, zal het agentprogramma nog steeds zijn grip verliezen bij het vernieuwen, springen, terugdraaien en wijzigen van rechten.

Interactie moet de actie voltooien, en niet alleen stoppen bij de prompt

Als de pagina alleen bedoeld is voor de weergave van inhoud, zijn compatibiliteitsproblemen relatief eenvoudig op te lossen. Als het gaat om het interactie- en bedieningsniveau, wordt het probleem nog moeilijker.

Wat een agent werkelijk nodig heeft, is niet ‘bijna genoeg’, maar duidelijke actiegrenzen. Verzenden, bevestigen, intrekken, downloaden, abonneren, springen en exporteren, deze acties moeten bij voorkeur duidelijke randvoorwaarden, foutretouren en traceerbare resultaten hebben. Zolang acties worden gecombineerd met een heleboel pop-ups, prompts en secundaire bevestigingen, zal de machine steeds opnieuw op dezelfde plek blijven hangen.

Dit is waar het verschil tussen openbare sites en interne systemen groot begint te worden. Openbare sites hebben te maken met verbruiksmogelijkheden, terwijl interne systemen te maken krijgen met machtigingen en risicobeheersing. Het eerste is geschikter voor het stabiliseren van de informatiestructuur en de semantiek van acties, zodat externe klanten omwegen kunnen vermijden; laatstgenoemden mogen de grenzen niet versoepelen om “compatibel te zijn met agenten”, vooral als het om fondsen, publicaties, verwijderingen en toestemmingswijzigingen gaat. We moeten nog steeds conservatief zijn waar we conservatief zouden moeten zijn.

Het gaat hier dus niet om het transformeren van alle webpagina’s in machine-interfaces. Een meer realistische benadering is om de pagina’s die oorspronkelijk bedoeld zijn voor externe consumptie om te zetten in stabiele, verifieerbare en herspeelbare ingangen. Artikelpagina’s, documentatiepagina’s, kennisbanken, helpcentra, open API’s en openbare zoekresultaten worden als eerste getroffen en zien als eersten voordelen.

Dit compatibiliteitsniveau heeft duidelijke grenzen

Klaar voor agenten is geen one-size-fits-all doel.

De backend van een compleet intranet, het bedrijfssysteem met sterke toestemmingscontrole, de activiteitenpagina met een korte levenscyclus en het inhoudstation voor openbaar gebruik bevinden zich niet op hetzelfde niveau. De eerstgenoemde geeft meer om controle, terwijl de laatste meer om leesbaarheid, indexeerbaarheid en traceerbaarheid geeft. Het dwingen van deze twee typen systemen tot dezelfde set standaarden die ‘machines bruikbaar maken’ zal uiteindelijk de beheerkosten alleen maar verhogen.

Maar het is moeilijk om te blijven doen alsof er niets is veranderd op de openbare site. AI-crawlers zullen pagina’s steeds vaker rechtstreeks lezen, en de workflows van agenten zullen steeds meer afhankelijk zijn van gestructureerde inhoud en stabiele acties. Als een site nog steeds vasthoudt aan het idee ‘het is genoeg dat mensen het zien’, zullen er vroeg of laat scheuren ontstaan ​​in de distributie, het ophalen, archiveren en geautomatiseerde integratie van de inhoud.

Deze verandering lijkt dus meer op een compatibiliteitsupgrade. In het verleden moest de front-end rekening houden met verschillende browsers, verschillende schermen en verschillende netwerken; nu moet het ook rekening houden met een type client dat zelf pagina’s kan splitsen, zelf links kan volgen en de status zelf kan verifiëren. Met deze compatibiliteitslaag kan de site echt aan een nieuwe standaardvereiste voldoen: deze moet niet alleen zichtbaar zijn, maar ook stabiel worden gebruikt.