Atlas sulkeutuu, agentit jäävät: mikä muuttui sivustoille

Lyhyt vastaus: OpenAI julkisti Atlasin 21. lokakuuta 2025, ilmoitti sen lopettamisesta 9. heinäkuuta 2026 ja poisti tuotteen käytöstä elokuussa 2026. Ominaisuuksia ei poistettu, ne jaettiin ChatGPT:n työpöytäsovellukseen ja Chrome-laajennukseen. Tuolloin tehty johtopäätös: selain osoittautui ominaisuudeksi, ei päämääräksi.

Mikä piti:

• Agenttikaupan suunta. Käyttäjän puolesta toimivat agentit eivät kadonneet; OpenAI siirsi kyvyn sen sijaan että olisi peruuttanut sen.
• API-ensin-vaatimus. Agentin tarve puhua rajapinnalle painikkeiden klikkaamisen sijaan ei ole muuttunut.
• Palomuurin ristiriita. Laillisen agentin erottaminen vihamielisestä kaapijasta on yhä ratkaisematta.
• Pienyritysten kuilu. Turvallisen ja dokumentoidun rajapinnan hinta on yhä vakava este pienemmille yrityksille.
• Muurien ympäröimän puutarhan riski. Tämä kohta vahvistui odotettua nopeammin: oman selaimen ylläpidon sijaan OpenAI siirtyi Chromen laajennusekosysteemiin. Agenttikerros rakentuu vakiintuneiden puutarhaan, ei itsenäiselle ovelle.

Mikä ei pitänyt:

• Aikakauden nimeäminen tuotteen mukaan. Atlas-vallankumouksen kehys oli väärä. Muutosta ei kantanut selainbrändi vaan tapa, jolla agentit puhuvat verkolle. Tuotteeseen sidottu kehys vanheni tuotteen mukana.

Oppi yhdellä lauseella: rakenna valmistautuminen mallin äläkä tuotteen ympärille. Atlasille tehty API-, skeema- ja nopeustyö toimii sellaisenaan ChatGPT-laajennukselle sekä Geminin, Perplexityn ja Copilotin agenteille. Tuotenimen ympärille suunnitelleet tiimit joutuivat vaihtamaan suuntaa kahdesti yhdeksässä kuukaudessa.

Tekoäly ei enää vain anna vastauksia; se toimii puolestamme. Tässä uudessa ekosysteemissä tekoälyagentit, jotka voivat suorittaa itsenäisiä tehtäviä käyttäjien puolesta, ovat pääroolissa.

Lyhyt vastaus: Atlas oli OpenAI:n 21. lokakuuta 2025 julkistama työpöytäselain, jonka ytimessä oli ChatGPT. Sen tavoite oli antaa agentin selata sivuja, täyttää lomakkeita ja viedä tapahtumia loppuun käyttäjän puolesta. OpenAI lopetti sen yhdeksän ja puoli kuukautta myöhemmin ja siirsi nämä kyvyt ChatGPT-sovellukseen ja Chrome-laajennukseen. Karsittu asia oli tuote, ei idea.

Agenttikäsite ei alkanut Atlasista. Vuonna 2023 avoimen lähdekoodin hankkeet kuten Auto-GPT, BabyAGI ja AgentGPT olivat ensimmäisiä itsenäisiä yrityksiä tuottaa tehtävälistoja itse; ne olivat vaikeita asentaa ja useimmat jumittuivat matkan varrella. Automaatioalustat kuten n8n ajoivat saman idean sääntöihin sidottua versiota yhdistämällä eri sovellusten rajapintoja.

Ero oli itsenäisyyden asteessa. n8n:ssä määrittelemme logiikan: jos X niin Y. Agentille annamme tavoitteen ja se rakentaa askeleet. Atlasin takana ollut väite oli tuoda tämä kyky laboratoriosta miljardien käyttämän käyttöliittymän ytimeen. Se väite pitää yhä; vain kantava pinta osoittautui olemassa oleviksi selaimiksi ja sovelluksiksi eikä omaksi tuotteeksi.

