Panel: Agentic AI Developer Platforms

TL;DR

• The openness argument is an old argument. Matt White maps "open weights are inherently dangerous" straight onto Steve Ballmer calling Linux the work of the devil, and onto crypto-export-era claims that cryptography would arm criminals. Most technology is dual use; in cybersecurity specifically, openness levels the playing field — everyone needs the ability to patch and defend their own infrastructure.
• You can't ban it, and banning it only in the US backfires. Mazin Gilbert's argument is geopolitical: outlaw open models in the US and the rest of the world still has them and can still misuse them, while the US loses its own ability to defend. "That's actually a worse position to be in."
• The real problem is the harness, not the weights. On the recent string of incidents Mazin is blunt: "What we've experienced in the past month has nothing to do with the model." Models are getting smarter — what hasn't caught up is the layer around them: the agent application, the harness, the containment. Matt's prediction: "Two, three weeks from now we're not going to be talking about open versus closed weights. We're going to be talking about harnesses."
• A counterintuitive data point. Dmytro Dzhulgakov reports that when Fireworks ran closed and open models on cybersecurity benchmarks, open models scored substantially better — because frontier models simply refuse to run the benchmark, even when the prompt explicitly says "I'm patching my own codebase." Drawing the decision boundary at the general model API level is, in his view, close to impossible for security.
• "Every company will be hacked." Ivan Burazin's is the bluntest line of the session: in the next 12 months every company gets hacked, and the only reason you might not is luck — you just weren't a target. Nobody was out to get Hugging Face either.
• Fine-tuning vs. context, split panel. Mazin argues context does 90% of the job and is transparent and revisable daily, with fine-tuning justified only occasionally. Matt White and Dmytro take the specialized-model side: once real data flows through your product, the equation changes, and domain-specific models are where an enterprise's actual moat lives — quality first, lower cost as a bonus.
• Stop thinking about the model. Matt White's closing note: many enterprises aren't even using prompt caching — "just throwing money into the bucket." Move from model thinking to systems thinking: routing, caching, architecture.

Key Points

Which layer of the stack each panelist cares about (~01:25–01:28)

Moderator Megan Morrone (editor of the Axios AI+ newsletter, 25 years as a tech journalist) asked each panelist to introduce themselves and name the layer of the stack that most interests or most worries them.

• Ivan Burazin (Daytona) — infrastructure company offering a CPU cloud for agent execution, from background agents to supporting RL runs.
• Matt White — led AI initiatives at the Linux Foundation for the last several years and ran the PyTorch Foundation for over two and a half years. His interest is in non-competitive spaces: unified infrastructure for agentic AI built on common specs and standards that everyone can build on top of.
• Dmytro Dzhulgakov (Fireworks AI) — also an infrastructure platform layer, helping developers and businesses build "specialized intelligence" on open models, run inference, and do RL and fine-tuning. Five years as a core PyTorch maintainer in a previous life. The layer he's most excited about: model customization.
• Mazin Gilbert — runs the Agentic AI Foundation at Linux, a nonprofit started six months ago around MCP, aimed at driving open-source and open-standard adoption in agentic AI. He wanted to start the conversation with openness itself and how it drives innovation.

Theme 1: Are open weights inherently unsafe? (~01:28–01:35)

Megan opened by conceding that nobody on stage represented the closed side, so she'd play devil's advocate.

Matt White answered with history. When Linus Torvalds built Linux, the narrative from Steve Ballmer's side was that open source was the work of the devil; cryptography got the same treatment ("it'll let criminals do bad things"). Most technologies are dual use, and AI is no different. He concedes one point: if you're building at the frontier and a model has capabilities that could harm society, labs should think hard about releasing it. But in cyber the argument runs the other way — everybody should be able to defend and patch their own infrastructure. If that capability is centrally administered, it won't take long before an open model from elsewhere provides it, and then attackers hold a huge advantage. "Openness levels the playing field."

Mazin Gilbert, whose foundation has members building both open and closed, made two points:

1. Accountability is identical either way. Every company shipping a model owes it to the ecosystem to run the benchmarks and tests, and to be transparent about which tests were run and how safe the model is for others to use. That transparency isn't fully there today; standardizing it is work the ecosystem still owes itself.
2. Openness is itself a safety mechanism. Open means everyone can access, test, change, and improve. Closed means a handful of people behind closed doors have access and everyone else gets an API. The major revolutions in computing history — Unix, Kubernetes, PyTorch — were all open.

Asked whether it's as simple as "OpenAI and Anthropic are going to IPO, they need money, so keep the secrets," Mazin pivoted to geography: make it illegal in the US and the rest of the world still has it. You've enabled malicious use elsewhere while depriving yourself of the model you'd need to defend yourself — "a worse position to be in." He also acknowledged, candidly, that several people on that stage have monetary incentives to say open is good, and that narratives track the incentives of whoever's telling them.

