Meta’s StyleX compiles thousands of styles into a few reusable class names at build time—zero runtime, fully type-safe. Scott and Wes break down why it’s suddenly everywhere, and why it might be the best CSS tool for AI agents.
We believe the future is a multi-model, multi-harness world. And we think it needs a new trust model.
In 1988, Norm Hardy described a problem that had been quietly breaking systems for years: the confused deputy. A program that takes action using its permissions instead of yours.
Today, every AI agent is that deputy. It inherits your authority: Your credentials, your repo access, your ability to call APIs. But its behavior is probabilistic. It might be acting on an instruction found in its environment, on a step it invented, or on a confident wrong answer.
The industry didn’t fix the confused deputy problem by making the deputy itself more careful. They fixed it by moving its authority a layer away. Forty years on, that’s still the answer.
Everyone is converging on the same future
Three facts are pushing the industry toward the same conclusion.
Agents are expensive loops. An agent takes many steps, and you pay for every token of every one. We all can agree that it makes no economic sense to call the latest frontier model for simple tasks.
The leader of frontier capability changes often. We’re all aware that the top model of the day (and its vendor) changes every couple of months.
Your workflows may need custom models. Many teams are recognizing that intelligence is commodifying and the differentiator is custom models, derived from custom context.
As a result, all of us are quickly ending up with a portfolio of multiple models across multiple harnesses.
A similar convergence is happening one layer up. Developers pick certain tools for the right task, the way they always have. For example, perhaps Claude Code for long refactors, Codex for daily work, Hermes for quick scripts.
It’s reasonable to expect the future of work to be multi-model and multi-harness.
Which makes trust the defining question
A lot of agents work the same way.
They read material that is often out of our control: support tickets, web pages, documentation, and code written by strangers. But they act with authority you granted: your credentials, repo access, production APIs, and the open internet. And they usually do both from a developer’s laptop, outside typical security guardrails like VPCs and IAM.
Private data and the ability to act autonomously, together, is what makes an agent worth deploying. Your deputy needs the ability to execute in order to be useful. Which means the interesting question is no longer which model is best. It’s what happens when one of these deputies is wrong, or manipulated.
Per-harness guardrails break down
The obvious answer is that each harness ships its own guardrails. Many do. But relied on as your security boundary, they fail in three ways.
The agent talks past them. Guardrails inside the harness are enforced in the same loop the agent is running. Deny it a git push and it reaches for the API. Deny the API and it opens a gist. Deny the gist and it tucks the data into a channel you trust and never inspect. Researchers showed last year that a single malicious issue filed in a public GitHub repo could steer a coding agent into reading a company’s private repositories and publishing the contents in a pull request the agent opened itself. Nothing was hacked since every step used the agent’s own legitimate access, through a channel everyone trusts. A boundary the agent can negotiate with is not a boundary.
The rails move without you. Most harness’s isolation models are closed source and ship on their vendor’s schedule. The major coding agents have each revised their default sandbox and approval behavior several times in the past year alone. Updates to sandboxing models should be treated as a security event. Multiply this by ten harnesses and your security posture is, at any moment, whatever is the patchwork of your half dozen vendors’ measures.
The rails don’t cover the fleet. The custom agent your platform team built has exactly the guardrails your platform team wrote. The agent inside your support SaaS has whatever its vendor chose, and most expose no isolation controls to you at all. Every new harness means building or auditing governance again, from scratch, differently. You end up with a dozen implementations that drift apart, each blind to the others’ traffic, with no single place to set a rule and no single record to understand why something went wrong.
Safety cannot depend on the agent making the right decision, or on someone else’s release schedule.
A layer below
So here is what we believe. The future is multi-model and multi-agent. And given that future, we believe every organization will need a layer below: a runtime layer, below the harness, that all of them run on top of.
The reasoning is straightforward. Strip away the model, the vendor, and the framework, and an agent has two ways to affect anything. It runs code, which touches files and opens network connections. Or it calls a tool, which acts on a system. Everything an agent does travels one of those paths. And both paths cross the same surface: the runtime, where processes execute, credentials get used, and requests leave the machine. Every agent passes through it, no matter which model powers it, which vendor shipped it, or whether you built it yourself. That makes it the one place where rules you define can be enforced across all your agents. It is also the same fix as 1988, applied to today’s deputy: the authority sits a layer away.
Put enforcement there and each of the three failure scenarios we spoke about flips around.
Your agents can’t talk past themselves. The boundary for an agent sits outside the loop the agent is running, so it holds steady no matter if the model is with you, hallucinating, or compromised. A hard neutral boundary at the runtime is more effective than a prompt-level boundary the agent creates for itself.
The rails stop moving randomly. Policy is yours, written once, covering execution, tool calls, credentials, and spend. Now, a model or agent vendor making an update won’t randomly change your security posture.
The rails cover your whole fleet. A policy you write up will apply to every harness. And every action, by all your agents, lands in one record: what ran, what it touched, which rule decided.
This is what lets you be nuanced about agents. Without a boundary below your harnesses, you have three bad options: block agents completely, allow all of them and hope for the best, or wedge a manual approval into every step and give up the productivity you wanted.
A boundary at the runtime gives you a fourth option. When consequences are bounded even if an agent goes off the rails, you can start granting it true autonomy, which is the goal.
We expect models to keep changing and new harnesses to land in all of our toolkits. That part is healthy. The boundary underneath them is the part that should hold steady.
At We Are Developers in San Jose, Tushar Jain, Docker’s CTO, will talk more about this world: multiple models, multiple harnesses, and a single runtime under it all.
AI evaluation has never been easier to start. Reproducing it reliably is another story. Developers now have access to more benchmarks, evaluation libraries, model APIs, and agent frameworks than ever before. But keeping the prompt, model, and scoring method fixed doesn’t necessarily make a run reproducible. The execution environment matters too.
Python dependencies change. Local tools drift. Setup steps go undocumented. A workflow that succeeds on one machine may behave differently on another. Most discussions about evaluation focus on what should be measured: benchmarks, scoring methods, or judge models. Much less attention is given to how those evaluations are executed. Yet that execution layer often determines whether someone else can reproduce the same workflow weeks or months later.
When I started exploring Docker Sandboxes, I wasn’t trying to build another evaluation framework. I had a much smaller question.
Could Docker Sandboxes and an SBX Kit make evaluation workflows easier to rerun, inspect, and compare?
That question eventually became the SBX AI Evaluation Kit, an open-source Docker Sandboxes Mixin Kit focused on repeatable execution, structured evaluation records, and runtime evidence. The current implementation does not execute AI models or automatically derive evaluation judgments. Instead, it executes configured commands consistently and preserves evidence of what actually ran.
In Practice
In practice, the workflow starts by choosing where the evaluation command should run through the execution block:
With executor: sbx, the runner delegates command execution to Docker Sandboxes and writes the runtime evidence into the resulting artifact.
The repository is also packaged as an SBX Mixin Kit, so it can be applied when starting a Claude sandbox:
sbx run claude --kit .
The runner reads the configured executor and delegates the command to SBX, which executes it inside the sandbox.
python run_evaluation.py
From Documentation to an Executable Workflow
Each evaluation is defined in a YAML file that describes the evaluation and the command to run. The repository validates that definition, executes it, and produces a structured JSON record of the result. The difference is in what gets recorded. A written evaluation captures what someone intended to do. An execution-backed evaluation captures what actually happened.
Separating Evaluation from Execution
I wanted the evaluation definition to stay independent of where it ran. A workflow written during local development shouldn’t need to change simply because it later executes inside Docker Sandboxes.
To keep those concerns separate, I introduced an executor abstraction. The evaluation describes what should run; the executor determines where it runs.
With the local executor, the configured command runs on the host. With the SBX executor, command execution is delegated to Docker Sandboxes. Switching between the two only requires changing the executor configuration, not rewriting the surrounding evaluation workflow.
Figure 1. Evaluation definitions remain independent of the execution environment. The same workflow can use either the local or SBX executor while producing runtime evidence in the same structure.
Capturing Evidence Instead of Assumptions
For each execution, the runner records enough information to inspect what actually happened:
the selected executor,
the command that was executed,
standard output (stdout) and standard error (stderr),
the exit code,
and the execution time.
These details are stored in the evaluation artifact. The repository also generates a digest of the evaluation configuration. This creates a deterministic link between the evaluation configuration and the artifact it produced, without trying to replace full experiment-tracking systems.
{
"executor": "sbx",
"command": ["python3", "-c", "print(\"hello from sbx\")"],
"stdout": "hello from sbx\n",
"stderr": "",
"exit_code": 0,
"duration_ms": 120.0
}
Scaling from One Evaluation to Many
Real-world evaluation rarely consists of one isolated run. Teams compare prompts, validate behavior, measure regressions between releases, and test multiple scenarios. That led to evaluation suites.
Rather than changing how an individual evaluation works, a suite groups multiple evaluation definitions into a single repeatable workflow. Each evaluation still produces its own structured artifact, while the suite also generates an aggregated summary of the overall run.
Reusable SBX Kits Beyond Evaluation
The same pattern isn’t limited to evaluation. An SBX Kit can package more than a development environment; it can also package the setup an engineering workflow depends on. The same model could support regression testing, policy checks, security analysis, code-generation experiments, and other workflows that depend on consistent execution and inspectable results.
Conclusion
The SBX AI Evaluation Kit doesn’t replace evaluation frameworks, benchmarks, or scoring systems. Its job is narrower: execute configured evaluation workflows in a way that is easier to rerun and inspect.
The question I came away with is simple: before comparing benchmark scores or choosing a judge model, can someone else reliably run the same workflow under comparable conditions?
People feel differently about AI, and here at Firefox, we think that is completely reasonable. Something else that is completely reasonable: deciding for yourself how and when you engage with AI features.
For some of you, AI is part of your everyday life, whether you are using it to summarize a large amount of information, brainstorm ideas for work, or research trips and personal purchases. Some of you interact with AI as little as possible, and prefer to keep it that way. And a lot of you are somewhere in between: curious, but exploring on your own terms and at your own pace.
Your personal use of AI is just that, personal. Firefox offers various levels of AI integration into your browser, and the choice between them is entirely yours.
Block new and current AI features in a single switch
Opting out of upcoming and current AI features on your browser should not require endless navigation through multiple Settings pages. That’s why Firefox offers an AI controls section within its General Settings panel. A single, easily located place where you can block current and future AI features and related pop-ups with the swipe of a toggle.
Not only do we want people to have the choice to remove certain AI features from their Firefox browsing experience, we make sure doing so is as easy and accessible as possible.
Choose the features that work for you
For the many people who sit in the middle of the AI usage spectrum, we made sure you can opt in and out of specific features in line with your preferences. Capabilities like AI translations, image alt text in Firefox PDF viewer, tab group suggestions, and key points in link previews can all be individually switched on and off, ensuring you can enjoy such offerings on a case by case basis as it suits your needs.
In addition, if there is an AI chatbot provider you already trust or pay for, you can use it directly inside Firefox’s built-in desktop sidebar. This means you can use your chatbot of choice and browse side by side without ping-ponging between tabs.
While some browsers integrate a singular AI model or chatbot into their system, this can restrict flexibility and concentrate data sharing. Firefox prioritizes transparency and user control by letting you select from multiple providers, allowing you to review each option’s policies before you engage with them.
You can turn on AI chatbot providers in the AI controls section of browser settings and select one of the following: Anthropic Claude, ChatGPT, Google Gemini, and Le Chat Mistral. Once this feature is turned on, you can switch between chatbots within the sidebar itself based on your preferences and task at hand.
Smart Window, for when you want help finishing what you started
Smart Window is Firefox’s most integrated AI experience, but that doesn’t mean it compromises our commitment to choice, privacy, and transparency. Our newest window type, which we’ve been polishing and testing in beta, uses only the context you share with it to help you move work forward and across the finish line.
When permitted by you, its built-in, AI-powered assistant can work directly with your open tabs and browsing history to connect the dots. This means comparing information, generating recommendations, summarizing pages, and planning projects without having to feed every crumb of context from your previous and current browsing activity each time you enter a new prompt.
As we’ve built out Smart Window, we’ve added a few additional features to align its design with how people actually browse. These include the ability to group related tabs together – so you can make sense of what’s open without spending time organizing everything yourself – and visual history previews that help you spot a page you visited earlier when you can’t remember the exact URL or phrase searched. In addition, a new partnership with Exa enables Smart Window to not only locate current web information to include in responses, but also display the sources behind these responses so you can verify what you’re seeing, without breaking your flow.
We understand people use different Firefox windows for different reasons, and often switch between options based on the task at hand. Smart Window is the window you reach for when your browsing turns into a project. When your quick search becomes inspo for the girls’ trip you’ve been meaning to plan, or finding the perfect gift for your partner becomes a dozen tabs comparing prices and reviews, turn the window you’re already using into a Smart Window. Your tabs and progress stay in place while Smart Window helps organize the task and move it forward. Use it for one complex project, use it all the time, or switch it back when you’re done.
Smart Window remains in beta as we continue to learn and improve from our community’s feedback. At present, it’s available in English to people in the U.S. and Canada.
Your opinions and preferences on AI usage are individual to you.
We don’t think there is one right answer for how and when to engage with AI, and we’re not going to pretend there is one. What we can do is make sure that whatever level of engagement is right for you, Firefox supports it well. Because the only person telling you how much AI you need should be you.
Erik Darling here with Darling Data, enjoying a lovely LaCroix Pamplemousse seltzer. No booze in that whatsoever. Can you believe how lucky we are to enjoy a non-alcoholic beverage? Anyway, we’re going to do some more Learn T-SQL with Erik. In this video, we’re going to talk about cross-table date math, and I am going to catch myself and a funny little bit of irony in this one. Down in the video description, if you would like to purchase the full training content, there is a link with a coupon code attached to it down in the video description. Just below me here, just below this lovely fold here. There are also links for you to do other things, like hire me for consulting, become a supporting member of the channel, ask me Office Hours questions, and you can also, while you’re down there, like, subscribe, and tell all of your friends. Your beautiful, wonderful friends who would just benefit so greatly from watching these videos. If you are in the market for free SQL Server performance and availability group recently monitoring, you can get mine. There’s also links for this stuff. Totally free, totally open source, no phoning home, no weird stuff.
A brand new sort of version of the monitoring tool is available. Let’s go to Postgres and Timescale backend, and it has a headless Windows service, and it can monitor up to 500 servers, again, totally for free. It doesn’t cost you. It doesn’t cost you more if you want to monitor more than 500 servers. I would just maybe start a second install to monitor the other 500, because concurrency for that many servers, even in the wonderful world of Postgres, is maybe not so much fun. But, but let’s talk T-SQL here. That is, that is the turkey that we care about.
So, so we’re going to use this query, which, if I remember its provenance correctly, came from the Stack Data Explorer site. I can just never find it when I go look there again. But it’s, it’s, it’s, it’s the intent of the query is to find posts that had a lot of very early upvotes, and this query was always very slow, and to me, the interesting part of the query was that the where clause was looking for a date diff in columns on two tables. Now, under normal circumstances, if you had both of these columns in the same table, right, you could, you could, if you were denormalized a bit, but this would be a terrible denormalization.
You could create a computed column, but them being cross table, you don’t get that. SQL Server 2005 or so had this feature called the date correlation optimization, which could help in cases like this, but it required a lot of stuff, like, like a unique index on one of them. Which you can’t always get, and a foreign key between the two of them, which you can’t always get, because your data is filthy and cackadoodoo dirty because of your, all your nolak hints and whatever.
I don’t know, whatever. Let’s just go, go along with it. It’s funny.
So, it would be very hard to get that set up, but you, nothing is stopping you from creating an indexed view that can do the same or a similar thing. Now, this query runs for about, oh, five, six seconds or so. Oh, we got, we got a big five and a half second thing there.
And, you know, like one, like, this is not the thing I wanted to look at. It was being very silly. But, sort of, like, the important thing here is that, like, you know, you can, like, there’s only so much you can filter until the tables kind of get joined together, and you can finally apply, like, some of those filters, like the date diff one here, right?
The date diff in hours is less than or equal to 168, which is seven days, right? So, you have to, like, get all the rows from both tables and then do the join, and then you can start doing other things. And then you can start filtering your results to where they’re greater than or equal to 50.
And that’s fine, but, you know, if you want this type of query to be much faster, there are some things you have to do, right? So, you know, like, you might not find it very useful to seek to 40 million rows. I know I sure wouldn’t, but this is the way the votes table kind of breaks down.
So, you know, like, anything in here is going to not be fun. Like, nothing about this is going to be enjoyable. So, what I would recommend here is, especially if you are not in a situation where you can get the date correlation stuff working naturally out of the box, one thing I just want to point out about the original query, I’m going to make you sit through about five and a half more seconds of runtime here, is that, like, the majority, if not the total of these operators, aside from gather streams, are all happening in batch mode already, right?
Like, this is a nearly entirely batch mode query, and so, like, you’re already getting a lot of, like, the oomph that you would get out of this. You know, like, I guess if you want to add a non-clustered columnstore index there, you could, but we’re going to look at a slightly different way of handling it.
So, let’s come on down here, and what we’re going to do is we’re going to take a portion of the query that makes for a good indexed view. It’s not the full query, because I’ve talked about in other videos where we talk about indexed views. Making overly specified, overly specific indexed views will largely lead to those indexed views not being used by queries that could potentially benefit from them.
So, looking at all the, like, this is just, like, the base query that I would start with in here, and the idea behind it is just to get this part sort of squared away, right? So, we’ll create our unique clustered index as required in order to create other indexes.
And then there’s a neat trick with indexed views. Now, the indexed view documentation has some stuff about columnstore indexes. You can obviously not create a clustered columnstore index on an indexed view, because you can’t create a unique one, and the indexed view needs that.
But you can create a non-clustered columnstore index over an indexed view, and that can sometimes get you a very, very good mix of both the pre-aggregate and the batch mode that you would want. Did I actually run that?
It just happened very quickly. So, this all happened, it all happened in the blink of an eye. And now we can sort of, we can run this query, right, where we can get our sort of pre-aggregated list of stuff from the indexed view that has a count big of greater than or equal to 50, just like our original query.
And then we can join to our, just those rows to our query, and we can get ourselves a wonderful result that goes a lot faster. This all finishes in, well, because this is all happening in batch mode, we have to, and there’s no parallelism, we have to go look over here, and that the query time stats, and we’ll see this finished in 500 milliseconds of wall clock time with 460 milliseconds, 462 milliseconds of CPU time.
So, if you’re in an environment where these types of queries really have to be front and center fast, indexed views can go a long way to making them much, much faster. There are, of course, many caveats and drawbacks to indexed views.
Maintaining them on modification can be somewhat painful. And for this one specifically, which is something I’ve talked about many times in many other videos, when you have a cross-table index, when you have an index view with a join in it between one or more tables, not lock escalation, but isolation-level escalation can get pretty out of control.
You’ll also end up seeing a lot of serializable stuff that you didn’t ask for. SQL Server just does it automatically. So, you do have to be pretty careful and, you know, pretty conservative with how many indexed views you’re using and all that stuff.
But under the right circumstances, and especially if you start getting real crazy and creating non-clustered columnstore indexes on your indexed views, you can do a lot of really, really neat tuning stuff if the workload demands it.
Anyway, thank you for watching. I hope you enjoyed yourselves. I hope you learned something. I hope you’ll purchase the full course that this was just a tiny, itty-bitty little taste of and, yeah, all that stuff.
All right, cool. Thank you for watching.
Going Further
If this is the kind of SQL Server stuff you love learning about, you’ll love my training. Blog readers get 25% off the Everything Bundle — over 100 hours of performance tuning content. Need hands-on help? I offer consulting engagements from targeted investigations to ongoing retainers. Want a quick sanity check before committing to a full engagement? Schedule a call — no commitment required.
Log in
