M
Magdalena Śleboda
Head of Operations | Scaling Tech Organizations with AI, Automation & Data-Driven Execution | Global Ops & Transformation Leader
2 days ago in External Development Summit (XDS) starts next week.
I’ve already introduced the panel I’m in: AI in External Development —Policy, Risk, and Reality. Feel free to sign-up on Wednesday, if there are any seats left.
We’ll be talking about AI off the stage, too, but I’m also going to other table-topics and panels to explore:
- how vendors and developers are rebuilding their business models for the AI era
- where the gaming industry is actually heading, what the current trends are
- how studios and external partners are working together right now
- what needs to change in ex-dev - sustainability, margins, survival
I'll come back next week with whichever one surprised me most.
The main reason everyone flies to Vancouver is the networking and what happens in the Connect meeting zone. So if you're going to be there and want to go deeper on any of the above - hit me up to connect.
#xds2026 #gamedev
View on LinkedIn
Damian Naglak
Head of Engineering | Bedrock Platform | AdTech
3 days ago in A user agent string is supposed to say which browser made a request. Most of what it actually contains describes browsers and engines that aren't the one running, kept alive as compatibility credentials for three decades.
A user agent string is meant to carry the browser, its rendering engine, the operating system, and a version number, sent automatically on every request. A newer field, sua, is meant to carry a more honest structured version, built from data the browser only shares if asked, and only on the next request. OpenRTB's spec recommends sua over the plain string when both exist, since the plain one can be frozen or reduced. sua also carries a field marking where its data came from, and since Safari and Firefox never adopted the mechanism that would make it genuine, that value is often just the old string, parsed and reshaped to look tidier.
The reason goes back to 1995. Netscape's browser identified itself as Mozilla, and sites checked for that word before serving the full page. When Internet Explorer 2 shipped that year, it started sending Mozilla too, so it wouldn't get the downgraded page. Every browser has kept the trick since.
The format itself isn't even consistent. Browsers and mobile apps mostly send that same layered string, since they run real browser engines underneath. CTV splits in two: some platforms send their own short device string with no browser claims at all. Others run an actual browser under their interface and produce the identical Mozilla, WebKit, Safari chain a phone would. Three conventions, depending only on what's asking.
The same identification problem is showing up again, one generation newer. GPTBot, ClaudeBot, PerplexityBot, and Google-Extended are real, distinct strings site owners write rules against, commonly blocking the ones built for training while letting the real-time answer ones through. Research from January 2026 already found some AI agents using those exact strings to get past the blocks.
An IETF draft called Web Bot Auth, backed by engineers at Cloudflare, Google, and Amazon, replaces the self-reported string with proof. A bot signs each request with a private key only it holds, and publishes the matching public key at a known address. A server checks the signature against that public key: a match proves who sent it, anything else proves nothing. A text string can be typed by anyone, a signature only by whoever holds the private key. Cloudflare already runs a version of it, though the standard itself is still a draft, not yet adopted.
As a field for saying what's actually making a request, user agent is unreliable. Every other identifier in this series gets patched by someone, privacy extensions, sync mechanisms, truncation policies. This one has a patch too, and most of what claims to be patched is really just the old string, reshaped. The approach that might work doesn't patch it at all, it stops asking the field anything and checks a signature instead.
Bedrock Platform
View on LinkedIn
M
Michał Nieć
CEO of Appliscale | AI in AdTech Expert | LP & Angel Investor in AdTech/GameTech
3 days ago in ChatGPT ads just went from “interesting experiment” to a $1B annualized business.
On August 31, OpenAI said its advertising business had reached a $1B annualized revenue run rate, less than 200 days after the first paid ads launched in the US. At that run rate, we're talking about roughly $83M of monthly ad revenue.
The more interesting number is the slope.
OpenAI says the ads business was around $100M ARR after ~6 weeks, with roughly 600 advertisers. By August, it had reached $1B ARR and tens of thousands of advertisers across 40+ countries.
That's roughly a 10× increase in run-rate in five months (!).
And there is a technical story underneath the revenue story.
OpenAI has had to build most of an advertising stack from scratch in roughly half a year: Ads Manager, CPC and outcome-based bidding, conversion tracking, product feeds, geo targeting, custom audiences and integrations with 50+ measurement and technology partners.
The inventory is also unusual.
Ads appear below responses for Free and Go users, while Plus, Pro, Business and Enterprise remain ad-free. That puts advertising directly next to what is arguably the highest-intent consumer interaction on the internet: someone asking an AI to help them decide what to buy, where to go, what software to use or which product to choose.
And this is where I think the next interesting competition will be: how much of the advertising stack can move from predicting intent to observing intent?
View on LinkedIn
M
Michał Nieć
CEO of Appliscale | AI in AdTech Expert | LP & Angel Investor in AdTech/GameTech
4 days ago in Over the weekend, X got taken over by “Infinite Slop” - a live stream where people type prompts and AI generates the next video in the sequence.
The reason this suddenly became possible is a very specific performance threshold.
On August 27, fal.ai released H3 Max, a post-trained and inference-optimized version of MiniMax H3. At 768p, it can generate 5 seconds of video in under 3 seconds. fal reports roughly 35× the throughput of the official H3 endpoint (Design Arena measured more than 50× the speed of the original model at comparable quality).
That means generation is now faster than playback.
It sounds like a benchmark detail, but it changes the system you can build around the model.
Previously, a video model looked roughly like: prompt → wait → video → watch → repeat
If a 15-second clip takes several minutes to generate, you can't really make it the engine of a live medium.
With sub-real-time generation, you can generate the next scene while the current one is playing. Add a queue, some state and an input channel, and you have a continuous stream.
That's basically what InfiniteSlop.ai does. Pieter Levels connected H3 Max to a live interface where chat messages influence the next generation and the model tries to connect it to the previous clip. Levels reported 37,000 viewers on August 30.
The output is obviously rough. Characters drift, scenes don't reliably connect and most prompts produce nonsense. But that's almost useful for the experiment because the demo is testing the system property rather than the quality of the final product.
Future? Interactive stories, generative games, live virtual characters, audience-controlled broadcasts, dynamic advertising.
(Of course there is also a new constraint: Infinite Slop can receive more prompts than it can put on screen so at some point the problem becomes deciding which input gets compute, when to generate it and how much context to carry forward)
H3 Max is still limited to 768p, and the continuity between generations is primitive. The standard price is also moving to $0.08/sec after the launch promotion.
But the underlying threshold is worth paying attention to:
For most of the history of digital advertising, we’ve optimized the path from an impression → a decision → an asset being served. Milliseconds matter because the decision has to happen before the user moves on. Generative video has operated on a completely different timescale. You generate the asset first, then serve it so interesting thing about H3 Max is that it starts to blur that boundary?
View on LinkedIn
Damian Naglak
Head of Engineering | Bedrock Platform | AdTech
5 days ago in Device ID can go missing, and so can a cookie. An IP address almost never does, which doesn't make it any more stable.
An IP address is a routing address: a network location for delivering a packet, not an identity. It only has to be right long enough for one delivery, nothing about it was built to stay attached to a person over time.
NAT is the trick a router uses to let many devices share one address, and CGNAT is the same trick run by the carrier instead of your router. It's driven by plain IPv4 exhaustion, only about 4.3 billion IPv4 addresses exist and none are left to hand out, and it's standardized, not a workaround: internet technical standards require these devices to limit how many connections each subscriber gets. Ordinary office or cafe WiFi does the same sharing through plain NAT: one documented setup showed a single device supporting up to 8,000 people before its roughly 60,000 connection slots ran out. A VPN's exit server runs the same trick, just chosen by the user instead of assigned by a carrier. The address itself isn't fixed either. It changes on lease renewal, a router restart, or just moving networks, home WiFi to mobile data.
IPv6 has its own churn built in, and there's a real reason for it. Left alone, IPv6 can build a device's actual hardware address into the address itself, the same value on every network it joins, letting anyone who sees the traffic recognize it across networks and even read the manufacturer off part of it. Privacy extensions exist specifically to cover that up, swapping in a fresh, randomized address roughly every 24 hours instead, standard across every major modern operating system.
Some exchanges blur it further on purpose. IPv4 gets its last number zeroed before a buyer ever sees it, confirmed against real traffic. IPv6 gets wiped down to a fixed size too, and that doesn't reliably hide anyone. How much ground that covers depends on how the ISP handed the block out, and plenty give one household exactly that size on its own. So the wipe can look like it blurs several homes together when it is really just one house's address, untouched.
The same address also gets used to guess where someone is, and that guess was never precise either. The databases behind it describe a circle with a radius from 5km to hundreds of km, not a point, warning against reading it at street level. Starlink is a clear example: its own support documentation notes the IP-based location can be off by entire states, because the address reflects wherever the connection surfaces at one of its data center hookups, not the dish itself.
Cap on an IP address and you will almost always have something to count against. Sharing, churn, deliberate blurring, and geolocation that was never precise all mean it rarely points at the same person twice. It is part of why linking an IP to a specific person downstream is so hard too, because that work is built on a foundation that keeps shifting under it
Bedrock Platform
View on LinkedIn
M
Michał Nieć
CEO of Appliscale | AI in AdTech Expert | LP & Angel Investor in AdTech/GameTech
5 days ago in There are a hundred newsletters that will tell you about the "future of advertising." We decided to write one about the actual plumbing.
Together with our Damian Naglak and the team at Appliscale we launch our weekly Substack newsletter: The Frontier.
We have spent 11 years building RTB platforms, containerized bidders, agents and identity pipelines that process tens of billions of impressions a day. So we are writing it by ourselves and for ourselves.
The Frontier covers Ad Tech and the AI agents moving into it. No fluff. No trend takes. Just the exact engineering reality of what breaks when an LLM gets near a bid path.
Every week on Tuesday, you get four things:
1) A Deep Dive written by someone who actually built the system
2) 5 News Items that matter, with the technical mechanism explained
3) The Number: One specific industry stat, unpacked
4) The Signal: A slow-moving shift that might dictate your roadmap in six months
Sign up here: appliscale.substack.com
View on LinkedIn
Damian Naglak
Head of Engineering | Bedrock Platform | AdTech
1 week ago in To count the same person twice, for a frequency cap or a retarget, you need one identifier that holds still across visits. The cookie was the original answer, and you have probably heard it is disappearing. Here is what that means: five separate places it can fail.
Quick refresher: a cookie is a key/value pair set through a Set-Cookie response header, stored in the browser, then sent back automatically on every later request to that domain. Netscape invented it in 1994 to remember a shopping cart between page loads, one small job. The industry built an entire identity layer on top of it anyway.
First gate: does the browser even allow it. Safari has blocked third-party cookies since 2017, Firefox since 2019. Chrome still allows them, and Chrome alone carries roughly 65% of global traffic this year, more than every other browser combined.
Second gate: does the law allow it. The EU, UK, Brazil and China run opt-in, nothing fires until the user says yes, and GDPR gives cookie storage no fallback to legitimate interest, only consent. The US runs opt-out instead: a cookie fires by default until the user objects. Twelve states now legally require honoring that objection when sent as a browser signal.
Third gate: this is called cookie syncing, buyer and seller platforms exchange their own cookie IDs with each other so they can recognize the same person under two different values. It isn't a standing connection, it has to keep re-happening: sync only completes when the seller's tag actually calls the buyer's sync pixel during that one page visit. Miss that call and nothing happens until it lines up again on a later visit.
Fourth gate: even synced, it dies fast, by design and by accident. Every cookie carries a built-in expiry, and Chrome caps it at 400 days no matter what's requested. Some carry no expiry at all, a session cookie, and vanish the moment the browser closes. Users clear browsing data.
Fifth: even alive, a cookie identifies a browser, never a person, in both directions. The same person on a phone, a laptop, and a work desktop becomes three unrelated IDs. A shared family or library computer collapses several people into one.
A less obvious version of the same problem, and a growing one given how much traffic now starts inside a social app: Instagram, TikTok and Facebook open links in their own isolated browser rather than the phone's, keeping the whole experience inside the app's own branded view instead of risking someone bouncing to the standard browser and not coming back. That isolated view keeps its own separate cookie jar, disconnected from the real browser's, so the same person looks like a stranger clicking from inside the app.
Cap on a cookie and you're only capping the slice that survived every gate: the browser, the law, the sync, the clock, or the device can each leave you counting a stranger.
Bedrock Platform
View on LinkedIn
M
Michał Nieć
CEO of Appliscale | AI in AdTech Expert | LP & Angel Investor in AdTech/GameTech
1 week ago in According to OpenRouter in February 2026, agentic token usage officially surpassed human usage. Fast forward to August, and human usage grew 2.8x. Agentic usage grew 14x (!) meaning agents are currently burning 7.3 trillion tokens / week just on this one platform.
One could say "The Internet is no longer for humans" or that "dead Internet theory" is not a theory anymore. But apart from that, it is clear that autonomous agents talking to other autonomous agents in endless loops, reading massive codebases, and parsing databases is not a distant vision anymore.
If your API rate limits are configured for human clicking speed -> these agents will DDoS your servers by lunchtime
If your database structure isn't optimized for machine-readable context -> agents will burn millions of tokens just trying to understand your schema
If you aren't strictly monitoring the cache read costs of your own internal coding agents -> your cloud bill is going to explode
At Appliscale , we tell our clients that building is no longer about writing better prompts but designing a strict agent harnesses" - if you don't put a leash on your agentic workflows, you are just funding that green line and tokenmaxxing is not always the best way (ask your CFO).
View on LinkedIn
M
Magdalena Śleboda
Head of Operations | Scaling Tech Organizations with AI, Automation & Data-Driven Execution | Global Ops & Transformation Leader
1 week ago in 100M monthly active users, 4M concurrent, 300K auth requests a minute at peak.
We don’t own any of these platforms. We modernised them, migrated them, and now help run them.
That’s what external development looks like when it works. You don’t see our name on any of it.
Adtech or gaming, the scale problems are similar. If you’re curious about our gaming case studies, check a dedicated section on the Appliscale website.
I’m happy to deep dive during the XDS.
#XDS2026 #ExternalDevelopment #GameDev
View on LinkedIn
Damian Naglak
Head of Engineering | Bedrock Platform | AdTech
1 week ago in To count the same person twice, for a frequency cap or a retarget, you need one identifier that holds still across visits. Device ID looks like the cleanest option: no login, no cookie sync, generated automatically just from using the device. None of that guarantees it shows up.
The field exists because an app-capable operating system generates an ID and hands it to whatever app is running. A browser tab never gets one, on any operating system, phone or desktop. iOS calls it IDFA, Android calls it GAID, and CTV has five more names for the same idea: Roku's RIDA, Samsung's TIFA, Amazon Fire TV's AFAI, Vizio's VIDA, LG's LGUDID. Windows has one too, assigned to every Windows 10 and 11 install for apps bought through the Microsoft Store, and it stays invisible to a browser tab open on that same machine.
Inside an app that can generate the ID, two things still take it away. A user can decline tracking, and the field comes back as a defined placeholder: a string of all zeros, the exact same value on every device that declined. Apple started it on IDFA, Android matched it on GAID in 2022. It looks like an ID but means nothing, and it's the same nothing for millions of people at once. A user can also reset it from settings, any time, with no notice to anyone who was counting on it.
CTV works the same way, and adds two more problems. The ID exists at the platform level, but five unrelated names with no shared standard means a cross-device campaign is stitching together five different systems, not one. And even when the platform hands over a real ID, the ad often doesn't reach the viewer directly. Server-side ad insertion splices it into the stream on the publisher's own infrastructure, so the device ID has to be carried through that step by hand.
OpenRTB used to name the platform that issued the ID: idfa, aaid, rida, afai. That field is deprecated now. The replacement names how the ID was generated instead: by the device, by the publisher, or as a short-lived session value meant to be thrown away. That's what tells you whether an ID holds still. Cap on device ID and you're only capping the slice of traffic that carries one, never all of it: a browser tab, an opt-out, a reset, or a stitching step can each leave the field empty.
Bedrock Platform
View on LinkedIn
M
Magdalena Śleboda
Head of Operations | Scaling Tech Organizations with AI, Automation & Data-Driven Execution | Global Ops & Transformation Leader
2 weeks ago in The description of my XDS panel hosted by Summer O'Brien says policies, cost models, and risk frameworks are still catching up with the tools our teams already open every day. Accurate.
From the service provider perspective it’s no longer a question of if, but of how. Which model, which skills, how to optimize the toolkit and tokens you burn to get to the results you wanted. And who reviewed it before it went to the client’s codebase.
The model is the easy part. The harness around it is where the advantage sits. Craft problem, not a licensing one.
Max Wojczuk and Michal Niec have been publishing for months how Appliscale engineers experiment with it in internal and external projects - token usage, toolkit and agentic setup, what we tried and dropped. They go deeper than I’ll manage in a panel slot.
AI in External Development: Policy, Risk, and Reality. Vancouver, Sep 9, 11 am. I’m booking meetings around it if you want to chat more.
View on LinkedIn
M
Michał Nieć
CEO of Appliscale | AI in AdTech Expert | LP & Angel Investor in AdTech/GameTech
2 weeks ago in tl;dr we're looking for Senior Data Engineer who can handle petabytes of data.
I write a lot about Ad Tech on LinkedIn, but that is only half the story at Appliscale .
The core of our DNA isn't advertising. It is scale. We build infrastructure for companies that generate data so fast it breaks normal cloud architectures.
Right now, we are hiring a Senior Data Engineer for one of our longest-standing partners: one of the largest game studios on earth, responsible for massive global MOBA and FPS franchises.
When millions of players log in concurrently to play an FPS, the data exhaust is staggering. You aren't just managing gigabytes of data; you are playing a vital role in building solutions capable of processing petabytes of information.
This role sits inside the Data Experiences and Automation team. The mission is to harness that massive data stream to power player-centric decisions, Machine Learning, and GenAI pipelines. You will be building the data foundation that insight analysts and ML engineers rely on to iterate fast.
We need a Senior Data Engineer who understands large-scale, globally distributed systems.
The details:
- B2B: 26,000 - 30,000 PLN net / mo.
- Remote / Krakow
- PST Overlap required (the core team is in LA and Seattle)
If you are tired of working on small datasets and want to manage petabyte-scale infrastructure for millions of players, you know the drill: https://www.appliscale.io/career/senior-data-engineer-pst-overlap-zbor
View on LinkedIn
Damian Naglak
Head of Engineering | Bedrock Platform | AdTech
2 weeks ago in You get the same ad ten times in one evening. That campaign almost certainly had a frequency cap set well below ten. A cap counts an identifier, and you keep arriving as a different identifier.
In the bidder a cap is a lookup. A request comes in, the bidder reads a counter for this person and decides whether to bid. For that number to mean anything, the request has to carry something that points at the same person as yesterday, and the impression from an hour ago has to be in the count already. Both of those fail often enough to explain the ten.
Start with the identifier. A bid request can carry a person in four ways, and any of them can be missing. The exchange's own ID for you (user.id), usually taken from its cookie, which it may rotate under its own privacy policy. Your own ID, mapped for you by the exchange (user.buyeruid), which exists only where a cookie sync ran first. The advertising ID from the phone or TV operating system (device.ifa), which anyone can reset from settings, and which arrives as a string of zeros on iOS when the user declines tracking. And IDs from third party graphs like RampID, ID5 or UID2 (user.eids), which arrive encrypted and encoded for one specific buyer, readable only with an agreement and the keys.
Those graph IDs carry a note saying how the match was made. Some come from an email login. Some come from a cookie sync. One of the values means the match was inferred from IP address and user agent, so the ID is a guess about who this is. A cap counts against a guessed ID the same way it counts against a real one.
When none of them arrive, what is left is the IP address and the user agent string (device.ip, device.ua). An IP is rarely one person. A home router puts the whole family behind one address. Mobile operators run carrier grade NAT, where thousands of subscribers share a single public address. The address does not hold still either: a home lease runs from a day to a week and can change when it renews or the router restarts. The user agent stopped separating people too, because every Chrome on Android now reports the same made up device.
Then there is the delay. The counter moves when the impression is booked as spend, which happens after the ad renders, and rendering can wait. A video prefetched during a game level plays when the level ends. An ad stitched into a podcast sits in the file until someone reaches that minute. On the web that gap is short. On formats that get cached or stitched into a stream it runs far longer. Everything you bid in that window is decided on the old count.
A frequency cap is worth no more than the identifier it hangs on. The harder it gets to recognise a person, the more of the same ad that person potentially sees.
Bedrock Platform
View on LinkedIn
Maksymilian Wojczuk
Technical Engineering Manager @Appliscale | Co-founder @DiPA
2 weeks ago in On August 17, Activision reported a connectivity incident affecting multiple Call of Duty titles.
The incident started at 6:43 PM UTC, with players reporting problems connecting to the game and logging in. Activision marked it as under investigation. I haven't found a public post-mortem explaining what caused it yet.
That leaves an interesting question for anyone working on game backends: where did it actually fail?
A player pressing “Play” can trigger a surprisingly long chain of backend services:
authentication → verification → entitlements → player profile → matchmaking → session allocation → game server
A failure in any of these can prevent the player from getting into a game, even when the game servers themselves are healthy.
This is where game backend engineering starts looking very familiar to anyone who has worked on distributed systems. You deal with partial failures, retries, timeouts, inconsistent state, traffic spikes, queues and regional failures. The player just experiences it as “the game doesn't work.”
This is also the area my team at Appliscale specializes in. We build backend services for authentication, verification, player preferences, queueing, and session management at large scale.
At scale, game technology is distributed systems engineering. Authentication, session management and player state are all part of the system the player depends on before the game even starts.
View on LinkedIn
M
Michał Nieć
CEO of Appliscale | AI in AdTech Expert | LP & Angel Investor in AdTech/GameTech
2 weeks ago in Really impressive AI parkour simulation by NVIDIA . The coolest part: all of that generated from just 30 seconds of reference material.
But looking under the hood, I think there's a fascinating tension robotics optimization vs. game realism I've been thinking about:
Robotics = optimization is king. We treat movement as a pure kinematic problem ("get from A->B via path C") to strictly minimize energy costs and wear-and-tear. The goal is always maximum efficiency.
However, to avoid the uncanny valley in characters, we actually need to inject somę “inefficiency”. If an AI/NPC moves with perfect thermodynamic optimization (like a robot), it feels… robotic. Humans don't move optimally - our actuators fatigue, joints stiffen, we run out of breath etc.
So to mirror human movement, we can't just optimize for the "best path" but rather “simulate the limits”: tired joints that fail under load, momentum that naturally drains speed, and recovery phases where efficiency drops.
For robots it’s ok to treat energy as infinite because they lack an explicit "battery" state or metabolic decay in their loss functions but that’s a different story for games.
(strongly recommed to follow Maksymilian Wojczuk from our Appliscale team who shares his deep dives into AI/gametech)
Paper: https://jiashunwang.github.io/HIL/static/mat/Hybrid_Imitation_Learning_TOG.pdf
Video: https://www.youtube.com/watch?v=8B05cy3UuSE
View on LinkedIn
Damian Naglak
Head of Engineering | Bedrock Platform | AdTech
2 weeks ago in A sportsbook asks for the people most likely to bet on football. The closest match anywhere in the data lives in a state where the company holds no licence. The model was right and the answer is worthless.
The last two posts were about finding the closest people among billions. Nobody wrote down who belongs in the audience and no score makes somebody a member, so everybody scores something against the description. Comparing against everybody is too slow, so each person is stored next to a short list of their nearest neighbours, and the search hops from person to person, always towards somebody closer. A few hundred stops instead of a billion comparisons. What comes back is a ranking, and it says nothing about who you may advertise to.
A profile often says where someone lives, so the vector half knows. Pooling flattens a whole browsing history into one vector, so two words about a city sit among hundreds of others, and one state reads much like the next. The vector leans one way, it never certifies. And the conditions that disqualify a person were never in their browsing history at all. Whether the sportsbook holds a licence in that state sits in the company's records, and changes when a legislature votes. Whether they agreed to be advertised to sits in a consent record. Whether you can reach them depends on an ID you may bid on. Anyone who already opened an account is on the advertiser's exclusion list. A better model ranks people better and learns none of this.
The obvious way to combine them is to take the closest hundred and drop the ones you cannot use, which in a narrow market leaves nobody. So the licence check runs during the hopping instead. Every time the search reaches somebody it asks two things: are they close, and are they allowed. Only the allowed ones go on the shortlist, and the rest still get hopped over, because their neighbour lists are the route to everybody behind them. The search stops when nobody left to visit is closer than the worst person on the shortlist, so when few qualify it fills slowly and the search keeps running. If one person in twenty is allowed, the search stops at twenty of them for every usable name it collects. Removing a few people costs almost nothing. Requiring something rare is what stretches the search.
The way out is to split people in advance by a separate index per state, so everybody inside it is eligible. Licences, caps, budgets and exclusions change by the second, so those get checked as the search runs. When very few qualify, the better move is to stop hopping and compare against the eligible ones directly, which is what engines do below a size threshold. And the top of the ranking wears away as a campaign runs: the best matches get served first, so they cap out first, and the ones who sign up move to the exclusion list.
Search over vectors is quick because it never looks at most of the people. Every rule about who you may advertise to is a reason to look anyway.
Bedrock Platform
View on LinkedIn
M
Michał Nieć
CEO of Appliscale | AI in AdTech Expert | LP & Angel Investor in AdTech/GameTech
2 weeks ago in A cheaper and more efficient that Seedance 2.5 flow to generate game videos.
Instead of prompting a video model directly and relying on multiple rerolls to get the right shot, GMI Cloud used DeepSeek V4 Flash to write a raw Three.js scene (exact camera movement, character motion, timing etc.).
Once the sequence was correct, they fed that raw, low-poly footage into MiniMax H3 to generate the final realistic render in a single take.
Cost: 48 mins, $1.97 total, one H3 generation.
View on LinkedIn
Damian Naglak
Head of Engineering | Bedrock Platform | AdTech
3 weeks ago in Embedding targeting is usually explained as comparing two vectors. The step before that, picking which vectors to compare against at all, is where most of the work sits.
Last post: you cannot put vectors in order, and you cannot rule out a group without looking inside it. So whatever makes this fast has to be built before any request arrives. There are thirty years of methods for doing that. Trees, which cut the space into smaller and smaller boxes, stopped working above about ten numbers per vector. Hashing, which sorts vectors into buckets using random cuts, needs too many buckets to get accurate. Grouping, which clusters everything and opens only the nearest few clusters, survives underneath the others. And one approach won outright, a graph of neighbours called HNSW, for hierarchical navigable small world. Of the ready-made databases sold for storing and searching vectors, Qdrant offers nothing else at all, and Weaviate makes it the default.
It works like walking downhill in fog. You cannot see the valley, but from where you stand you can feel which way the ground drops, so you step that way and check again. You stop when every direction goes up. The structure is exactly that. Every vector gets a list of about sixteen of its nearest neighbours, stored right beside it, and that list is all it can see from where it stands. A request drops in somewhere, checks those neighbours, moves to whichever one sits closer to what it is looking for, and does the same again from there, until none of them is closer than where it already is. Then it stops. A few hundred steps out of a million, and everything it never walked past is never seen.
There is one shortcut on top of that. The map comes in layers: a sparse top layer where the few points sit far apart and every hop covers a lot of ground, then denser layers below with shorter hops. A request crosses the rough map first to get into the right region, then drops down and refines. Flights, then trains, then walking.
What goes wrong comes out of the same picture. You can end up at the bottom of a small dip with the ground rising in every direction, while the real valley sits over the ridge you never crossed. The fix is to walk several routes at once instead of one, and how many is a configurable number. Walk more of them and you land in the real valley more often, and it takes longer. None of this is free. Those sixteen links per vector get stored alongside them, so the structure takes up more room than the data it was built from, and assembling it for a million takes time. You are buying query time with space, paid once in advance, and in bidding query time is the one thing you cannot get more of.
That trade is what makes matching by meaning possible inside an auction at all. A bid response has about a hundred milliseconds. Comparing one vector against every stored one does not fit inside that but walking to a few hundred of them does.
Bedrock Platform
View on LinkedIn
Damian Naglak
Head of Engineering | Bedrock Platform | AdTech
3 weeks ago in Segment targeting asks one question: is this user in list 12345. Embedding targeting asks which of my audiences this user is closest to. One of those is a lookup. The other is a search.
With segments somebody drew the line in advance, so a user is on the list or off it and the auction only has to check. With vectors there is no list and no line. Every user has some score against every audience, nothing is in or out, and the only way to decide is to rank everything and take the top few. So matching on meaning means finding the closest, and finding the closest is a different job from checking membership. Databases are fast on huge tables for two reasons. The rows are kept in order, so finding one is jumping straight to it. And they are grouped into chunks whose contents are known, so most chunks never get read at all: if a chunk holds only values between 10 and 20 and you asked for 50, it is thrown away untouched. A billion rows, and the database reads almost none of them.
Neither trick works on vectors. Keeping things in order needs something to order them by, and closest has nothing, because it depends on a question that arrives later and is different every time. Whatever order you pick, the next request wants another one. Skipping groups fails for its own reason: to throw a group away you have to be certain nothing inside it is closer than what you already found, and with hundreds of numbers per vector the distances all come out similar.
So you are left comparing against all of them. A million vectors at 3,072 numbers, four bytes each, is twelve gigabytes to read for one bid request. Nobody does that. Everyone gets around it the same way: group the vectors by closeness before any request arrives, then only look at the group the request lands in. That saves almost all the work, and it sometimes gives you the wrong answer. For bidding it lands somewhere specific. Today the hard part happened days earlier, when someone worked out who belongs in the audience and wrote it down, so the auction only reads the answer. Matching on meaning moves the finding into the auction itself, and what a bid costs stops being flat. Twice the audiences, twice the work, on every request.
Next: the three ways people organise vectors in advance, and what each one gets wrong.
Bedrock Platform
View on LinkedIn
M
Michał Nieć
CEO of Appliscale | AI in AdTech Expert | LP & Angel Investor in AdTech/GameTech
3 weeks ago in If you are not tired of AI content yet, congratulations, here is one more concept.
Agentic Software Factory. You stop writing code and start designing the factory that writes it. Nine stages, three kinds of actor. Agents implement, test, review and analyse incidents. Infrastructure sandboxes, ships and watches. Humans do four things: set intent, set priorities, own the architecture, and get paged when it breaks.
The pitch you will hear is that this removes the code review bottleneck. It does not. Ten agents opening forty pull requests an hour makes human review the bottleneck, harder than it has ever been.
What actually changes is where humans spend attention. Upstream, into the specification, because a vague spec used to cost you a day and now costs you forty confidently wrong diffs. And into the gates: tests, review agents, monitoring. Those are the only things that scale with the agents.
The factory does not remove the human. It removes the human from the middle and puts them at both ends.
So where is your bottleneck now: writing the code, or deciding what it should be?
View on LinkedIn