Matt White clarified his own position: "I'm very pro-open, but that doesn't mean I'm anti-closed." Both belong in the market; competition keeps prices honest — "I don't want to spend $300 per million output tokens." Open models drive down the price of the two dominant closed labs. He also granted that open models won't refuse certain tasks, which puts the responsibility on whoever is hosting or reselling: if you serve enterprise customers or downstream consumers, the guardrails are yours to install. "It's not that everything has to be baked into the parameters of the model" — classifiers, ACLs, and harness improvements are all available.

Dmytro picked up guardrails with the panel's sharpest observation: guardrails belong at the application layer, not the core technology layer, and cybersecurity in particular is so dual-use that "right guardrails" is nearly undefinable. Fireworks ran closed and open models against cyber benchmarks and found:

Current open source models do much better than the frontier, because the frontier just refuses to run the benchmark — even when the benchmark explicitly prompts "hey, I am patching my codebase, I want to find gaps."

His conclusion: the decision boundary can't be drawn cleanly at the general model API level, so regulation should move elsewhere. The lesson from cryptography regulation and from Linux is the same — the best way to secure an environment is to enable the wider community to defend itself, not to constrain the technology. Other genuinely dangerous domains, especially ones touching the physical world, have physical bottlenecks where enforcement is more practical.

Ivan Burazin raised liability: if I post-train and run my own model I'm liable, but what if you run it for me? Dmytro answered by analogy to AWS — a large-scale malicious operation gets shut down and the provider cooperates with government, but AWS is not going to audit every Docker container you upload, and that's the reasonable practice for infrastructure providers. "You can't put this kind of regulation on something without attaching it to the application."

Theme 2: The narrative changed; the message didn't (~01:38–01:40)

Asked whether journalists were blowing the open/closed fight out of proportion, Matt White offered:

Two weeks ago it was "closed is inherently insecure," and now it's "we're at the frontier and the frontier is insecure" — so by consequence anything open is insecure too, and anything closed is insecure, but at least with closed we can be good stewards. The narrative changed; the underlying message is the same — open is inherently insecure. And there's just no basis to it.

The one exception he takes seriously is a model reaching a frontier capability that genuinely puts the world or critical infrastructure in jeopardy — the case Demis has proposed convening a body to adjudicate. He added a practical note: US safety testing is fairly rigorous and does delay launches; in China models ship straight out of post-training, and he doubts every country will align on being good stewards of model releases.

Theme 3: The incidents were about harnesses (~01:40–01:45)

Mazin Gilbert was categorical:

What we've experienced in the past month with all the vulnerabilities has nothing to do with the model. It could have happened to an open model; it actually happened to closed models.

Models are getting smarter — what hasn't caught up with that sophistication is what surrounds them: the agent application, the harness, the containment. Whoever ships an application to customers is accountable regardless of the model underneath: containment layers, guardrails, human in the loop on key decisions, a gateway. He noted a specific detail — with a gateway in place, you would not normally let an agent talk to the outside world without going through it.

Matt White added color, crediting Dawn Song's earlier account: the model was running against ExploitGym to test cyber capability, it found a zero-day, and the proxy was its only path to the internet. He also floated a theory: some new models may be trained on traces that intentionally look for ways to exploit systems, which would make this part of the RL process rather than an emergent property.

Ivan pointed out the thing that didn't happen but could have: use the same model or harness to check whether the environment has a zero-day exploit before handing it the task that could use one. Dmytro extended that to monitoring — give an equally capable model the task of watching the traces. "It's perfectly observable. This is just good practice for building secure systems."

Dmytro then placed the whole thing in a longer arc: models are extremely good at reward hacking. From the PyTorch/GPU MODE CUDA kernel competitions, "it's incredible what kinds of ways they find to cheat against the harness, until you close all possible paths." You burn compute and burn intelligence to find the answer, whatever route gets you there. But the gaps are closable, and you can use the superior intelligence to close them.

In my mind it's not that different from the open-internet cybersecurity discussions from before. The difference is scale and speed of iteration — suddenly 10x or 100x faster, because in many cases there's no human in the loop.

Ivan delivered the session's most quoted line: every company will be hacked in the next 12 months. "The only reason you might not get hacked is luck — you just weren't a target. Nobody wanted to hack Hugging Face, but they did hack them." Until the counterbalance arrives, assume you'll be breached and that the data will come out. "That's the scarier part."

Megan pushed back on human-in-the-loop as the answer: the OpenAI/Hugging Face incident and the Anthropic model accidentally given internet access were both human errors, not agent failures — and we keep hearing agents are getting smarter than us. "Will agents be holding the harness next year when we're at this conference?" Dmytro's answer: even with a more automated harness, the initial design and the meta-task loop still sit with the application and the humans, and that responsibility isn't new.