Esimerkki tekee eron konkreettiseksi.

• Vastauskone: kysyt Googlelta halvinta lentoa ja saat listan tai tiivistelmän. Sivustolle menet sinä, lomakkeen täytät sinä.
• Agentti: sanot, etsi ja osta turistiluokan lippu ensi perjantaiaamuksi alle 200 dollarilla. Agentti löytää vaihtoehdon, varaa sen ja päättää tapahtuman.

Tätä kutsutaan agenttikaupaksi, ja se tarkoittaa, ettei asiakkaasi ole enää vain ihminen. Sivustollasi on toinen kävijätyyppi: käyttäjän valtuuttama ohjelmisto.

Tämä on tämän analyysin kriittisin tietoisuuden kohta. Jos huomisen asiakas on agentti, tuon agentin on voitava puhua sivustollemme. Agentti ei yritä navigoida napsauttamalla sivustosi painikkeita ja kirjoittamalla lomakkeisiin kuten ihminen. Tämä menetelmä on liian hidas, hauras ja virhealtis. Agentit tarvitsevat luotettavan, nopean ja skaalautuvan tavan kommunikoida.

Tämä tuo meidät kahteen perustavanlaatuiseen tekniseen välttämättömyyteen verkkosivustoillemme. Nämä ovat koodin ja sisällön optimointi.

Toistaiseksi sisällössämme olemme sanoneet, että API on kriittinen toiminnalle (osto, varaus). Tämä on kuitenkin vain osa koodin optimointia. Ennen kuin agentti voi toimia, sen on luettava ja ymmärrettävä sivustosi. Joten, mitä nämä seuraavan sukupolven sivustot tarvitsevat koodauspuolella vastatakseen agentin tarkoitukseen sekä luku- että toimintatasolla?

Tämä on perussääntö, josta keskustelimme. agenttiekosysteemissä agentti tarvitsee API:n toimimaan sivustollasi (ostaa tuotteita, tehdä varauksia). Näyttää siltä, että lähitulevaisuudessa yrityksen pääasiallinen tuote ei ole enää visuaalinen verkkosivusto, vaan sen tarjoama API. E-kaupankäyntisivusto ilman API:ta näkyy agenteille näkymättömänä ja jää "Agentic Commerce":n ulkopuolelle.

Realiteettitarkistus (kustannukset): Emme kuitenkaan saa unohtaa tämän vallankumouksen taloudellista vaikutusta. Miljoonille pienille ja keskisuurille yrityksille (tavalliset WooCommerce- tai Shopify-sivustot) turvallisen, skaalautuvan ja hyvin dokumentoidun API:n luominen ja ylläpito on valtava este. "Atlas"-vallankumous saattaa laajentaa teknologiajättien (kuten Amazon) ja PK-yritysten välistä kuilua demokratisoimisen sijaan. Siksi tähän tavoitteeseen pitäisi harkita hallittavampia ensimmäisiä askelia, kuten 'read-only API:t', kuten keskustelimme 'AI Defense Line'-osiossa.

Sanoin, että agentit eivät luota hitaisiin sivustoihin, nyt käsittelemme tätä kysymystä syvällisesti. Mikä aiheuttaa hitautta? Tähän kysymykseen ei ole yhtä vastausta. Se on useiden tekijöiden yhdistelmä.

