Talk by Patricija Žemaitytė (Oxylabs) on how web data infrastructure supports AI systems, told through three engineering case studies: rebuilding a search API to answer in under a second (reducing latency from a 4-second baseline to ~550 ms by optimizing layouts, parsers, sessions, and proxies after a live demo failure); a video API that grew from a two-week deadline and 5 PB/month minimum into a product suite including transcripts/subtitles, search, and metadata, with the client collecting 30 petabytes while remaining unpaid; and scaling an unblocker from 10,000 to 60,000 requests per second, where load testing hit a wall around 20,000 and telemetry itself became part of the measured load. The central argument is that web data infrastructure is an "adapt forever" business rather than a build-once one. # Channel Identity Observations — Video: "How Web Data Infrastructure Powers the Next Generation of AI — Patricija Žemaitytė, Oxylabs" ## 1. Explicit Self-Description (Creator Claims) - **Company self-description**: The speaker states Oxylabs "was established in 2015 and describes itself as a web intelligence platform and a premium proxy provider." - **Claimed scope of work**: > "we built infrastructure that allows companies to extract public web data at scale." - **Refined positioning claim**: Late in the talk, the speaker argues the stories show "we are not just a proxy provider," claiming the larger job is "building the infrastructure layer that allows companies to extract public web data... and operate it at scale." - **Business-model claim**: > "this is not a build-once business. This is an adapt-forever business" — positioning Oxylabs as absorbing "the messy maintenance underneath" so clients can "build the intelligence." ## 2. Speaker Role and Background (Stated, Not Inferred) - Introduces herself as **Patricija** (title renders "Patricija Žemaitytė"), a **product manager at Oxylabs**. - States her career path: > "I started actually closer to engineering. I was leading teams dealing with... core services," including a squad called "UX" (their internal usage, meaning unusual client requests with tight timelines). ## 3. Intended Audience - The talk appears addressed to a **conference/technical audience** interested in AI infrastructure: - Opens with "hello everyone" and a talk framing ("mostly I talk today starts with models. This one starts somewhere less glamorous with infrastructure"). - Assumes listener familiarity with AI concepts: retrieval pipelines, grounding, agents, training workloads. - Secondary implied audience: **AI companies / potential clients**, given the closing pitch: "you build the intelligence and we take the messy maintenance underneath." ## 4. Claimed Scope and Capabilities (with Evidence) - **Video AI-training data pipelines**: Client demand for "video API for AI training" at "at least 5 petabytes per month," delivered in "two weeks"; grew into "the whole video API suite that supported downloaders, transcripts, subtitles, channel information." - **Low-latency SERP delivery**: Fast search API delivering "550 milliseconds average latency"; scale "from 400 million daily requests to almost 6 billion daily requests." - **High-scale scraping**: Scaling a web unlocker "from 10,000 requests per second" to "60,000 requests per second and in less than 2 months," with an internal project "60" becoming "project 150." - **Claimed reliability/operations scope**: Handling "antibot systems," browsers, retries, normalization, delivery, observability, and load testing. ## 5. Observable Presentation Patterns (Demonstrated, Not Claimed) - **Narrative, story-driven format**: The talk is structured around three client-driven stories (video API, SERP latency, scale), each ending in a stated "lesson." - **Engineering-credibility style**: Concrete metrics (4-second baseline, 650ms P90, 20,000 rps wall), honest admission of failure (blocked during a client call: "we got blocked really bad"; client "did not test it out"; unpaid invoice: "we're still waiting for a payment"). - **Thesis framing**: Concluding claim that "the next generation of AI will not be powered by better models. It will be powered by better infrastructure around it" — the talk's central asserted viewpoint. ## 6. Source Notes and Uncertainty - Transcript is auto-transcribed with artifacts (e.g., "Patricia" vs. title "Patricija Žemaitytē"; "ev-" truncations); speaker name spelling taken from the title. - No curated metadata was supplied; all identity evidence derives from the title and transcript only. - All items above are either **directly quoted claims** or **observable presentation features**; no private motivation is inferred. # Delivery Observation: Patricija Žemaitytė, Oxylabs ## Overall Delivery Style - **Story-driven conference talk** structured as three sequential case studies ("stories"), each ending with an explicit lesson. - Conversational, candid tone with self-aware humor and admitted setbacks rather than polished marketing language. ## Recurring Phrases & Verbal Habits - **"So," as a sentence opener** — extremely frequent: "So, I work at Oxylabs", "So, my name is Patricia", "So, we had to start over", "So, what does Oxylabs do". - **"Actually" as a frequent filler/emphasis word**: "we actually made it", "this is really honest moment", "the real story happened on the next call". - **"And this is how / And this is where" as transitions**: "And this is how the first story started", "And this is where my story begins". - **Lesson framing**: each story closes with a stated takeaway — "the first lesson is really technical, but also very human", "So, the lesson of this part is that…", "So, the lesson from this part is also simple". ## Teaching Habits - **Concrete numbers throughout**: "Two weeks", "5 petabytes per month", "4 seconds average latency", "650 milliseconds P90", "400 million daily requests to almost 6 billion". - **Triadic repetition of the core thesis**: "adapting products, adapting architecture, adapting systems" — echoed again as "Infrastructure that can connect… infrastructure that can push… infrastructure that can scale". - **Dialogue re-enactment** of client/sales conversations: "What's the deadline? Two weeks. What's the scale?" and "So, client asked, 'Great that you have a downloader, but what about transcripts?'" - **Contrast pairs** to teach points: "a system that works in development, system that works in a test, and system that actually survives reality"; "In 4 seconds, you have a slow pipeline. In sub-second delivery, you have something that can sit and interact in your AI workflows." - **Plain-language glosses after technical statements**: "In simple terms, we built infrastructure that allows companies to extract public web data at scale." ## Humor & Candor - Dry, punchline-style reveals: "and we're still waiting for a payment." - Honest admission of failure: "But the story doesn't have happy ending here because client did not test it out." - Personification for effect: "browsers really wanted us to give us 4 seconds." ## Uncertainty Notes - The transcript contains transcription artifacts ("what became clay clear", "we have never built nothing like that"), so some word-level habits may reflect the transcript rather than the speaker. - Tone attributes beyond text (pacing, pauses, gestures) are **not observable** from this transcript alone. # Position Record: Patricija Žemaitytė, Oxylabs — "How Web Data Infrastructure Powers the Next Generation of AI" ## Speaker - **Patricija Žemaitytė**, Product Manager at Oxylabs (previously led core service engineering teams), per self-introduction in transcript. ## Core Thesis - The next generation of AI "will not be powered by better models" but by **better infrastructure around them** — infrastructure connecting models to fresh, real-time web data. - Training alone is no longer enough; models need live search and external data to stay useful. --- ## Company Positioning - Oxylabs, established **2015**, self-described as a **web intelligence platform and premium proxy provider**. - Her stated framing: Oxylabs is **not just a proxy provider** — the larger job is the infrastructure layer for extracting and operating public web data at scale (antibot handling, browsers, delivery, AI-system integration). - Value proposition: clients "build the intelligence" while Oxylabs takes on "the messy maintenance underneath." --- ## Story 1: Video API for AI Training - **Trigger:** Sales team returned from San Francisco with demand for a video API for AI training; **deadline: 2 weeks; scale: at least 5 petabytes/month**. - Claimed lesson: innovation "never comes as a neat road map. It comes as a pressure, as a deadline... as a trip report from San Francisco." - **Iterative build:** started as a downloader; client actually needed subtitles, not transcripts; then search by language, metadata, channel info; became a full video API suite in roughly 3 months. - **Unresolved tension (preserved as stated):** "It's 2026. Client already gathered 30 petabytes of data, and we're still waiting for a payment." - **Lesson:** clients don't buy the first iteration; "they buy your ability to adapt." ## Story 2: Sub-Second SERP Delivery - Context: SERP data previously used for analytics/SEO/monitoring; now feeds AI retrieval pipelines, grounds answers, powers agents. She cites Google's grounding documentation as positioning Search as a connection to current public knowledge. - **2024 request:** sub-second SERP delivery; baseline scraper was ~4 seconds average latency. They built it; client didn't test; market wasn't ready; shelved. - **2025 request:** zero data retention, sub-second latency, 2 weeks → redesigned from scratch; first version hit ~650ms P90 in under two weeks — **then got blocked during the client call itself**. - Stated distinction: a system that works in development vs. test vs. "survives reality." - Contradiction faced: sub-second target vs. reliance on browsers ("slow, expensive, complex, and deeply incompatible with dreams about low latency"). - Resolution: no magic trick — incremental time-hunting across layouts, parsers, sessions, proxies; "small decisions that add up." - **Result claimed:** fast search API at **550ms average latency**; scale moved from 400 million to nearly 6 billion daily requests — a "change in operating model," not just growth. - **Lesson:** in the AI era, speed defines what products can exist (slow pipeline vs. AI-interactive component). ## Story 3: Scaling Web Unlocker - Forced scale from ~10,000 to **60,000 requests/second in under 2 months** (internal project "60," now becoming "project 150" targeting ~100,000+). - Load testing hit a wall at 20,000 rps; the real bottleneck was **uncertainty**, plus observability at scale (telemetry itself becomes load). - Hardest part: **organic data testing** — traffic realistic enough to be informative; synthetic traffic "relatively easy comparing to reality." - Accepted truth: real testing had to be production traffic — "thankfully, that part actually went completely fine." - **Lesson:** "scale is never a finish line"; reaching one target means the next appears. --- ## Overarching Claimed Definition of Innovation > "Innovation is the ability to keep adapting fast enough that changing requirements become new infrastructure." - Web data extraction is "not a build-once business... an adapt-forever business" (targets, layouts, detection, market, and client needs all change). ## Final Position - "The model is not alone anymore. It already has bridge to it" — models need infrastructure linking them to live web data; Oxylabs positions itself as that bridge. # Speaker Attribution & Provenance Record ## Video - **Title:** How Web Data Infrastructure Powers the Next Generation of AI — Patricija Žemaitytė, Oxylabs - **Video ID:** `01a15ca7-f4a0-74ff-a922-0a47c2cb1f00` ## Speakers | Speaker | Role | Evidence | |---|---|---| | Patricija Žemaitytė (introduces herself as "Patricia") | **Creator / Presenter** — sole speaker; Product Manager at Oxylabs (formerly led core services engineering teams) | Transcript: "my name is Patricia... I worked... in Oxylabs as a product manager now" | - No **guests**, **narrators**, or other identified speakers appear in the transcript. - Non-verbal audio cue: `>>` markers and `[music]` at close — no attributed speech. ## Roles Referenced (non-speaking) - **Oxylabs sales team** — described as bringing the video API demand from San Francisco. - **Unnamed clients** — quoted/paraphrased requesters (video API, SERP sub-second delivery, scaling demands). Client identities not disclosed. - **Google** — cited via "Google's grounding documentation" positioning Search as a way to connect models to current knowledge (third-party claim, no document link provided). ## Promotional Segments - **Flagged:** The talk is structured around Oxylabs products; the opening ("I work at Oxylabs... web intelligence platform and premium proxy provider") and closing pitch ("you build the intelligence and we take the messy maintenance underneath"; "not just a proxy provider") function as **company/product promotion**, including named products: **video API suite, fast search API, web unlocker/scraper, proxy services**. ## Provenance Facts Recorded - Company founding claim: Oxylabs "established in 2015" — **speaker's own claim**, unverified. - Performance figures (4s baseline latency, 650ms P90, 550ms average, 400M→6B daily requests, 60k→150k requests/sec, 30 petabytes) — all **speaker-reported**, no external sources cited. - Client non-payment anecdote (2026, 30 petabytes, awaiting payment) — speaker claim, client unnamed. - No curated metadata supplied; **comment availability unknown**. \>\> Okay, hello everyone. So, mostly I talk today starts with models. This one starts somewhere less glamorous with infrastructure that decides whether those models get fresh, usable, real-time data at all. So, I work at Oxylabs and Oxylabs was established in 2015 and describes itself as a web intelligence platform and a premium proxy provider. In simple terms, we built infrastructure that allows companies to extract public web data at scale. And as we all know, public web data theoretically is available for everyone. But when you But in practice, if you want to connect your AI models, agents, databases, you need infrastructure layer. Uh so, this is what we do and this is where what matters now more than ever. Uh because the industry is shifting away from static knowledge and training itself still matters, of course. But training alone is no longer enough and to stay useful models needs to get access to fresh information, live search, real external data. And without that, even the smartest model is limited by what it knows. And this is where my story begins. So, my name is Patricia and as I mentioned, I worked as uh in Oxylabs as a product manager now. But I started actually closer to engineering. I was leading teams dealing with service, core services. But the first squad that actually taught me one thing was what we called UX. Uh and what is UX? UX is usually means user experience. That is completely correct. But for us, that often meant closer to this, that client needs something really unusual. There is no ready-to-made product. The timeline is extremely painful, and somehow we need to build everything fast and make it work beautiful. So, the lesson that I learned with that team, that innovation never comes as a neat road map. It comes as a pressure, as a deadline, and sometimes, and quite often, as a trip report from San Francisco. And this is how the first story started. One day, our sales team came back from San Francisco and said, "There is a demand for video API for AI training." Um there is one question that you actually really scared to ask the sales team. What's the deadline? Two weeks. What's the What's the scale? At least 5 petabytes per month. At that point, we have never built nothing like that, and it seems a lot. And actually, this is also a moment when the feature stops sounding less as a product feature. It sounds like infrastructure, because what client actually is asking to build is not just to download some videos. They are asking for a pipeline, collection, transfer, storage, delivery. And do it with enough reliability that would be compatible with AI training workloads. So, that story actually aged surprisingly well, because the market has moved exactly into that direction. And AI infrastructure is becoming increasingly more multimodal. It's no longer about the text, and companies now need pipelines for video, metadata, transcripts, subtitles, and another structural context around the content itself. So, what with that? So, in two weeks, we had to build a new dedicated scraper with a brand new logic, new storage integrations, and with delivery flow of something that we actually never built before. And we actually made it, and somehow we made it even on time. But, this is not where the actually story ended. That was only the version one. So, client asked, "Great that you have a downloader, but what about transcripts?" So, we built a transcript support. Uh client tested out, and we see that all of the requests are failing. Then we start talking with the client, and we see that there is nothing that we did something wrong. That client actually didn't need a transcript, they needed the subtitles. So, we adapt again. We build a subtitle support. Um then another request comes. "We are struggling to find videos in languages that we actually need. Can you build a search that we could gather those ideas?" So, we do it again. "What about metadata?" Of course, we do it once again. And this is the part of the story that I really loved, because once it started as a one product feature request, it actually became um became the whole product suite, because we started thinking that we're building just a downloader. Then we realized that we're building a transcript support, subtitle support, uh adding metadata, channel information, and ended up building our own internal library that glues everything together. And after enough iterations, uh as a one as I mentioned that started as a one-off time request, uh it became the product family. And in roughly 3 months, we actually ended up having the whole video API suite that supported downloaders, transcripts, subtitles, channel information. And yeah, after all of this, the final twist came. So, it's 2026. Client already gathered 30 petabytes of data, and we're still waiting for a payment. So, yes, the first lesson is really technical, but also very human. Uh that innovation is actually a repeated adaptation under high pressure. Because once you learn that the client actually doesn't buy the first product iteration, they buy your ability to adapt. The next question becomes, can you actually make it under extreme latency constraints, too? And this is a part where I tell you a little about SERP data. And search data has always mattered. But the AI changed the role it plays. Um before, SERP was often used for analytics, SEO, monitoring, market intelligence. But now, it's a huge part of AI systems. It feeds retrieval pipelines. It grounds uh it powers assistance. It grounds answers. It helps agents interact with live information instead of stale training memory. And that shift is not hypothetical. Google's grounding documentation explicitly positions Google Search as a way to connect models to current public knowledge. In simple terms, the model layer is increasingly expected to work with live retrieval layer around it. And that's why the next request mattered so much. So, back in 2024, client came and asked for SERP delivery with sub- sub-second SERP delivery. At that time, our traditional regular search scraper was around 4 seconds average latency. So, the gap was huge, but we still decided to go for it just to see if it's possible and we actually did it. But, the story doesn't have happy ending here because client did it not did not test it out. And to be honest, the market wasn't ready for that. So, we just put it on a shelf. But, what became clay clear later on that was never about making uh the old scraper faster because the regular scraper, what he does here is built to retrieve as much information as possible. So, we're talking ads, widgets, rich results, AI-generated results, different layouts. And when we think about fast search API, it takes a different approach. It focuses on the things that actually matters only for AI systems. So, it's mostly organic results, top stories, news, and it cuts away all the heavy layout. So, even this small scope, it's already something to start thinking about lower latency. So, fast forward, it's 2025. Another client comes in and their request was simple: zero data retention, sub-second latency, and 2 weeks. For us, that meant to support different geolocation and query parameters, to have a system that is capable to deliver results under 800 milliseconds, and to have a solution that is ready uh to be tested out in less than 2 weeks. So, when your baseline is at 4 seconds, we are not talking about optimization. We are talking about redesign. Uh so, we started from the scratch. And actually, the first version worked. In less than 2 weeks, we got around 650 milliseconds P90. So, that alone would be a great story, but the real story happened on the next call. So, we're sitting on a call with the client getting ready to test it out our new product. And while we were on the call, we got blocked. And we got blocked really bad. And to to be honest, this is really honest moment about when you think about infrastructure and systems, because this is a kind reminder that there is a difference between system that works in development, system that works in a test, and system that actually survives reality. So, we had to start over, because nothing worked. And at this second iteration was the hardest one, because we actually had to rely a lot on browsers. And don't get me wrong, browsers are amazing. They are extremely useful, but browsers also are slow, expensive, complex, and deeply incompatible with dreams about low latency. So, there is So, we had a contradiction. The reality and the client wanted sub-second, the reality needed browsers, and browsers really wanted us to give us 4 seconds. So, at this point, there is no magic trick. You just go hunting for a time. So, you you review everything, layouts, parsers, sessions, proxies, every place when you can cut off a second, a two, a three, or four. And this is how systems becomes fast, not by giant breakthroughs as we thought at first, but by small decision that adds up. And that work paid off and actually evolved into something new. So, today we have fast search API that delivers results and fresh data directly into AI workflows with 550 milliseconds average latency. And our scale move from 400 million daily requests to almost 6 billion daily requests. Uh so, that number matters. Because going from 400 million daily requests to 6 billion daily requests is not just a change, not just a growth. It's a change in operating model. It changes how you think about costs, observability, and failure of domains. So, the lesson of this part uh that in AI era, speed is not just performance. Speed actually defines what product can exist. Because in 4 seconds, you have a slow pipeline. In sub-second delivery, you have something that can sit and interact in your AI workflows. So, when a speed becomes product, what's next? Next is then scale actually becomes the real test. So, the first story was about mm adapting product scope. The second was adapting architecture for latency. The third one is going to be adapting systems for scale. And the scale is where infrastructure becomes really humbling. At one point, another demand has forced us to scale our web and blocker quite aggressively. Uh I added just slides just to see how it works. Uh it's simple terms, it's similar to scraper, but it has proxy integration. So, we were working our way around 10,000 requests per second. Demand has forced us to scale to 60,000 requests per second and in less than 2 months. So, now that number alone sounds impressive, but it might be also misleading misleading if if you are thinking about as as a simple HTTP request. In our world, that means the end-to-end scraping job. Part uh it it will be routing, rendering, proxy handling, browsers execution, parsing, retries, normalization, and delivery itself. So, when you kind of scale to that workload, even adding up additional 2,000 servers doesn't solve the problem. You need an architecture. You need a central components that actually are reliable. You need observability that still tells you the truth. And you need testing that resembles ev- uh reality enough to matter. And this is where our main bottleneck showed up, not in dramatic outage, in load testing. Uh the hardest part was not generating synthetic traffic. Synthetic traffic is relatively easy comparing to reality. Uh but the hardest part, organic data testing. That means processing traffic that behave enough like real client usage to tell us something useful. And during one of those load tests, we hit the wall around 20,000 requests per second. At that point, there is no question if the system is actually working. It is working. The question becomes, do we actually know that it can go further? And that uncertainty was the real bottleneck. So, uh so are all the pain points, metrics, logs, and generating and processing everything at scale. So, everybody loves observability in theory, but observability at scale becomes a true work because collecting logs is hard, processing logs is harder. Um and same applies to metrics. Uh they're essential, but when you scale up to that kind of a load, the telemetry itself becomes a part of the load and a part of the complexity. So, what we did? We scaled gradually. And eventually, we had to accept one unavoidable truth that the real testing is going to be with production traffic. And thankfully, that part actually went completely fine. Uh but the story doesn't end up here uh because the drama is still happening right now. Uh internally, we call this project 60 because we had to scale up to 60,000 requests per second. Now, it's already becoming project 150. So, while we were scaling our infrastructure to 60,000 requests per second, now we are talking and seeing results and scale up to about to about 1 100,000 requests per second. So, the lesson from this part is also simple that the scale is never a finish line. Well, at least not for us. And probably when you reach one target number, the next one will appear. So, anyways, what does Oxylabs do in this whole thing? The I guess the stories make one thing quite clear that we are not just a proxy provider. Proxies are essential, they are important, but the hardest part and the larger job is building the infrastructure layer that allows companies to extract public web data up and and operate it at scale. That means reaching the open web, collecting data reliably, dealing with antibot systems, handling browsers when they are needed, instruction and delivering data, and doing in that manner that AI companies can actually plug into their systems. And this is exactly why it matters because the best thing we can offer is not just data access, it is this. That you build the intelligence and we take the messy maintenance underneath because the messy part is is is real. The targets change, layouts change, detection changes, market itself changes, client needs changes. So, this is not a build-once business. This is an adapt-forever business. And honestly, that may be the most useful definition of innovation that I know. That innovation is the ability to keep adapting fast enough that a changing requirements becomes a new infrastructure. So, if I need you to leave with one thought today, I will probably get back where it started. That the next generation of AI will not be powered by better models. It will be powered by better infrastructure around it. Infrastructure that can connect models to reality, infrastructure that can push the web data directly into your pipelines, databases, agents, AI tools, infrastructure that can scale from 400 million daily requests to 6 billion daily requests. Because this is really the story. Not just scale, not just scraping, not just speed, adaptation. Adapting products, adapting architecture, adapting systems. And doing it fast enough that the AI companies and you can keep on building while the maintenance burden stays with us. So, and this is what it actually means for me in AI world. It means that the model is not alone anymore. It already has bridge to it. Thank you. \>\> \[music\]