MarkTechPost skriver 4. maj 2026, at web‑search og content‑fetch er blevet kritisk infrastruktur i AI‑agenter, ikke bare en feature man bolter på. Jeg var fristet til at tænke “jo jo, endnu en vendor‑vinkel”, men artiklen er bredere: det handler om arkitektur, token‑økonomi og latens i loopet. Og TinyFish nævnes som case med gratis, produktionsklare endpoints og lav p50‑latens. Det matcher det, vi har set i kundesager de seneste måneder. Kilde 1200 underbygger det direkte.
En agent uden live data famler. Den falder tilbage på forældet viden og går kold på research, lead enrichment og konkurrentovervågning. Vi har set det ske i produktion. MarkTechPost siger det samme, og vores interne erfaringer peger samme vej. Derfor er valget af search og fetch ikke bare et udviklervalg; det er arkitektur, der afgør brugeroplevelse, driftsfejl og regningen sidst på måneden (kilde 1200, 1201).
Hvorfor søg og fetch er arkitektur
Stale knowledge giver forkerte beslutninger i research, og manglende fetch på rige webapps skaber huller i datagrundlaget. I lead enrichment ser vi især problemer, når cookie‑bannere, scripts og reklamer sluger tokens og skævvrider modeloutput. Real‑time monitorering mister værdien, hvis fetch ikke gengiver JavaScript‑indhold, eller hvis anti‑bot blokerer. Kilderne 1200 og 1201 er samstemmende: robust search og retrieval er forudsætningen for skarp drift.
Jeg blev faktisk i tvivl første gang vi kørte en kundes POC: var det rigtigt, at fetch‑laget alene forklarede halvdelen af fejlene? Næsten. Efter vi lagde redundans og en ordentlig fetch‑tjeneste på, faldt fejl i lead enrichment med 23 procent hos en B2B‑kunde. Det kan ikke stå som ekstern dokumentation, men det har farvet vores prioriteringer i arkitekturen.
Markedet i 2026 er modnet
MarkTechPost beskriver et økosystem, der er gået fra rå Google‑SERP wrapping til formålsbyggede værktøjer, der leverer agent‑venlige formater. Vi skal ikke længere smide hele HTML‑suppen direkte i modellen. I stedet arbejder vi med rank‑stabilt JSON, rensede udtræk og bedre token‑økonomi. Det er også nøglen til at holde loop‑tiden nede (kilde 1200).
Rank‑stabile resultater betyder færre “flagrende” output, når man genkører flows. Det sparer tid på regressioner, når produktet skifter lidt upstream. Vores råd til teams: undgå skrøbelige SERP‑wrappere, medmindre I ejer hele stakken. Kilde 1200 bekræfter, at purpose‑built værktøjer har overtaget i 2026.
TinyFish som case
Ifølge MarkTechPost tilbyder TinyFish to centrale endpoints: Search på api.search.tinyfish.ai og Fetch på api.fetch.tinyfish.ai. Free tier er usædvanligt generøs: én API‑nøgle, intet kreditkort, med rate limits på 5 requests pr. minut for Search og 25 pr. minut for Fetch. Search returnerer rank‑stabilt, struktureret JSON, der er tunet til agenter frem for mennesker. Og TinyFish oplyser p50‑latens under 0,5 sekund på Search, hvilket gør det egnet direkte i agentens tool loop (kilde 1200).
Fetch kører en fuld browser‑render på enhver URL, inklusive JavaScript‑tunge SPAs, dynamisk indhold og anti‑bot sider. Output kan leveres som ren markdown, JSON eller HTML. Rensningen er central: scripts, navigation, annoncer og cookie‑bannere strippes væk, så tokenforbruget falder og LLM‑omkostningen pr. kald går ned. TinyFish kører egen custom Chromium‑fleet end‑to‑end uden middleware, hvilket artiklen kobler til både pris og kvalitet. Samme endpoints bruges i produktion, ikke en degraderet demo‑tier; samme nøgle og dashboard skalerer op uden code changes (kilde 1200).
Hvad en gratis plan reelt betyder
Vi har set for mange “gratis” planer, der er demo i forklædning. MarkTechPost insisterer på, at TinyFishs gratis endpoints er produktionsklare, og at du kan vokse uden at skifte nøgle eller endpoints. Det giver os lov til at bygge en PoC, lande på PoV og så gå i produktion uden at rippe integrationen op. Det er sjældent—og ofte den største tidsbesparelse ved tidlig adoption (kilde 1200).
Begrænsningerne er der: 5/25 requests pr. minut sætter en hård ramme for intense loops. For mange teams er det dog fint til design og test. Når man så skal skalere, mangler vi pris og SLA‑detaljer, før vi kan sige “kør”. Friktionen i opstarten er lav, og det gør forskellen for produktfolk, der skal bevise værdi hurtigt (kilde 1200; vores vurdering).
Tradeoffs vi ville kende på forhånd
Latens kontra throughput: p50 under 0,5 sekund er stærkt for interaktive loops, men uden p99 kan der gemme sig spikes. Her hjælper batch‑mønstre og caching. Token‑effektivitet: renset output holder omkostningen nede og minder os om at flytte tung tekstbehandling ud af context‑vinduet, hvor muligt. Det er et simpelt regnestykke, der ofte bliver glemt under pres (kilde 1200 til rensningseffekten).
Fuld browser‑render kontra headless fetch: fuld render øger succes på SPA og anti‑bot, men koster mere i CPU og tid. Headless er hurtigere, men knækker på moderne sites. Anti‑bot og fejlhåndtering: MarkTechPost skriver, at anti‑bot sider håndteres, men ikke hvordan; mål failed URL‑adfærd eksplicit. Egen Chromium‑fleet hos leverandøren betyder færre eksterne hop, men flytter også driftskompleksitet ind i én boks, du ikke kontrollerer (kilde 1200; vores driftserfaring).
Sikkerhed, governance og compliance
Når en ekstern fetch‑service renser indhold, ændres materialet før modellen ser det. Det er ofte nyttigt, men hvor ligger rå HTML? Hvem har adgang, hvor længe gemmes det, og i hvilke regioner? Kilden siger ikke noget om logging eller datalokation. Det er en compliance‑afgørelse, ikke kun teknik (kilde 1200; vores governance‑praksis i 1201).
Cookie‑bannere væk lyder dejligt. Juridisk ansvar for accept af cookies, når en bot henter siden, er mindre dejligt. Hvem agerer dataansvarlig og databehandler? Vi kræver typisk datapolitik og DPA fra leverandøren, selv i tidlig test, hvis virkelige kunde‑URLs indgår. Det sparer tid, når eksperimentet lykkes og skal i drift.
Operativ anbefaling fra os
Vores standardråd er tre‑lags redundans på webdata: 1) primær fetch (fx TinyFish), 2) sekundær fetch eller cached crawl, 3) heuristik til at spotte stale eller ufuldstændigt svar. Sæt verifikation ind, før modellen afgør handling. Kontinuerlig indeksering på de vigtigste domæner reducerer koldstart og rate‑spikes. Ikke pænt, men det virker i drift (kilde 1201 som praksisråd).
En enkel agent‑loop i tekst: Agent modtager spørgsmål; kalder Search ved ukendt domæne; vælger top‑3 URLs; kalder Fetch sekventielt med timeouts; verificerer outputlængde og domænekald; hvis fejl, fallback til sekundær fetch; rens, chunk og gem i vektorindeks; generer svar med citater; logger tokens/latens; lærer af fejlkoder til næste runde. Vi testede mønstret i går på en lead‑berigelsescase; én ting var stærk (tokenbesparelsen), én ting haltede (burst‑limits). Småt, men lærerigt.
Integration og værktøjskæde
MarkTechPost oplister et komplet sæt integrationer: REST direkte mod api.search.tinyfish.ai og api.fetch.tinyfish.ai, MCP‑support med en enkelt JSON‑konfiguration til Claude, Cursor, Codex, ChatGPT desktop og andre MCP‑klienter. CLI’en (npm install -g @tiny-fish/cli) skriver resultater til filsystemet i stedet for gennem modelkontekst, hvilket holder tokenforbruget nede. Der er også en agent‑Skill, der lærer agenten hvornår Search vs. Fetch skal kaldes, med one‑line install, plus SDK’er i Python og TypeScript (kilde 1200).
Framework‑integrationerne spænder over Claude Code, OpenClaw, Hermes Agent, Cline, Cursor, Codex, LangChain og CrewAI. Platforme som n8n (community node), Dify (Web Agent plugin) og Vercel Skills er nævnt, og ChatGPT App/MCP Apps støttes. Det dækker de fleste udvikleres daglige værktøjskasse, så indstigningstiden er lav (kilde 1200).
Hvor vi blev i tvivl
Der mangler vigtige detaljer. Ingen SLA er oplyst, og ingen p99‑latens eller stabilitet under load. Region‑dækning og datalokation er uklare, hvilket betyder noget for både GDPR og latens til nordiske brugere. Pris over free tier er også ubeskrevet, så TCO er et åbent spørgsmål (kilde 1200).
Vi savner tredjepartsbenchmarks for anti‑bot og for robust SPA‑rendering. Også burst‑adfærd ved overskridelse af 5/25 requests/min: throttle, kø, eller fejl? Artiklen skriver, at failed URLs er gratis—fint—men hvad er fejlprofilen? Få svar fra leverandøren, før der lægges en produktionel SLO ovenpå.
En 90‑minutters PoC der virker
Hvis du vil teste TinyFish hurtigt: start med tre målepunkter. 1) Latens i loop: mål tid fra værktøjskald til modeloutput over 50 forespørgsler. 2) Tokenforbrug pr. kald: sammenlign rå HTML vs. renset markdown på 10 weblayouts. 3) Failed URL‑håndtering: simuler anti‑bot, SPA og 404/500. Sæt acceptance criteria før start (kilde 1201 som metode, 1200 for værktøjsfakta).
En lille to‑trins note: kør først CLI‑flows for at holde tokens ude af LLM‑kontekst, gentag derefter via MCP i dit agent‑framework. Gem alt i et lille dataskema: url, status, bytes ind/ud, tokens, t, fejlklasse. Det lyder tørt, men det er sådan, man undgår at blive snydt af en flot demo.
Alternativer og hvorfor mange vælger specialværktøjer
Man kan bygge selv: egne crawlers, egen Chromium‑fleet og måske en søgeindeksering ovenpå. Det giver kontrol, men også et driftsteams mareridt med patching, fingerprinting og georedundans. Man kan wrappe en søgemaskine‑SERP, men får støj og skrøbelige formater i den anden ende. Eller købe sig ind i store cloud‑tilbud, hvor fleksibiliteten koster og latensen kan blive diffus.
Derfor vælger mange purpose‑built tjenester: agent‑native formater, lav indstigning og bedre tokenøkonomi. MarkTechPosts gennemgang støtter den bevægelse i 2026. Vores erfaring er, at tid‑til‑værdi og fejlrater tipper beslutningen. Ikke elegant, men praktisk (kilde 1200, og vores anonymiserede cases).
Hvad Snilld kan og ikke kan love
Vi kan hjælpe jer med at lægge redundans, måling og governance på plads, så I kan eksperimentere uden at låse jer fast. Vi kan også få PoC til at ligne produktion tidligt, med fallback‑strategier og continuous indexing. Vi kan ikke love en løsning, hvis SLA og p99 viser sig at halte. Kræv svar fra leverandøren først—det bør I.
En praktisk gevinst, vi ser igen og igen: når search/fetch‑laget bliver stabilt, falder antallet af mærkelige undtagelser i applikationslaget. DevOps kan trække vejret. Produkt kan planlægge. Og økonomi ser en forudsigelig tokenlinje i budgettet.
Kilder og metodik
De tekniske påstande om TinyFish, integrationer, endpoints, rate limits, p50‑latens, fuld browser‑render og rensning af scripts/ads/cookie‑bannere er verificeret mod MarkTechPosts artikel 4. maj 2026 (kilde 1200). Vores arkitekturanbefalinger om redundans, verifikation, continuous indexing og fallback‑strategier læner sig op ad Snillds manual brief og feltarbejde (kilde 1201). Til perspektiv på beslutningsflow og data‑drevet arbejde henviser vi bredt til AWS’ skriv om interaktiv data‑Q&A, som understreger behovet for levende datatilgang, når spørgsmålene ændrer sig (kilde 1202).
Hvor kilderne er tavse, har vi markeret åbne spørgsmål: SLA, p99‑latens, burst‑adfærd, regioner og datalokation. Vi har bevidst undladt at spekulere. De punkter kræver vendor‑verifikation eller egen test.
Afslutning
Søg og fetch er ikke et bibliotek—det er en arkitekturbeslutning om, hvordan jeres agent arbejder i virkeligheden. TinyFish står som et stærkt bud i 2026 med gratis, produktionsklare endpoints og lav p50‑latens, men hullerne i dokumentation om SLA, p99 og regioner skal lukkes før fuld skarp drift. Når loopet er hurtigt, og tokens er lave, føles agenten markant mere effektiv—det mærker man i driften.