• Infrastruktuurin valinta (pilvi vs. dedikoidut) - Perinteiset jaetut hosting-ratkaisut tai tavalliset VPS-ratkaisut eivät riitä vastaamaan agenttiliikenteen välittömiin ja intensiivisiin vaatimuksiin. Agentit, kuten ihmiset, eivät halua jäädä sivustosi RAM- tai CPU-rajoihin ja saada virheitä. Tässä tarvitaan pilvipalvelimia (kuten AWS, Azure, GCP) tai suorituskykyisiä dedikoidtuja palvelimia. Nämä järjestelmät tarjoavat välittömän skaalautuvuuden joustavuuden kysynnän mukaan.
• Sijainti ja latenssi - Nopeusoptimointin avain kohderyhmäsi mukaan on latenssin minimointi. Jokainen millisekunti on tärkeä agentille. Jos sinulla on amerikkalaisia käyttäjiä, palvelimesi täytyy olla myös Amerikassa (tai paremmin, Amerikan reunassa CDN:n kanssa). Ratkaisu ei ole palvelimen sijoittaminen yhteen paikkaan, vaan CDN (Content Delivery Network) ja Edge Computing infrastruktuurien käyttö. Näin sivustosi staattiset kopiot tai jopa funktiot tarjoillaan lähimmästä maantieteellisestä pisteestä, jossa käyttäjä (tai agentti) sijaitsee (Amerikasta, Japanista, Euroopasta). Latenssi vaikuttaa suoraan luotettavuuteesi agentin silmissä.
• Koodin ja tietokannan tehokkuus - Vaikka saisit nopeimman palvelimen, optimoimaton tietokantakysely (kuten N+1-ongelma) tai hitaasti toimiva palvelinpuolen funktio muuttaa koko järjestelmän kilpikonneksi. Mikä hidastaa asioita, on usein itse koodi, ei infrastruktuuri. Agentit suosivat tehokkaasti kirjoitettua, optimoitua, puhdasta koodia. Headless-arkkitehtuurien ja lähestymistapojen, kuten JAMstack, voima tulee esiin täällä. Ne minimoivat tietokanta- ja funktiokuormaa tekemällä mahdollisimman paljon staattisesta (välimuistissa oleva HTML). Annan sinulle vinkin - Tämä nopeus ei saavuteta vain perinteisellä 'välimuistilla'. Voit myös luoda virtuaalisia HTML:ää, jotka käyttäytyvät kuin PHP. Tässä lähestymistavassa, kun dynaaminen rakenne (puoliksi paikallinen, puoliksi tietokantaa käyttävä) toimii taustalla, järjestelmä voi välittömästi tuottaa dynaamista HTML-muotoista tulostetta agentille ilman välimuistin tarvetta käyttämällä näitä virtuaalisia staattisia tiedostoja.

Tämä on ehkä yksi kriittisimmistä ja unohdetuimmista teknologisista haasteista. Raskaat palomuurit (WAF - Web Application Firewall) ja monimutkaiset bottisuojausjärjestelmät, jotka olemme asettaneet suojellaksemme sivustoamme, voivat olla suurin esteemme Atlas-vallankumouksessa.

Nämä turvallisuusjärjestelmät on suunniteltu estämään epäilyttävä ei-inhimillinen liikenne. Mutta miten ne erottavat ei-inhimillisen mutta laillisen (ja asiakkaamme) AI-agentin pahantahtoisesta botista?

Hitauden ja latenssin lisäksi näiden järjestelmien vahingossa palauttama "403 Forbidden" tai "429 Too Many Requests" vastaus agentille olisi katastrofi. Agentti merkitsee kyseisen sivuston luotettamattomaksi tai saavuttamattomaksi ja todennäköisesti ei koskaan palaa.

Tämä vie meidät pisteeseen, joka on *ihanteellisesti* ratkaistu kooditasolla, mutta *käytännössä* muuttuu ratkaisemattomaksi dilemmaksi. Teoriassa voimme väittää, että turvallisuuden pitäisi olla itse koodissa (API-avaimet, älykäs nopeusrajoitus, turvalliset kyselyt, parametrien validointi). Mutta käytännössä tämä on monimiljoonan dollarin ongelma. "Atlas"-agentin (laillinen asiakas) erottaminen aggressiivisesta "scraping"-botista (pahantahtoinen varas) miljoonien pyyntöjen mittakaavassa on lähes mahdotonta.

