Damian Naglak
Head of Engineering | Bedrock Platform | AdTech
3 days ago in A Gemini audience vector is 3,072 numbers. I deleted 2,304 of them, kept the first 768, and every audience in my test still matched the same ones. The order those numbers come in is not an accident.
Two posts back I showed an audience vector weighing about eight times the whole bid request, with two ways to shrink it: store each number in fewer bits, or carry fewer numbers. The first was quantization, where int8 gave a free 4x. This is the second, and the more surprising of the two.
Start with what those 3,072 numbers are. Each is a coordinate on the model's map of meaning, and on its own a single one tells you nothing: there is no "luxury" number to point to, no slot for "in-market for a car." The meaning is smeared across all 3,072 at once, so you would expect every number to matter and dropping any to hurt.
These models do something deliberate about that. Gemini's is trained with a technique called Matryoshka, after the nesting dolls that sit one inside another: the first 768 numbers are a complete, usable vector by themselves, the first 256 a coarser one inside that, and so on down. The full 3,072 is the outermost doll, with smaller working vectors packed in from the front. The tail adds detail; the front carries the gist.
This is literal. Ask the Gemini API for 768 dimensions and it hands back the first 768 numbers of the same vector, nothing recomputed: I checked its answer against my own front-768 slice and they line up at cosine 1.0000. Fewer dimensions means keep the front and renormalise.
So I ran the ladder on the same 24-audience library. Cut from 3,072 to 768, four times smaller, and the matches are identical: every nearest neighbour is the one the full vector picked, and my three tiers barely move (0.956, 0.871, 0.809 against 0.956, 0.879, 0.823). Push further and it costs: by 256 dimensions the exact nearest neighbour holds for 88% of audiences, by 128 for 79%, and the cosine value drifts upward as fewer axes crowd together. Yet the right concept still ranks first all the way down to 32 numbers. The score loses its meaning long before the ranking does.
Which 768 you keep barely matters on a set this small: the first, last, or a random pick all worked about the same, so the saving here comes from the count of numbers. The front 768 earn their place on large, hard catalogues, which is what the public MTEB benchmark shows, with 768 dimensions about 0.2 points below the full 3,072. And truncation only works on a model trained for it: I ran the same cut on ada-002, never built to pack meaning into the front, and its nearest match scrambled to 79% at an eighth of its dimensions, while Gemini stayed near perfect.
So this is the second way to make an audience vector lighter, after quantization: that one rounded each number, this one drops most of them and keeps the front. Either buys a clean 4x on Gemini before the match suffers, and on a model trained for it the tail is mostly polish.
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 Our Head of Engineering Damian Naglak just published a masterclass on Appliscale blog detailing exactly how Embedding-Based Targeting works under the hood.
If you are interested in Agentic AI and Ad Tech, you need to follow Damian. He breaks down the exact mechanics, pulling real numbers from live models to show:
-> Why your targeting precision relies entirely on the tokenizer's dictionary (and why "Saturn" gets split into two meaningless pieces)
-> How the "Attention" layer uses surrounding words to figure out if you mean Coach the designer purse, or Coach the sports trainer
-> The "Squash" (Pooling): How a full paragraph of context gets compressed into a fixed 3,072-number vector
-> The One Golden Rule: Why a buyer and a seller MUST use the exact same embedding model, or the math completely breaks
Read the full deep dive below: https://www.appliscale.io/blog/how-embedding-based-targeting-works
View on LinkedIn
Maksymilian Wojczuk
Technical Engineering Manager @Appliscale | Co-founder @DiPA
4 days ago in With SIGGRAPH 2026 coming up in a couple of weeks, NVIDIA's paper on MotionBricks is worth a look. It proposes a way to completely bypass traditional game animation graphs.
If you look at modern AAA games, they still handle character movement with techniques from twenty years ago. Brittle state machines, blending trees, and thousands of manual clips stitched together. A game might have 15,000+ animations and a state machine nested 12 levels deep. It is fragile, expensive, and a nightmare to maintain.
This is the generative AI in games we actually want to be seeing.
Instead of generating text or pixels, it is generating the underlying character motion in real-time. They model a dataset of over 350,000 clips with a single modular generative model.
The way it works is keyframe in-betweening. You place a simple target keyframe - like a ledge to climb or a chair to sit on - and the model handles the entire transition dynamically. It is plug-and-play, letting designers author complex locomotion and object interactions in under 10 minutes.
If this makes it into production pipelines, the industry impact could be massive. It points to a way to bypass the animation asset bottleneck completely - letting small teams author AAA-quality movement, and giving major studios a path toward building truly reactive virtual environments.
And the speed is what makes it feel actually viable for production. Usually, generative motion models take seconds to compute. MotionBricks hits 15,000 FPS with 2ms latency on a desktop GPU, and they even deployed the exact same model on a physical Unitree G1 humanoid robot running on a Jetson Orin board.
It feels like we are finally starting to move from rigid, pre-recorded playback to dynamic, real-time motion control.
Link in comments.
View on LinkedIn
Damian Naglak
Head of Engineering | Bedrock Platform | AdTech
4 days ago in A bid comes back in a hard window, on the order of 100 milliseconds, and on the open web most of it is gone before the request even reaches the bidder. What is left is the real limit on how smart the model can be.
The bigger these models get, the better they do, with no ceiling in sight. In 2024, Meta published a recommendation model called Wukong that kept improving as it grew, out to about 108 billion calculations for a single prediction, far past what a bidder could finish in time. That size is reached offline, in training, where nothing has to answer in milliseconds. The old way to make these models bigger was to give them more memory: a longer table that stores something about each user, page, and ad, and past a point more memory stops helping. Wukong grew a different part instead, the layers that work out how signals combine (this user, on this page, with this ad), and that kind of size keeps paying off.
The catch is in the same paper. A model that big cannot answer inside a real-time serving budget, so the way it reaches production is distillation. You train the big model first, then use it as a teacher: a small, fast model learns from its probabilities, not just the raw clicked-or-not labels, so it comes out close to the big one's quality while staying fast enough to serve. Meituan's SUAN did exactly that, a large model lifted click-through 2.67% in testing, and they shipped a distilled 43-millisecond version to production.
The same squeeze decides how much signal the model can read. Alibaba's SIM showed that feeding the model far more signal per request lifts click-through, 7.1% in their display ads since 2019, but scoring thousands of signals for every request was too slow, so they built a two-stage search: a cheap pass keeps the signals that matter, and the full model reads only those, up to 54,000 in a few milliseconds.
Now look at where open programmatic spends that budget. In a walled garden the model sits in the same data center as the auction, so all of its time goes to computing the answer. On the open web the bid request travels across networks to reach the bidder, and that trip eats 60 to 80 of the roughly 100 milliseconds before the bidder does any thinking. Put the bidder inside the exchange and that trip disappears. Bedrock Platform runs its bidder as a container inside Index Exchange, so the request reaches it without crossing a network. It does not make compute free, the walled gardens are co-located and still distill, but it returns the time lost to distance, which on the open web was most of it.
With that time back, the open web can move toward what these papers point to: a model run closer to full size instead of a distilled copy, far more signal read per request, and more candidates and creatives ranked before the deadline. Co-location also removes the egress cost of the request, so sending the bidder more signal gets cheaper,
View on LinkedIn
Damian Naglak
Head of Engineering | Bedrock Platform | AdTech
6 days ago in A full audience vector can weigh up to 12 kilobytes because each of its 3,072 numbers is stored in 4 bytes. Store each in one byte instead and it drops to 3 kilobytes, and in my experiments the matches came out identical.
In one of the recent posts I showed a full audience vector weighing about eight times the entire bid request. There are two ways to shrink it: store each number with less detail, or store fewer numbers. The first is called quantization. A vector is just a list of numbers, each stored to high precision like 0.0734126, taking 4 bytes, because the model works in fine-grained numbers while it learns and hands them to you in that form. Matching does not need that detail, so you can round. Write 0.0734126 as 0.07 and it fits in one byte, four times smaller, which is int8; round to 0.1 for half a byte; at the far end keep a single bit, just whether the number was above or below zero. The catch is that rounding blurs fine differences: 0.073 and 0.071 both become 0.07, so vectors that sat close start to look alike.
I measured what that costs. I embedded this series' 24-audience library with gemini-embedding-001 at 3,072 dimensions, quantized every vector down the ladder, and checked size and matches at each rung.
Down to one byte, nothing breaks. At int8, four times smaller, the three similarity tiers I have shown before are unchanged (0.956, 0.879, 0.822, within a thousandth) and every nearest match is the one full precision picked. Below that it costs, though not where you would expect. At 4 bits the scores drift and the nearest match holds for 92% of audiences. At a single bit, 32 times smaller, the cosine value falls apart and the exact nearest neighbour survives only 79% of the time, yet the right audience comes back: top-results recall stays at 96% and same-concept siblings rank first.
What survives depends on how you use the score. Read the cosine as an absolute number against a fixed cutoff, a match counts above 0.85, and hard quantization breaks it: binary pulled my three tiers from 0.96, 0.88, 0.82 down to 0.74, 0.56, 0.46. Use the score only to rank candidates and take the closest, and the order barely moves: rounding rarely changes which vector is nearest. So a fixed threshold can go to int8 and no further, while a system that just picks the closest can drop to a single bit and still land on the right audience.
How far you can push depends on the model and the data. Published benchmarks keep about 99% of retrieval at int8 and about 96% at binary on a good model, but on some models binary falls to 75%, and my small, clean set flatters binary here. The payoff is large either way: int8 is four times smaller and that cut lands straight on egress, storage and retrieval speed. What quantization cannot change is the count, every rung still carries 3,072 numbers.
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 The biggest irony of the AI revolution is that it is forcing tech companies to become deeply human again.
We have always been remote-first at Appliscale . Working with US clients means late hours, and forcing people to commute to an office just to act as a "social club" kills productivity. We care about results, and we wanted access to a country-wide talent pool.
But recently, the remote hiring market has become quite difficult. Despite the narrative about "mass tech layoffs," finding elite talent is harder than ever.
Here is what I am seeing in our recruitment pipelines:
1) The Layoff Myth. The market is not flooded with top-tier engineers. The massive layoffs mostly hit legacy or low-efficiency units that accumulated mediocre talent. The top 1% are still very hard to find.
2) Geo-scammers. We regularly interview offshore candidates claiming to be in Poland. They use traditional Polish names and claim they have a "Polish father who emigrated to Singapore." Ask them to name a single district in Warsaw, and the call usually ends abruptly.
3) AI-boosted Fake CVs. 5 years ago, faking technical seniority was hard. A few architecture questions would expose a junior. Today, with live interview helpers like Cluey and AI coding aids, it is terrifyingly easy to fake competence on a screen share.
We are adapting, and the solution is highly ironic.
Because AI makes it so easy to fake a CV and an interview, we are using AI to automate 100% of our recruitment paperwork and assessments. Our team spends zero time filling out forms. Instead, we take all those saved hours and dump them into deep, 1-on-1 human conversations with the candidates.
It feels like a paradox, but AI cheating is actually forcing us to shift back to deep, human-to-human relationships to verify who we are hiring. And that's good.
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 Ten roles are live on Appliscale careers page at the moment.
Posting each one took a single click in Airtable. Our site runs on Vercel and fetches directly from that base, so the click is the publish. Taking one down works the same way.
That's not a point about tooling. It's the whole series showing up in one place.
Because recruitment is where our operations actually start. The automations, the internal systems, the lean stack - none of it holds if the way people join is a mess.
So we built that part first.
Steady growth, not explosive. Smart, not loud.
And onboarding? Each step a candidate finishes sets off the next. The system carries the process, so no one has to carry it in their head.
If that's the kind of place you'd want to work - the page is open.
Click apply 👇
View on LinkedIn
Damian Naglak
Head of Engineering | Bedrock Platform | AdTech
1 week ago in A real bid request is about 2,000 bytes. The audience vector that embedding-based targeting would put inside it is 16,000 if not used properly. The vector alone outweighs everything else in the request, several times over.
Embeddings let you target by meaning instead of by segment ID. Let's take a closer look at what that vector could weigh on the wire. An average bid request runs about 2 kilobytes, and since everything on a bid path is gzipped and a request is mostly text and repeated field names, it compresses to about a kilobyte over the wire.
A full Gemini-class vector is 3,072 numbers, each one a 32-bit float at 4 bytes, so about 12 kilobytes of raw data and around 16 kilobytes once it is packed into the request. Next to a 2-kilobyte request that is roughly eight times the size of everything else combined: one field outweighing the device, the user, the page, the impression and the supply chain all together.
Compression does not close the gap. The rest of the request is text and repeated field names, so gzip halves it, while a vector is close to random numbers with no repeating pattern, so gzip barely touches it. The full vector still weighs about 12 kilobytes compressed, against a kilobyte for the request it rides in, so on the wire it ends up around ten times everything else combined.
That is a movement problem before it is anything else. Take an exchange with fifty buyers at a hundred thousand requests a second each, five million a second, around 430 billion bid requests a day. The requests on their own are about 430 terabytes of egress a day. Attach a full vector to every one and you add roughly five petabytes a day, more than ten times that. On public cloud every one of those gigabytes is metered on the way out. If you run the exchange there and pull up the egress line for the vectors alone, you will want to sit down first.
This is also where running the bidder inside the exchange changes the arithmetic. Bedrock Platform's bidder runs inside Index Exchange's Index Cloud, so the request never crosses a network to reach it. To reach a bidder in another cloud the exchange pays egress on every byte of the fat request; to reach a co-located one it pays none, whatever the vector weighs. So the vector's size stops being an egress cost on that hop, which makes it practical to send the bidder more signal than a remote one would justify: several vectors, richer context, things that were never worth shipping across a network.
The full, full-precision vector is more than the match actually needs on the wire. There is a lot of room between it and a vector that still matches well. I will take a closer look at it in the next posts.
Comparing two vectors is cheap, one multiply-and-add per match. Moving them outside the datacenter is the expensive part: a few thousand numbers per user, millions of times a second. That is what you can shrink.
View on LinkedIn
M
Michał Nieć
CEO of Appliscale | AI in AdTech Expert | LP & Angel Investor in AdTech/GameTech
1 week ago in Every time you think you need a new dashboard, stop. Ryan is 100% right here.
This is exactly why we built arctus.studio at Appliscale .
After talking to +20 companies we've noticed that most account managers in Ad Tech are drowning in dashboards and at the end of the day, they still have to manually export that data into Excel just to answer a simple client question like: "Why did ROAS drop yesterday?"
The problem is simple: dashboards are static - business questions are dynamic.
So instead of building yet another view in Tableau, we gave an AI agent the ability to understand the underlying database structure. When a client asks, "Why did our Meta spend spike?", the agent queries the database -> reasons through the metrics -> gives you the exact answer in seconds.
If your team is still spending Friday afternoons building reports that nobody looks at by Monday, you need an agent, not another chart.
View on LinkedIn
M
Michał Nieć
CEO of Appliscale | AI in AdTech Expert | LP & Angel Investor in AdTech/GameTech
1 week ago in After-Cannes thoughts vol.2: container > agent
Agents, agents, agents, AI - everyone on the main stages talked about it but the most valuable, concrete discussions we had this week weren't about futuristic AI. IMO in the private meetings with top players there was one hot topic (hotter than 31°C in the shade): Containerized Bidders. Yes, less sexy and shiny let's face it - buzzwords don't pay your cloud bills.
Running your bidding engine right next to the SSPs, does. E.g. if you're processing 1M+ QPS, shipping bid requests across different cloud networks easily kills your margin and eats up 20–30ms of your strict 100ms SLA window -> by running the bidder inside the exchange's own environment, whether that is a VPC or the SSP's own data centers, you drop network transit from 30ms to sub-5ms while virtually eliminating cross-cloud egress costs (=good old: faster, cheaper).
The part people miss: once each bid costs almost nothing to process, you stop throttling. The bidder listens to far more of the stream and stops timing out. On the sell side, more bidders reaching more of the stream lifts competition and fill. On the buy side, your cost per win falls. Both without a single model change.
AI agents are incredibly powerful and we're big fan of them in Appliscale , but you cannot deny raw efficiency of the design that just make sense.
View on LinkedIn
Maksymilian Wojczuk
Technical Engineering Manager @Appliscale | Co-founder @DiPA
1 week ago in A player turns 18. Your system removes parental consent. You're compliant.
Not in South Korea.
The Juvenile Protection Act doesn't calculate age by birthday - it calculates by calendar year. Everyone born in 2007 becomes a legal adult on January 1, 2026, the year they turn 19, regardless of when their birthday falls.
A player born December 15, 2007 hits 18 and your system flags them as an adult. Under the Juvenile Protection Act, they're still a minor for another 17 days.
Easy fix: bump the threshold to 19. Except that breaks something else. A January-born player ages out almost 12 months earlier than a December-born player from the same birth year. The logic itself has to change - from "age at birthday" to "calendar year they turn 19."
This is one country, one act. Multiply it across every jurisdiction with its own definition of "adult" - 18 in most places, 19 by calendar year in South Korea, 21 for certain content in some US states - and age assurance starts to look like what it actually is: an active engineering problem, not a policy checkbox.
Getting it wrong isn't a UX bug. It's operating without legally required parental consent for a minor.
Link in comments.
View on LinkedIn
M
Michał Nieć
CEO of Appliscale | AI in AdTech Expert | LP & Angel Investor in AdTech/GameTech
1 week ago in Few tips & thoughts on Cannes festival (tl;dr yes, it's awesome buuut)
It was my first time in Cannes and long-story short: yes, it's great and probably one of the best places to be when it comes to advertising and ad tech. The scale?
+12,000 participants
+26 official side events
+700 panelists
So forget about traditional networking playbook for conferences and meetups. Here are a bunch of my insights and "lessons learned":
1) Leave your calendar empty. Yup, my initial plan was to book meetings with old friends, panelists, have planned converstaions etc. it's a trap: at this scale, you cannot design serendipity. Counterintuitively, I'd recommend just to go with the flow - for me the best networking happend after 6pm over a pint of lager
2) "Alpha in the shadows". It's like market alpha - it's hidden. Same for events. Open events are great for scouting. But the real market intel is shared in closed WhatsApp groups and under-the-radar private dinners. If you overpack your calendar -> you have no room to accept these.
3) Hyperniche >> niche >> generic. Ad tech is incredibly specialized now so don't worry about being too niche. For example: Damian Naglak specializes in containerized DSP bidders, and embeddings - yes, generic networkers walk away, but the right person always lean in. Niche = filter.
4) Demo and use case beat vision. Nobody cares that "you do AI." Everyone claims that. What starts a real conversation is pitching exactly how you create value for the specific person across the table: "we send you our segments/data/cohorts/wlist/blist..., you monetize/discard/target those unsold impressions," backed by a demo and numbers like "based on our case study, I think you cut cost by $2M and lift revenue 20%." I say this as an investor too.
5) Agentic FOMO is masking a data problem. Every single keynote was about AI agents. But when you talk to people off the stage, everyone is struggling with the actual implementation. The consensus is clear: the technology is not the moat. Your proprietary data and unique inventory are your only real moat. Kinda obvious but worth reminding.
Incredible week, got 4 pages of notes but main take away is: sometimes the best strategy is just leaving empty space on your calendar and join the random conversation over beer with strangers.
View on LinkedIn
Damian Naglak
Head of Engineering | Bedrock Platform | AdTech
1 week ago in At Cannes, the conversation I kept having was about the problem with frequency capping in agentic buying. One agent can buy from fifty sellers in seconds. None of them can stop the same person from seeing your ad fifty times. Cross-seller frequency capping is the one thing agentic buying does not hand you by default.
The popular protocols did not forget it. AdCP has a frequency cap field built in: a cooldown between two views (suppress), or a hard limit per user in a time window (max_impressions with a window). IAB's agentic direct carries one too, a frequencycount over a frequencyinterval. The field is there in both.
The catch is the scope. The field caps within one seller, never across them. The protocols are explicit that audience IDs do not carry from one seller to the next, so the count cannot be shared. As a buyer you usually want to cap across the whole campaign. Show one person the same ad twenty times and you waste spend and wear out the audience. Inside one DSP this is automatic. Across sellers, bought through agents, it is gone.
The agent works at the negotiation layer: price, terms, the buy. At execution it hands your cap down to each seller's ad server. In Google Ad Manager that cap becomes a native frequency cap on the line item, and the ad server is what counts impressions and decides whether to serve the next one. And an ad server only sees its own inventory. It counts a user by its own idand it has no view of what happened on another seller. A frequency cap is just a counter tied to one person. To count across two sellers you need one system that sees both streams of impressions, and one shared id for the same person. By default, between two sellers who do not talk to each other, neither of those exists.
You only get that counter on one rail. A direct buy skips the auction and lives in one seller's ad server, so your DSP never sees it. A programmatic guaranteed deal does run through the RTB pipe and your DSP, but it is one seller and it is take-all: you committed to the volume, so you keep bidding even when you can see the user is over the cap. Only PMP is the case that works: it runs through your DSP and you can pass, so the DSP sees impressions across every seller and holds one counter. That is why a cross-seller cap survives on a PMP.
This reaches past frequency capping. An agent sits on top of the systems that already run advertising, and it inherits their limits. It can request a cross-seller cap, but it cannot enforce one: the enforcer is the ad server, and each ad server sees only its own seller. This is not a protocol gap, and agents are not too early. Swap protocols agentic and nothing changes, because both ride the same ad servers. The cap belongs to whatever sees every impression for one user, and an agent never does.
In the next two posts I will look at a couple of ways to get some of this back
Bedrock Platform
View on LinkedIn
Damian Naglak
Head of Engineering | Bedrock Platform | AdTech
1 week ago in A bid request passes through a Prebid wrapper, an ad server, and an SSAI stitcher before it reaches a buyer. The OpenRTB supply chain object has never recorded any of them. It records who gets paid.
IAB Tech Lab opened SupplyChain v1.1 for public comment last week, and that is the gap it closes. Today the chain shows the companies in the flow of payment. v1.1 lets it also show the companies that handle the request without being paid for the media.
Quick refresher: the supply chain object (schain) is a list of nodes attached to a bid request. Each node identifies one hop in the path by the advertising system handling it (asi, the SSP or exchange domain) and the seller account inside that system (sid). The system's own sellers.json resolves that account to a real company. In practice these chains are short. Across a day of the bidstream most carry one node, almost all the rest carry two, and a longer chain is a rounding error. Each node also carries a flag called hp for whether the company is in the flow of payment, and the v1.0 spec pins it: "for version 1.0 of SupplyChain, this property should always be 1." Every company the chain names is there because it gets paid, so the path you can read is short and purely financial.
That leaves a lot of companies invisible. A Prebid wrapper running the auction, an ad server in the middle, an SSAI service stitching ads into a livestream, an SDK on the device. Each one can read, change, or duplicate the request without taking a cut of the media payment, so none of them show up in the chain.
v1.1 adds:
1. hp 0 nodes. A node with hp set to 0 means this company handled the request but is not in the payment flow. The flag was always in the spec for exactly this, and v1.1 is the first version that puts it to work.
2. Lighter trust requirements for those nodes. An hp 0 node does not need ads.txt validation, since it is not selling anything, but a sellers.json reference is strongly recommended so the company can still be identified.
3. The bookkeeping to support it. The object's version label moves to 1.1, and the flag that marks whether a chain is complete gets new values, since a chain can now be whole on payment yet still missing handling hops. The companion sellers.json file is updated to match, so a company that only passes the request through can be described there.
What that buys, assuming it gets used, is one object answering three questions instead of one: who owns the inventory, who handled the request on the way, and who gets paid. Supply path optimization has the full path to reason about rather than the money path alone. Duplicate requests get easier to group when the intermediary doing the fan-out is named instead of inferred. And the SSAI and wrapper layer in CTV, where spoofing and double counting tend to hide, at least shows up in the record.
Comment period runs to August 21
Bedrock Platform
View on LinkedIn
Stanislav Shelemekh
AI Engineer & Tech manager, Appliscale
1 week ago in I open-sourced my first agent skill: self-improve. It’s simple, and it actually works.
At the end of a session you activate it, and the agent looks back and reflects: where it stumbled, where you corrected it, where it danced through ten steps to do something that should have taken one. Then it works out what was missing and proposes a few small fixes: a rule in AGENTS md, a command, a skill edit.
That’s the whole thing. No heavy process, no big config. The agent gets a little better every time you run it, and you can watch it happen.
Works with any coding agent. One command:
npx skills@latest add szelemeh/skills
View on LinkedIn
Damian Naglak
Head of Engineering | Bedrock Platform | AdTech
2 weeks ago in Just came back from my first Cannes. I spent most of it discussing three things: containerized bidding, embeddings, and agentic buying. The same three I keep writing about here, so I went in to see how far the market has actually moved on each.
Four days of conversations. Here is where they stand:
Containerized bidder - This was the one people brought up to me, unprompted, and from very different corners of the market: supply, premium video, audio, data-heavy platforms, even infrastructure providers. Run the bidder inside the exchange, next to the auction, and you lose the network round trip and its egress costs, and keep the signals that normally die on the way out to a DSP. The questions were not whether that works. They were the unit economics, and what happens when you let it run uncapped, with the whole market in view.
Embeddings - Targeting by meaning instead of segment IDs. You describe an audience in plain language, a model turns it into a vector, and the match is by closeness rather than a fixed taxonomy. Any audience you can put in a sentence exists the moment you embed it, and two different wordings of the same audience still land together. This is where the technically curious lean in: identity and clean-room companies, data shops, all wanting to test it and compare notes. It is the newest of the three for the wider market, and the one with the most room to run.
Agentic buying - Agents negotiating deals directly, AdCP, AAMP and the protocols around it. The most talked about of the three, and the least demonstrated. On stage it sounds inevitable; the people running sell-side businesses are more reserved, because adoption is still thin and hard proof is scarce. It feels that what would move companies is not more talk but proof they can see: take one real campaign, run it both ways, the old path and the new one through agents, hold the budget and the goal fixed, and show what each delivers on cost and performance.
One line ran through all three. Containerized bidding is already running, so the talk around it is backed by something real, which is why every conversation about it was concrete. Embeddings and agentic buying are earlier, and the request underneath both kept coming back in different words: show me it works, with numbers. Less evangelism, more evidence.
A good first Cannes. Now back to innovating, running it, and sharing the numbers.
View on LinkedIn
Stanislav Shelemekh
AI Engineer & Tech manager, Appliscale
2 weeks ago in I'm not a designer. But with an AI agent on the canvas, I've shipped designs I genuinely didn't think I could make.
That's the part of Pencil(.)dev that got me. I point my coding agent at it through the Pencil MCP, so the agent works on the canvas directly, not from the sidelines. I say what I'm after, it lays it out, we iterate until it looks right. And because the design lives in the repo, it drops into the UI cleanly instead of starting another round of back-and-forth.
It's faster, yes. The part that stays with me is that the ceiling on what I can ship is higher now.
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 most expensive work in a company usually isn't the hard work. It's the repetitive work. Same report, same pull, same five steps - every week, forever.
Pulling reports from the terminal is the easy part. The part that matters comes after - when you stop asking and start building.
Two things change once you're past the on-ramp.
First, you start combining tools. On its own, a Jira connection is convenient. Connected to Slack and your docs, it becomes a workflow. A messy requirements doc turns into a structured backlog of tickets. A decision buried in a Slack thread becomes a ticket without anyone leaving the conversation. The biggest value is not in a single connection - it's what happens between them.
Second, you build skills. The first time you run that weekly report, it's a careful prompt. The tenth time, it shouldn't be. So you capture it once - the steps, the filters, the format - and it becomes a command. Hand it to the team, and everyone runs it in a sentence.
That's the part worth a leadership team's attention. Not that one person can do something clever - that the clever thing becomes a reusable asset the moment it works. One good afternoon turns into permanent capacity.
At Appliscale we don't sell clients more tools. We help their people turn work they repeat into work they no longer do.
Setting up the terminal was the on-ramp. This is the point.
View on LinkedIn
Maksymilian Wojczuk
Technical Engineering Manager @Appliscale | Co-founder @DiPA
2 weeks ago in The era of not caring about AI costs - everyone knows it's ending. Someone has to pay. Which is what made Graphify catch my eye this week: it turns your codebase into a queryable graph for agents. Not much noise around it yet.
I use Claude Code daily and I've definitely felt the thing it's solving. Agents fly blind in large repos - file by file searches, burning through context windows just to understand what calls what, where a type is defined. The model is capable. The scaffolding isn't.
And this is starting to matter beyond the engineering annoyance. Uber burned through its entire 2026 AI coding budget by April. Wasted context isn't just slow. It's expensive.
Code graphs are the missing layer.
Pre-index the codebase - every symbol, call edge, dependency mapped before the agent asks. Instead of searching at runtime, it queries a graph. The numbers being reported are hard to ignore: 58% fewer tool calls, response times down 22%, token reductions anywhere from 30% to 99.7% depending on the task.
Graphify is one worth looking at. CodeGraph is another (local, auto-syncing, 20+ languages).
This feels like the kind of infrastructure that becomes obvious in hindsight. Not because agents get smarter - but because flying blind gets more expensive as the codebase scales.
Link in comments.
View on LinkedIn
Stanislav Shelemekh
AI Engineer & Tech manager, Appliscale
2 weeks ago in If you're not tokenmaxxing, you're doing it wrong.
There's a name now for burning as much AI as you can: tokenmaxxing. The usual take is that it's vanity, a leaderboard for who spends the most and calls it productivity. That's right about the metric and wrong about the instinct. Token count is a terrible score. But finishing the cycle with capacity to spare still means something, and it isn't that you were disciplined. It means there was work you could have handed off and either did by hand or didn't do at all.
Most people leave so much unused because they treat Claude Code like a faster autocomplete. One request, wait, read the diff, next request. A human sits in the loop on every step, so throughput is capped at human speed. The limit was never the constraint. The one-thing-at-a-time habit is.
The shift is going from "help me with this" to "go do this and come back." Have it find every place you touch money without a transaction and rank them by blast radius. Spin up a dozen agents (the ultracode mode) that attack one audit from different angles and merge what they find. Point it at a 60-page competitor whitepaper and ask what's actually new, or at last quarter's support tickets and ask what keeps breaking. The machinery that reads code reads everything else.
None of this is free. The cost moved. It used to be the model's speed, now it's your ability to specify a task clearly enough that it runs without you watching. A clear brief, a way to check the result, scoped permissions so nothing dangerous happens unattended. That's most of the setup.
The dashboard number was never the point. The real limit is how much work you can define well enough to hand off, and for almost everyone that sits far below the cap they're trying not to hit.
View on LinkedIn
Damian Naglak
Head of Engineering | Bedrock Platform | AdTech
3 weeks ago in AgenticAdvertising.org' AdCP 3.1 was released yesterday. Minor release, additive over 3.0, nothing breaks: 3.0 integrations keep running and the version pin moves up once the SDK is ready.
Versioning: a request pins a release (adcp_version "3.1") instead of a bare major version, and the seller echoes back the release it actually served, so there is no more guessing which shape a response is in.
Media buys: a buy now carries a health flag and an impairments[] list, so when a creative gets pulled or an audience suspended the response names the offline dependency, the affected packages and a fix, instead of a drop in the delivery numbers being the first sign, followed by digging. Recent webhook fires are visible too.
Measurement and billing: optimization goals can bind to a named vendor metric (DV, IAS, Adelaide, Lumen) instead of a vague string, and delivery rows mark when a number is final, so there is something to invoice against.
Brand identity: a brand can publish its own brand.json on its own domain instead of living in one central house document, and a partner can ask the brand directly whether a trademark or asset claim is real, with a signed answer that can be verified later. Auth also got stricter: credentials out of the request body, clearer correctable-versus-terminal errors.
The rest: a canonical set of creative format names to replace per-publisher naming, cheaper catalog mirroring (send the last version token seen and an unchanged feed replies with nothing), and idempotency rules for concurrent retries.
Net: more ways to see what happened to a buy, settle the numbers, and verify the other side. The buying flow itself is unchanged.
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 I stumbled upon an interesting repo today called Ponytail.
It is apparently named after the veteran dev we all know: long ponytail, oval glasses, been at the company longer than the git history. You show him a complex 50-line class; he looks at it, says nothing, deletes the file, and replaces it with one line.
So Ponytail is a simple, two-paragraph agent skill that puts his brain inside your AI harness. Before writing a single line of code, it forces the agent to search for reasons not to write it.
Results: 80-94% less code, 47-77% less cost, and 3-6× faster than a no-skill agent, on every model.
"Does it scale? The code you never wrote scales infinitely. Zero bugs, zero CVEs, 100% uptime since forever".
Link: https://github.com/DietrichGebert/ponytail
View on LinkedIn
Maksymilian Wojczuk
Technical Engineering Manager @Appliscale | Co-founder @DiPA
3 weeks ago in Epic Games just open-sourced their own version control system called Lore.
The problem it's solving is real and largely unsolved: Git breaks the moment you have large binary assets. A game project with 4K textures, compiled shaders, physics meshes - you're not diffing those. You're duplicating them on every change. At scale, that's hundreds of gigabytes just to check out a branch.
So studios ended up on Perforce. Works, but expensive and proprietary.
Lore takes a different approach. Content-addressed storage - so identical chunks across files are stored once. On-demand checkout - you pull only what you actually work on, not the whole repo. And immutable revision history with cryptographic signatures, which honestly every version control system should have by now.
What caught my attention is that this isn't just a games problem. Robotics, hardware design, ML training data - anything that mixes code with large binary artifacts hits the same wall.
MIT licensed, multi-language SDK, maintained by Epic.
Link in comments.
Anyone here actually running something like this at scale? Curious what the alternatives look like in non-game domains.
View on LinkedIn
