Agent-ready website

Et agent-ready website er et website eller en digital service, som AI-agenter kan forstå og bruge til at løse konkrete opgaver. Det kan være at sammenligne produkter, hente dokumentation eller sende en tilbudsforespørgsel på en kundes vegne.

Begrebet er nyere og har ikke én universelt accepteret definition. Det betegner heller ikke en officiel webstandard. Hos HappiLeap bruger vi det som en praktisk ramme for at gøre udvalgte kundeopgaver gennemførlige med tydelig information, brugbare interfaces og klare adgangsregler.

Fra læsbar information til mulige handlinger

Agent-readiness omfatter to forskellige opgaver.

Information skal kunne forstås. Agenten skal kunne identificere virksomheden, dens ydelser, produkternes egenskaber og relevante vilkår. Klare overskrifter, konkrete beskrivelser og konsistente oplysninger giver et bedre grundlag for at arbejde med indholdet.

Structured data, eksempelvis Schema.org-markup, kan beskrive, hvilke oplysninger der handler om en organisation, et produkt eller et tilbud. Det supplerer sidens indhold med en maskinlæsbar struktur.

Handlinger skal kunne gennemføres. Agenten skal have en brugbar vej til eksempelvis at vælge en service, udfylde en formular eller oprette en forespørgsel. Det kræver tydelige input, forståelige trin og et resultat, der kan kontrolleres.

En produktside kan altså give et godt grundlag for en sammenligning, mens tilbudsformularen stadig kræver, at nogen ringer til Lars for at forstå feltet “Kategori B”.

Hvordan arbejder AI-agenter med websites?

En AI-agent kan arbejde mod et mål gennem flere trin og bruge værktøjer undervejs. Hvordan den møder virksomhedens website, afhænger af agentløsningen.

Computer use: Agenten bruger grænsefladen

Ved computer use kan en model betjene en browser eller anden brugergrænseflade gennem software. Den kan eksempelvis vurdere skærmbilleder, klikke på knapper og udfylde formularer.

For websiteejeren gør det tydelig navigation, genkendelige betjeningselementer og forståelige formularforløb relevante. Om agenten faktisk kan gennemføre opgaven, skal testes.

Tool calling: Agenten kalder en funktion

Tool calling betyder, at modellen anmoder om at bruge et tilgængeligt værktøj. Det kan eksempelvis være en funktion, der henter produktdata eller opretter en tilbudsforespørgsel via et API. Et API er en grænseflade, som software kan bruge til at udveksle data eller anmode om handlinger.

Softwaren omkring modellen udfører kaldet og sender resultatet tilbage. Virksomheden bør derfor beskrive funktionens formål, nødvendige oplysninger og mulige resultater præcist.

MCP: En fælles måde at forbinde værktøjer på

MCP, Model Context Protocol, er en åben protokol for at forbinde AI-applikationer med eksterne data og værktøjer. En virksomhed kan eksempelvis stille udvalgte funktioner til rådighed gennem en MCP-server.

Den konkrete agentløsning skal være forbundet med serveren og have den nødvendige adgang. Et API eller en MCP-server på virksomhedens side giver ikke automatisk alle agenter adgang. Valget af integration bør følge opgaven og de systemer, der skal bruge den.

Hvad bør en B2B-virksomhed gennemgå?

En praktisk gennemgang kan begynde med fem områder:

1. Gældende fakta: Er produktnavne, specifikationer og vilkår konsistente? Udpeg en ansvarlig for oplysningerne, så website og eventuelle integrationer bygger på samme grundlag.
2. Tilgængeligt indhold: Kan relevante løsninger og dokumenter findes gennem tydelige links? Sørg for, at centrale oplysninger også er tilgængelige som tekst.
3. Formularer: Har felterne klare navne og instruktioner? Bed om de oplysninger, opgaven kræver, og forklar fejl, så de kan rettes.
4. Integrationer: Hvis virksomheden tilbyder APIs eller værktøjer, bør dokumentationen forklare adgang, input, begrænsninger og svar. Afgræns funktionerne til konkrete opgaver.
5. Bekræftelse: Vis, hvad der er sket efter en handling. En kvittering bør gøre det tydeligt, om en forespørgsel er modtaget, en booking er gennemført, eller noget stadig afventer.

Eksempel: En agent anmoder om en demo

En softwarevirksomhed tilbyder løsninger til facility management. En potentiel kunde beder sin agent undersøge, om løsningen understøtter flere lokationer, og derefter anmode om en demo.

Agenten skal først kunne finde præcise oplysninger om funktionen. Derefter skal den kunne identificere demoformularen eller et tilgængeligt bookingværktøj, indtaste godkendte kontaktoplysninger og kontrollere kvitteringen.

Virksomheden bør tydeliggøre, om kunden har reserveret et tidspunkt eller blot bedt om at blive kontaktet. Den forskel kan let blive til en tom plads i kalenderen.

Sikker adgang er en del af opgaven

Fastlæg, hvilke oplysninger der er offentlige, og hvilke handlinger der kræver login, bestemte rettigheder eller brugerens godkendelse. Køb, ændringer og videregivelse af følsomme oplysninger bør have passende kontrolpunkter.

Rettigheder og validering skal håndhæves i virksomhedens systemer. Instruktioner til modellen kan supplere kontrollen. En hjemmeside bør heller ikke kunne give agenten tilladelse til handlinger, som brugeren ikke har godkendt.

HappiLeap-perspektiv

Vores arbejdsregel er: Vurder agent-readiness pr. kundeopgave. Vælg eksempelvis tre opgaver fra kunderejsen, og undersøg for hver: Kan agenten forstå informationen, udføre den tilladte handling og kontrollere resultatet?

Registrér, hvor forløbet stopper. Manglende produktfakta kræver typisk arbejde med indholdet. Uklare formularer kræver arbejde med brugeroplevelsen. Manglende adgang til en funktion kan kræve en integration. Det giver marketing, salg og IT en konkret prioriteringsliste.

Byg videre på virksomhedens eksisterende website og relevante standarder. Test med de agentløsninger, kunderne forventes at bruge, i et afgrænset miljø. Kontrollér resultatet i det modtagende system, og gentag testen efter væsentlige ændringer. Succes måles her på korrekt gennemførte opgaver.