Riski on tämä: Yritykset joutuvat käyttämään raskaita palomuureja ja bottisuojauskerroksia (Cloudflare, Akamai, jne.) suojellakseen API:jaan, ja nämä järjestelmät estävät väistämättä myös lailliset agentit. Tämä tilanne saattaa johtaa "muurien puutarhaan", jossa on erityisiä sopimuksia suurten teknologiayritysten (OpenAI, Google) ja verkkosivujen välillä sanomassa "Tämä on agenttini, luota siihen" avoimen ekosysteemin sijaan.

Mikä Schema tekee sisällölle, semanttinen HTML5 tekee itse koodille. Agentti skannaa raakaa HTML-koodia ennen kuin pääsee Schema-tageihin lukemalla sivusi. Jos sivustosi on div-keittoa, joka on tehty merkityksettömistä <div> ja <span> tageista, agentti hämmentyy.

Jos kuitenkin kirjoitat koodisi sopivilla semanttisilla HTML5 tageilla, kuten <article>, <nav>, <aside>, <section>, <figure>, annat agentille sivun rakenteellisen kartan, kun se vielä lukee koodia. Agentti ymmärtää välittömästi, että <article> tagi on pääsisältöä, <aside> tagi on sivutietoa. Tämä nopeuttaa palapelinratkaisuprosessia, josta keskustelimme edellisessä osiossa kooditasolla ja lisää ymmärtämiskykyä vähentämällä Schema-riippuvuutta.

Kooditasolla (API) kanssamme puhuvat agentit ovat toimintaosa. Mutta entä ymmärrysosa? Agentin on ymmärrettävä selvästi, mitä sivustomme sisältö tarkoittaa.

Ensimmäinen ja perustavanlaatuisin askel tähän on käyttää rakenteista dataa (Schema.org). Tehdään tämä nyt verkkokauppasivustolle ja trendituotteelle, mikä on paljon tärkeämpää «agenttikaupalle».

Oletetaan, että myyt erittäin haluttua, merkitöntä, tehokasta 144 Hz:n 4K-pelinäyttöä. Ihmisen on helppo tulla tuotesivullesi ja ymmärtää hinta: 499 dollaria ja varasto: saatavilla.

Mutta entä Atlas-agentti, joka on saanut käyttäjältään komennon «Etsi ja osta minulle alle 500 dollarin, 4K:n ja vähintään 120 Hz:n pelinäyttö»? Miten agentti voi tietää varmasti, että 499 dollaria sivustollasi on hinta, 144 Hz on virkistystaajuus ja sana saatavilla tarkoittaa ostettavissa (InStock)? Entä jos 499 dollaria on osa mallinumeroa? Entä jos saatavilla tarkoittaa saatavilla myymälässä, ei verkossa?

Agentit eivät voi arvata. Heidän on tiedettävä. Tässä Tuote-skeema tulee kuvaan. Käytämme skeemaa antaaksemme tekoälylle tämän teknisen viestin:

{
  "@context": "https://schema.org",
  "@type": "Product",
  "name": "Tehokas 27 tuuman pelinäyttö",
  "description": "Matala viiveinen 4K-näyttö 144 Hz:n virkistystaajuudella.",
  "sku": "GM-27-4K-144",
  "brand": {
    "@type": "Brand",
    "name": "XYZ"
  },
  "image": "https://sivustosi.com/images/gm-27-4k-144.jpg",
  "offers": {
    "@type": "Offer",
    "url": "https://sivustosi.com/tuote/gm-27-4k-144",
    "priceCurrency": "USD",
    "price": "499",
    "availability": "https://schema.org/InStock"
  },
  "additionalProperty": [
    {
      "@type": "PropertyValue",
      "name": "Virkistystaajuus",
      "value": "144Hz"
    },
    {
      "@type": "PropertyValue",
      "name": "Resoluutio",
      "value": "4K"
    }
  ]
}