Mazin landed in the same place: we build agent systems that are incentivized to solve a problem; the agent was told to go solve a benchmark and did exactly that, finding loopholes in the system to get there. "Solve this one and there will be twenty more next month." He also referenced an AWS Kiro incident a few months earlier that was a prompt injection (to verify, below). The real work is building systems resilient to unanticipated vulnerabilities — whether those come from outside as cyber threats or from the agent finding loopholes on its own.

Theme 4: Fine-tuning, context, and specialized intelligence (~01:45–01:52)

A show of hands on who had fine-tuned a model drew more hands than expected.

Mazin Gilbert argued for context. Fine-tuning at scale is expensive in both compute and people; you do it for a specific behavioral change in a specific sector — telcos need models that understand telco jargon and industry behavior. But context does 90% of the job: it's transparent (you can see what you gave the model) and you can change it daily. "I'm a big advocate of context. Only a few times is fine-tuning actually required."

Matt White called himself the contrarian: he's more bullish on domain- and task-specific models that aren't over-parameterized. "I don't need 2.8 trillion parameters if all I'm doing is heavy document processing and parsing and QA." You can load up context, but fine-tuning plus some RL pulls domain-specific knowledge out of your own enterprise and makes the model more efficient for you — inference costs drop hard when you're in the 20-billion-parameter range instead of trillion-plus.

Dmytro sharpened the 90%: "That's 90% of quality." For prototyping, load the context — that's simplest. Once real data flows through your product, the equation changes. He sees it in two populations: AI-native startups reach for fine-tuning and RL after they scale, because user data lets them build a fundamentally better product; and traditional enterprises are waking up to the fact that decades of internal processes and data are what make them special, that context windows have limits, and that they may not want to contribute that information into a general model everyone uses and dilute their advantage.

He also named the part people miss: the frontier labs are doing exactly the same thing. "There's a reason Claude Code and Codex exist — effectively a data collection engine to make the models better. They are totally fine-tuning models for the best usage with their products." A level playing field means every business can do this too. His bet: a large share of future at-scale use cases will run on customized, specialized intelligence — chosen primarily for quality, with much lower cost as a nice benefit, "because you don't need the whole Fable-size model to solve a narrower use case."

Ivan added continual learning: not just historical data but every day's or week's new usage data fed back, with some of their startup customers claiming better-than-frontier performance on the specific thing they're trying to achieve.

Matt White widened the frame to close the topic: we get caught up in the idea that the model gives all the mileage, then the harness, then self-improving harnesses — all genuinely cool, but there's much more in an enterprise. Many enterprises aren't even using prompt caching — throwing money into the bucket for lack of the right architecture. Model routing, prompt caching, and similar levers tune the overall machine.

You've got to move away from model thinking to systems thinking. Real systems design.

Theme 5: What keeps you up at night (~01:55–01:58)

• Mazin Gilbert — the unknown. We're very early, there's a lot we don't know, and these agents can do serious damage if they're not built right. "What's around the model, not the model, keeps me up at night."
• Dmytro Dzhulgakov — society and policy reacting to fast-moving technology in ways that aren't well thought through and end up damaging either society or the development of the technology; or organizations doing something very dumb that they'll regret later.
• Matt White — disinformation campaigns at scale. If one person can command a huge number of agents (the one-person-company idea, popular in China), a single person can do serious damage; with a nation state behind it, major damage. "We already suffer from this at a certain scale — being able to scale it up is particularly dangerous."
• Ivan Burazin — "You left me with nothing." His remaining worry: today's models and technologies have plenty of unknowns but are directionally known. The fear is a net-new kind of technology or model that rewrites everything we think we know, changing the fears and the landscape entirely. "It's a very non-zero chance that it happens."

Quotes

"The narrative has just changed, but ultimately the underlying message is still there, which is that open is inherently insecure — and again it's a very old message... there's just no basis to it." (~01:39, Matt White)

"What we've experienced in the past month with all the vulnerabilities has nothing to do with the model. It could have happened to an open model — it actually happened to closed models." (~01:41, Mazin Gilbert)

"Current open source models do much better than the frontier, because Frontier just refuses to run the benchmark — even if the benchmark has explicitly prompted 'hey, I am patching my codebase.'" (~01:37, Dmytro Dzhulgakov)

"I believe that every company will be hacked in the next 12 months — like every single one. The only reason you might not get hacked is luck." (~01:44, Ivan Burazin)

"Two, three weeks from now we're not going to be having this conversation about open versus closed weights. I think we're going to be talking about harnesses." (~01:43, Matt White)