Tämä merkintä ottaa tuotetietomme (ihmisen luettavissa) ja muuttaa ne koneellisesti luettaviksi tosiasioiksi, joita agentti voi käsitellä 100-prosenttisella varmuudella. Agentti ei enää arvaa hintaa, varastotilannetta ja teknisiä tietoja. Se tietää ja voi aloittaa ostosprosessin luottavaisin mielin.

Todellisuuden tarkistus (agentin laiskuus): Sisällön suunnittelu ajatuskartan (palapelin) kaltaiseksi on edistynyt strategia. Ajatellaan kuitenkin tekoälyagenttia kehittävän insinöörin näkökulmasta: onko agentille tehokkaampaa oppia kunkin sivuston ainutlaatuinen pulmanratkaisulogiikka vai sanoa sille «Lue vain tavalliset Schema.org-tagit ja API ja jätä loput huomiotta»? Vaikuttaa siltä, että skaalautuvuus ja tehokkuus voittavat. Agentit ovat «laiskoja» ja suosivat standardia, joka on skeema ja API. Siksi, vaikka ajatuskartta on hieno, prioriteettimme ja välttämättömyytemme on oltava standardi skeemamerkintä.

Ensimmäinen vaihe on jo alkanut, ja monet meistä tuntevat sen vaikutukset. Hakukoneet, kuten Google, eivät ole enää oppaita, jotka tarjoavat meille 10 sinistä linkkiä. Niistä on tullut vastauskoneita, jotka tuottavat suoraan vastauksia kysymyksiimme ja syntetisoivat tietoa. Tämä oli ensimmäinen suuri askel, joka muutti pelin sääntöjä täysin.

Jos muistat, jokin aika sitten oli «esillä olevia katkelmia». Google lainasi yhtä sivustoa, joka vastasi parhaiten kysymykseemme, ja asetti sen aivan ylös, nollapaikalle. Tavoitteenamme oli vallata tuo yksi paikka.

Googlen tekoälyn yleiskatsaukset tuhosivat tämän mallin kokonaan. Nyt Google ei ota parasta vastausta yhdeltä sivustolta. Sen sijaan se hakee tietoja useista lähteistä (joskus jopa alempana sijoittuneilta sivustoilta), syntetisoi ne ja luo oman tekoälyn tuottaman vastauksensa.

Mikä on tämän tilanteen selvin seuraus? «Nollaklikkaushakujen» räjähdysmäinen kasvu. Käyttäjät eivät tunne tarvetta napsauttaa sivustoasi, koska he saavat vastauksen suoraan hakusivulta. Analyysit osoittavat, että tämän uuden järjestelmän esiintyvissä hauissa orgaanisten klikkausprosenttien on todettu laskeneen vakavasti. Jos liiketoimintamallisi perustuu liikenteeseen ja mainontaan, tämä on sinulle suora uhka.

Joten, jos emme saa klikkauksia, mikä tavoitteemme pitäisi olla? Neuvo tässä on, että tavoitteen ei pitäisi enää olla klikkausten saaminen, vaan lähteenä mainitseminen siinä tekoälyn tuottamassa vastauksessa. Tätä uutta alaa kutsumme vastauskoneoptimoinniksi (AEO).

AEO, toisin kuin perinteinen SEO, keskittyy pitkiin ja keskusteleviin kysymyksiin. Tavoitteenamme on saada tekoälymalli mainitsemaan sisältömme lähteenä sanomalla: «Tämä tieto on luotettavaa, selkeää ja arvokasta».

Miten ansaitsemme tämän luottamuksen? Tässä E-E-A-T (kokemus, asiantuntemus, auktoriteetti, luotettavuus) tulee kuvaan. E-E-A-T ei ole enää vain Googlen ohjeistus; se on vahvin puolustusmekanismimme tekoälyä vastaan. Toisin kuin generatiivisen tekoälyn kaupallistama yleinen sisältö, meidän on esitettävä todelliset, omakohtaiset kokemuksemme, todistettavissa oleva asiantuntemuksemme ja auktoriteettimme. Tekoäly ei voi käyttää tuotetta tai mennä itse matkalle. Mutta me voimme, ja voimme välittää tuon kokemuksen. Tämä nostaa meidät sisällöstä, jonka tekoäly vain tiivistää ja ohittaa, luotettavaksi lähteeksi.

Joten miten emme vain väitä tätä luottamusta, vaan todistamme sen sekä ihmisille että koneille? Tässä tulee esiin rakenne, jota voimme kutsua «todennettavaksi auktoriteettikerrokseksi». Tämä rakenne muuttaa E-E-A-T-signaalimme konkreettisiksi, koneellisesti luettaviksi todisteiksi. Tämä kerros rakentuu kahdelle perustodistukselle. Ensimmäinen on kirjoittajan auktoriteetti. Kyse ei ole vain kirjoittajan nimen kirjoittamisesta, vaan kyseisen henkilön yhdistämisestä todennettavissa oleviin lähteisiin, kuten LinkedIniin tai akateemisiin julkaisuihin, skeematagien avulla. Toinen on sisällön auktoriteetti. Artikkelin väitteiden on perustuttava alkuperäisiin aineistoihin, ensisijaisiin lähteisiin tai omistusoikeudelliseen tutkimukseen. Agentin on tiedettävä, että näitä tietoja ei ole tiivistetty muualta, että sinä olet lähde.

Jos näit vaiheen 1, AEO:n ja E-E-A-T:n optimoinnin, vain puolustavana liikkeenä nykyisen liikenteesi suojaamiseksi, meidän on muutettava näkökulmaamme nyt. Koska olemme unohtaneet perusperiaatteen. Agentti ei koskaan toimi järjestelmässä, johon se ei luota.

Tämä on avain, joka avaa vaiheen 2. Tekoäly ei ota riskiä tehdä tapahtumaa käyttäjän luottokortilla sivuston API:n avulla tarkistamatta sisällön tarkkuutta, kirjoittajan asiantuntemusta ja sivuston luotettavuutta. Siksi tie agentin optimointiin kulkee virheettömän vastauskoneoptimoinnin kautta. Luottamuksen rakentaminen on toiminnan edellytys.

Kun yhdistämme nämä kaksi vaihetta (agentit ja AEO), näen selvästi, että digitaalisessa maailmassa on alkamassa «suuri ero». Kaikki verkkosivustot eivät vaikuta tähän muutokseen yhtä paljon. Joillekin tämä tarkoittaa «verkkosivuston sukupuuttoon kuolemista», kun taas toisille alkaa ennennäkemättömien mahdollisuuksien aikakausi.

Riski- ja mahdollisuusspektri eroaa seuraavasti.

• Korkean riskin omaisuus (tietosivustot) - Alustat, joiden arvolupaus on vain helposti tiivistettävää tietoa (yksinkertaiset «mitä on?» -artikkelit, yleiset blogit, viiteoppaat), ovat suurimmassa vaarassa. Koska tekoäly tarjoaa nyt nämä tiedot suoraan, nämä sivustot ovat vaarassa menettää liikenteensä ja toimintonsa.
• Korkean mahdollisuuden omaisuus (tapahtuma, vuorovaikutus, yhteisö) -
  • Verkkokauppa ja SaaS - Nämä sivustot ovat luonteeltaan toimintalähtöisiä. Agentti ei voi kopioida ohjelmistoa (SaaS), mutta se voi käyttää sitä API:n kautta. Se ei voi tiivistää tuotetta, mutta se voi ostaa sen API:n kautta. Nämä alustat ovat agenttien ensisijaisia tapahtumapisteitä.
  • Yhteisöalustat (Reddit, foorumit jne.) - Näillä sivustoilla on jotain, mitä tekoäly ei voi tuottaa: aitoa inhimillistä kokemusta (E-E-A-T:n «E»). Todellisen maailman mielipiteet, henkilökohtaiset kokemukset ja kapea-alaiset keskustelut ovat korvaamaton ihmisen näkemyksen lähde agenteille.

Jos olet korkean riskin kategoriassa, on välttämätöntä, että kehität liiketoimintamalliasi tiedosta toimintaan tai kokemukseen.

Tämä on tärkein strateginen johtopäätös, joka sinun tulisi tehdä tästä analyysistä. Tapa selviytyä «Atlas»-aikakaudella on luoda arvoa, jota tekoäly ei voi helposti kaupallistaa, kopioida tai tiivistää. Voimme kutsua tätä «tekoälyn vallihaudaksi» (AI Moat).

Jokaisella yrityksellä on kuitenkin erilaiset resurssit. On terveellisintä ajatella tätä puolustuslinjaa kerroksellisella lähestymistavalla, askeleista, jotka kaikki voivat «aloittaa huomenna», pitkän aikavälin visioon:

Kerros 1: Nopeat voitot (alhainen hinta, suuri vaikutus)

• Tekninen E-E-A-T:n vahvistaminen: Tämä on helpoimmin saavutettavissa oleva ensimmäinen askel. Merkitse kirjoittajaprofiilisi Kirjoittaja- ja Henkilö-skeemoilla. Todistaaksesi kirjoittajan asiantuntemuksen, linkitä todennettavissa oleviin LinkedIn-, Twitter- tai akateemisiin profiilisivuihin sameAs-tagilla.
• Perus-Schema.org-toteutus: Ennen kuin aloitat valtavan projektin, viimeistele tärkeimpien sisältötyyppiesi (Tuote, Tarjous, Artikkeli, UKK-sivu) perusskeemamerkintä. Tämä ilmaisee selvästi agenteille, mitä myyt tai selität.
• Ainutlaatuisen sisällön korostaminen: Korosta aitoa arvoa, jota tekoäly ei voi kopioida, merkitsemällä todellisia käyttäjäarvosteluja (Arvostelu), tapaustutkimuksia (Tapaustutkimus) tai omakohtaisia kokemuksia (Kokemus) asianmukaisella skeemalla.

Kerros 2: Keskitaso (vuorovaikutus ja tietojen jäsentäminen)

• Yksinkertaiset interaktiiviset työkalut: Luo yksinkertaisia työkaluja, jotka ovat ominaisia kapealle yleisöllesi ja joita tekoäly ei voi kopioida. Nämä voivat olla laskureita (esim. lainalaskuri), tuotekonfiguraattoreita (esim. «sinulle sopiva näyttö») tai tietokilpailuja. Nämä työkalut muuttavat sivustosi «pysähdyksestä» «kohteeksi».
• Vain luku -API:t: Täysin toimivan verkkokaupan API:n perustaminen voi olla kallista. Ensimmäisenä askeleena luo yksinkertaisia, «vain luku» -API-rajapintoja, jotka jakavat tuoteluettelosi, hinnat ja varastotilanteen. Tämä on matalan riskin ensiaskel «agenttikaupan» maailmaan.

Kerros 3: Edistynyt (täydellinen integrointi ja omistusoikeudellinen arvo)

• Täysin toimiva API-arkkitehtuuri: Täysin integroidut API:t, joissa agentit voivat paitsi lukea tietoja myös suorittaa toimintoja, kuten ostaa, varata tai tilata. Tämä on «agenttikaupan» avain.
• Omistusoikeudelliset tiedot ja tutkimus: Vain sinulla oleviin alkuperäisiin tutkimuksiin perustuvat analyysit ja aineistot. Agentit eivät voi kopioida näitä tietoja; heidän on viitattava sinuun.
• Yksityiset asiantuntijayhteisöt ja portaalit: Alustat, joissa todennetut asiantuntijat käyvät arvokkaita keskusteluja tai henkilökohtaisia kokemuksia, joissa käyttäjät saavat palveluita omien tietojensa perusteella (esim. asiakaskohtaiset hallintapaneelit).