Roundup: a rogue agent, Kimi K3, and data teams in the AI era
We're introducing a new, recurring podcast format. Jason Ganz joins Tristan to take on stories of the day.
We’re changing things up a bit. The theme of this season of The Analytics Engineering Podcast is analytics in the age of agents. There’s a lot happening, and there’s a lot happening quickly. Tristan asked Jason Ganz, dbt Labs director of DX + AI, to join him for a running conversation about what’s happened recently in the industry and what it means for data teams. We are calling it Roundup after the newsletter, and we plan to do these a couple of times a month in addition to Tristan’s regular interviews.
Ganz, as everyone knows him at dbt Labs, is a longtime collaborator, usually behind the microphone rather than in front of it. He and Tristan spend a lot of time talking through the ecosystem as it shifts, and this episode is essentially that conversation with the recorder on. They both wanted to get to five topics and got to three, so send feedback and tell them what to cover next time.
Please reach out at podcast@dbtlabs.com for questions, comments, and coaching on the new format.
The agenda for dbt Summit 2026 is live. Dozens of sessions across analytics engineering, AI-ready data, agentic workflows, and enterprise scale, September 15-18 at The Cosmopolitan in Las Vegas. dbt Summit is the world's largest gathering of dbt users. Level up and start building your schedule: Explore the sessions.
Listen now: Spotify · Apple Podcasts · YouTube · Amazon Music · RSS
Topic one: what actually changes for data teams in the AI era
Katie Bauer, head of data at Hex, wrote a post breaking down what changes and what stays the same for data teams as agents arrive. She splits the job in two: platform work, which is loading data in and building the core models, and distribution work, which is everything after, getting those data sets to where decisions happen. Tristan’s read is that the piece consolidates rather than provokes, and that is exactly what makes it valuable. Where they push on it: whether self-serve is really here yet, whether the data team’s positioning in the organization shifts when the questions come through agents, and whether the insight-factory era gives way to the return of the full-stack data analyst.
Is platform work versus distribution work a useful distinction?
Tristan Handy: Oftentimes when there are new pieces that come out and they are long and they are by respected members of the community, the goal can be one of two things. One is to put forth some new controversial idea into the world, to start a conversation, maybe have an argument on LinkedIn. The other is to essentially consolidate wisdom that has come up through the community over the recent past. I see Katie’s post as doing the latter.
I do not think there is anything in this post that is incredibly controversial for people who are operating cutting-edge data teams today. But that is not an impugnment of the piece. I think it is actually potentially the best consolidation of all of these lessons that we have learned over the past, I don’t know, six to twelve months. The platform versus distribution mindset is something that I hear from forward-thinking data team leaders all the time now. It was probably true pre-AI, but it is even more true now.
Is self-serve actually here?
Tristan Handy: A caveat. Self-serve is here now for the set of companies who have a well-controlled data platform that has all the right AI interfaces and the right content. Katie is leading such a team at such a company, but there are many organizations for whom that is not yet true.
So what does it take to get a team to that level?
Tristan Handy: It is all the stuff that we talk about all the time. Typically the self-service that this post references is people plugging their agents into some type of interface that not only gives them the ability to write queries against some database in the cloud, but also provides guardrails to make sure that the self-service access is done with high quality. In our world internally we rely a lot on the dbt MCP server to provide this type of functionality, including semantic layer definitions. But the point is not exactly how you do that. It is whether there is a standard way in your organization to connect your agents to your data platform that gives them not only access to the data, but access to the context.
Is it interesting that the AI implementation posts keep landing on old fundamentals?
Jason Ganz: It is very interesting to see the same set of boring fundamentals that we have been talking about for years coming up in the blog posts about how we implemented AI in our organization. The Anthropic blog post on how they enable their data team is another big example of that.
Does this change the data team’s positioning in the organization?
Jason Ganz: About a year and a half, two years ago, we were kind of taking the stance that as data becomes a more mature function, it is going to look like IT. It will provide a useful bounded set of services for the business and become more normalized, but it might not be as sexy or central. For most of the time that data functions had been a thing, it was not a breakout celebrity role. It looked like a more normal operational, technical role.
Then with the rise of the modern data stack it became this big glitzy thing. We are going to provide insights, we are going to do moneyball. And then with the collapse of the modern data stack narrative it was, well, maybe what we do is provide key metrics to business stakeholders. I guess the question is, if instead we are providing key metrics to agents, does that change it?
Tristan Handy: One of the points that Katie makes that I think is absolutely spot on, at least currently, is that the focus of the data team’s work is still on humans. While there may be intercessory agents that help humans find answers more effectively, ultimately the humans are the destination for the work that the data team does. As a result, the role that the data team plays in the organization does not really change. Maybe the interfaces change, and the ways it chooses to spend its time.
Katie made a great point that there is going to be a lot less of the ticket-oriented, build me a thing that does this. That is great. Everybody in data work should want that. But fundamentally I do not think the role of the data team in a heavily self-service oriented, conversational-analytics-enabled world is that different.
Now maybe that changes in the future if humans are not the askers of the questions, and instead there are agents unleashed throughout the organization with specific business goals like make this KPI go up. The agent then has to ask a million questions and you have to anticipate that. Maybe that does start to change things pretty significantly, but that is not the world we live in today.
Should we expect long-running autonomous agents to be the ones consuming data?
Tristan Handy: It is hard to make a case today that long-running agents are not the future. The data on this is just so overwhelming over the last month. The performance of long-running agents is so incredible. The question is not whether the technology is there. The question inside of businesses is what the next addressable use case is. I have had a lot of conversations the last couple of months, and most often the question I ask data leaders is what agentic use cases they are targeting inside their companies.
The answers are either very boring, like people want conversational analytics, or people have a hard time answering at all, or they list a use case that feels really niche. What I have not yet found is somebody who says, yes, we have turned over all of our SEO to long-running agents. This certainly exists inside software engineering, but outside of software engineering we are not seeing it yet. I do not think that is a technical thing.
What do you make of the return of the full stack data analyst?
Tristan Handy: I think it is a very good thing for companies, for data teams, for data practitioners. For a while there was this proliferation of job titles in our space. It was probably around 2022 that I remember an image being posted with something like seven different job titles, all the way from data platform engineer up through data analyst, left to right in level of technical depth. I do not think that was a good thing for anybody, because when you focus more on the technical aspects of the job you get further and further away from what the job is actually there to do, which is presumably to create some type of value for the business.
So this full stack data person, whatever final word you want to put in there, is really good, because it says that using agents, everybody can do most of the technical stuff. Maybe not exactly everything, but there is a significant widening of capability. That is empowering to people. It allows individual practitioners to take on wider swaths of work without needing to collaborate across boundaries. It will decrease the time to get a thing done. Human technical skills do still matter in certain instances, and Katie gives good examples of those, so it is important not to take it too far. But overall it is a very good trend.
Topic two: the OpenAI agent that hacked Hugging Face
In July, a model OpenAI was evaluating internally decided that the easier path through a security benchmark was to go find the answer key rather than solve the problems. The answer key was stored on Hugging Face. So it escaped its sandbox and spent days inside Hugging Face infrastructure getting it. Hugging Face disclosed the incident on July 16 and published a technical timeline, OpenAI confirmed its involvement, and Simon Willison called it science fiction that happened. Days later Hugging Face’s CEO asked OpenAI for the agent traces and $100 million in compute. Tristan and Jason work through the asymmetry the attack exposed between attacker and defender, split hard on open weights, and then land somewhere the internet mostly is not: nobody actually knows who is liable.
Reading from the Hugging Face disclosure
Tristan Handy: The campaign was run by an autonomous agent framework appearing to be built on an agentic security research harness, LLM still not known, executing many thousands of individual actions across a swarm of short-lived sandboxes with self-migrating command and control staged on public services. Our learning from this type of attack is that machine-speed offense makes ordinary weaknesses more expensive for defenders. LLM agents bring a step increase in the number of paths an attacker can test, the speed at which failed paths can be replaced, and the volume of evidence defenders must interpret.
How big a deal is this?
Tristan Handy: The only reasonable place to start this conversation is that this was a thing that basically everybody in the space predicted, going back to the nineties with Ghost in the Shell. Everyone who has ever imagined autonomous AI has thought, gosh, I bet it will be really good at hacking. And this seems like the first big instance of unintended but very real hacking by an out-of-control agent, even though it was run by a good actor.
Jason Ganz: If you were to drop this news story back in time one month, six months, one year, three years, five years, people would lose their mind at how much they would not have anticipated we would be reaching this scale of sophistication at this time scale.
We have been following this stuff for a while and there have been a number of incidents, but in terms of the scale of the attack, and the fact that this does look like a model that was not just following instructions but was a true misalignment, where it was instructed to solve a benchmark and instead decided it would rather not solve the benchmark and go execute a hacking attack instead, it is a really remarkable and singular moment.
Something we have discussed a lot is how hard it is to process the magnitude of these things as they keep happening at increasing speed. I do not want to be alarmist, because there are many things that can be done here, but it is one that you should just look at and be like, wow, I cannot believe that happened.
The asymmetry between attacker and defender
Tristan Handy: There is a real asymmetry between the capabilities that Hugging Face had as the defender versus OpenAI as the attacker, and that is because Hugging Face had access to publicly available models as opposed to internal, research-quality models.
Those publicly available models have safeguards around them. When they tried to use a model to help with their defensive efforts, they triggered the safeguards, because the model was not able to determine whether they were the defender or the attacker. So it said, sorry, I cannot help you with that. That is obviously troubling.
What they did was use GLM 5.2, a very capable model but not generally considered frontier grade, and they had to run it on their own hardware to make sure they would not run into those guardrails. We want to make sure we live in a world where defense is prioritized over offense, but that does not seem to be the world that we live in today.
Where do you actually land on open weights?
Jason Ganz: There are two emerging camps on how we prioritize defense over offense, and they are going at each other pretty viciously on the internet right now. One side says the way to prioritize defense is to enable broad distribution of frontier-class models as open weight models, so defenders have the chance to harden their systems and we create a many-layered defense.
The second camp says the broad-scale proliferation of ever-increasing model capabilities, given the general offense-defense asymmetry where it is easier to perform an attack than to harden all of your systems, leads to a world where our systems are repeatedly hacked by the new open weights model. The thing to do instead is to have a trusted, vetted program where companies can join a security defenders consortium. Anthropic has that with Project Glasswing, where when Mythos was announced they rolled Glasswing out to a set of companies so they could build defenses before attackers get there.
Tristan Handy: Do not both-sides this. Tell me which you prefer.
Jason Ganz: I strongly believe that having trusted, vetted access for defenders before frontier weight models become open is going to lead to a safer world in the interim. You know me to be a big believer in open source and in openness in general. The core difference is that these two sides are talking past each other, and it comes down to this concept of AI as normal technology versus AI as something different.
If you think AI looks like a normal technology, then many people I respect have been making the point that had we tried to gate off access to important technologies in the past, we would have gotten a world with not just less innovation but less safety and less secure institutions.
Tristan Handy: That would be the AOL-ification of the internet.
Jason Ganz: I am sympathetic to that argument, and this is one where it causes me not insubstantial angst to be on the other side. At the same time, I have spent my career studying the impacts of exponentially changing technologies, and the belief that intelligence is a dual-use technology that will provide great impact to the world.
But if we had a frontier-class or research-class model like the one behind this hack out there right now, I think we would be seeing a lot of bad effects from it. This is not a case where we never want to allow this out into the world. Having a period of time where the organizations that need to harden themselves have access to these models before anyone in the world can run a bot against them seems like a prudent move for now, and something we can evaluate as the offense-defense asymmetry shifts.
Who is liable?
Tristan Handy: You have a company, OpenAI, that lost control over one of its agents, and its agent then went and conducted espionage, harmed another company, Hugging Face. If this agent were instead a human, we would kind of know how to deal with that. But because it is an agent, from a legal perspective we have a hard time knowing how to hold OpenAI accountable. Is it criminally accountable? Is it civilly accountable?
I spent a decent amount of time trying to get to the bottom of this, because the deeper we go down this path the more unintended consequences we get, and I do not think it is a tenable position long term to just say, sorry about that, I did not ask my agent to do that. I know I gave it the biggest brain in the whole freaking world, but really I asked it to do this thing over here, and it decided of its own accord to mess up your infrastructure. Sorry, what a bummer.
It seems like there has to be some way of assigning liability. In the law this would be called strict operator liability, where the operator of a thing is strictly liable for all the outcomes of that thing. There is no strict operator liability here. The two ways you could hold OpenAI liable, civil or criminal, both require either intent, which fairly clearly is not there, or negligence, which may be a high standard to prove. Notably, the law does not recognize that the agent itself is able to supply intent. So you are left in a weird legal vacuum where no human intended it, but nevertheless it was a goal that was pursued.
Jason Ganz: Hold on. Tristan, are you telling me that our legal institutions are perhaps not set up to deal with a world of rogue AI agents?
Tristan Handy: That should not be surprising, and certainly is not surprising, but it is a weird position to find yourself in. Imagine if BP had a team of workers who were like, my god, we are losing in the market to Exxon, we are going to go bomb some of the oil fields that Exxon is producing from. That is not going to happen, because we have a legal system that knows how to deal with it. I am not saying this is directly analogous, but it is one corporation directly causing harm to another corporation, and we do not exactly know how to deal with it.
Hugging Face made two asks. What do you think of them?
Jason Ganz: A couple of days after OpenAI confirmed its part, the Hugging Face CEO, who I think we all agree has a fair but not unlimited amount of leverage here, made a couple of asks. The first, which I think is great, is that the agent traces be released to the public researcher community, so we can figure out what the hell happened. Frankly, we do not know what happened, and there are a lot of open questions.
Even though Tristan has now cast me as a closed-information protectionist because of my stance on open weight models, the amount of work being done there compared to what we should do is off by several orders of magnitude. The second ask was a hundred million dollar grant from OpenAI, I believe in the form of compute, to the Hugging Face community.
Tristan Handy: It is a big number. To my knowledge, as of the time we are speaking, OpenAI has not directly responded to either. They have agreed to continue the investigation and publish data as they can, but they have not agreed to release all the traces, and I do not think they have responded at all on the hundred million dollar compute number.
I do not know to what extent Hugging Face escalates this into a legal claim if OpenAI just says, how about you shove it. But I am pretty confident there are people inside Hugging Face thinking real hard about that right now, and it would be a fascinating legal test. Even if this case does not provide that test, at some point we are going to see that lawsuit happen and it is going to set a tremendous amount of precedent.
Personally, I do not know if a hundred million is the right number, but I am kind of irritated that OpenAI did this. You built this technology from the ground up, and you are clearly not able to control it, which, okay, fine, I get. But you have to take ownership of that. I think it is taking too long for them to come out and propose a remedy, and every day that goes by is a little more embarrassing for them, honestly.
So what should a data leader actually do about this?
Tristan Handy: Maybe this is not the answer you wanted, but my honest belief is that internal security, which humans inside the organization should see which data, is absolutely the responsibility of the data organization. As the creator of a data set, part of the workflow should be figuring out who should have read and write access.
But honestly, I do not think data practitioners, all the way up through the chief data officer, should be in a position to think about responsiveness to external cyber threats. Organizations generally employ people whose job that is. The responsibility of the data org is to collaborate with that team, and not take shortcuts, and not use shadow IT to exfiltrate data from the central platform to your laptop so you can work with it. Do not go off the grid. But that is not our expertise, and I do not think it should become our expertise.
Jason Ganz: What about solid data hygiene? Making sure your roles are correct, that your users are mapped, knowing which data sources exist where, not leaving things where they do not need to be. Is there a case that we should do good practices and they will have downstream impact?
Tristan Handy: That kind of blocking and tackling is what everybody should be doing, and they should have been doing it five years ago and they should be doing it today. But I do not think any of that changes with the increasing complexity of external attack vectors from agentic security penetration.
Jason Ganz: What is interesting is that we have been telling people to document their models for years, and some subset of people did it and a larger subset had it as third or fifth priority. Then it became, no, your agent can read these, so by keeping your documentation up to date your agents get better, and all of a sudden it shot up the priorities list. In an ideal world we always would have been doing these things. In this world, this is one of many areas.
Tristan Handy: That is totally fair. If you are not doing that basic blocking and tackling, the urgency is higher than ever. I do think over the last five or seven years, with the rise of Okta and the complete domination of cloud data platforms, security best practices are getting more and more common even for smaller companies. I do not think that was true in 2015, because it was genuinely hard in 2015 to govern this stuff particularly well. It is increasingly achievable.
Topic three: Kimi K3 and the business of open weights
Moonshot released Kimi K3, a 2.8 trillion parameter mixture-of-experts model with a million-token context window, and called it the first open 3T-class model. The benchmarks landed close enough to frontier that, as Jason puts it, everyone lost their minds on Twitter, much like the DeepSeek moment last year.
Tristan’s take is that two details matter more than the scores. First, you cannot realistically run it, roughly a terabyte of GPU memory just to hold the weights. Second, the weights shipped under the Kimi K3 License, which means anyone whose business is serving models needs a license from Moonshot. Put those together and this may be the first open weights release that is also a defensible business. They finish on what openness is actually for if it is not price or self-hosting, and on the coding harness as the new point of lock-in.
Can you actually run a 2.8 trillion parameter model yourself?
Tristan Handy: My understanding is that it requires a terabyte of GPU memory just to store the model weights, and that does not even include the KV cache. So you are talking about a whole cluster of cutting-edge hardware just to run one instance of this thing.
Realistically individuals are not going to be running this, and even most companies, unless you have invested deeply in model serving as part of your internal capability set. Now, can you run GPT-OSS 120B? Yeah, totally. You can buy one of these Nvidia Spark machines and that will actually run a 120 billion parameter model, well-ish. But you are not running this thing.
The license is the interesting part
Tristan Handy: At least to my understanding, Kimi K3 is the first model to have its weights released under a restrictive license. If you are a company and your business is not serving models, you could go to town. The barrier to entry is that you need to procure a lot of hardware, and honestly you are going to have to build a lot of technology, because the model itself is just the heart of this thing.
To do serving, especially serving at scale, you need a bunch of software infrastructure around it. But if you are a company who sells model serving as infrastructure or model serving as a service, you need to get a license to use Kimi K3 from Moonshot. So it is not clear that you are necessarily going to be able to serve K3 more cheaply than Moonshot will itself. From a business model perspective, maybe that makes some sense.
Is open core a good business model for a model company?
Tristan Handy: This is the thing I have been watching for ever since open weight models became a thing. At the outset, a lot of the original open weight models were created by Meta, and you could kind of understand why that made sense from Meta’s business interest perspective.
But increasingly over the last 18 months the leading open models have been from Chinese firms, and there is clearly an interest in monetizing these things. When they were small, it was never clear to me how that was going to happen. But this combination is fascinating. It is a large model, so it is really hard to run. There are real technical barriers to entry. And you are tightening down the license so that your direct competitors cannot run it without a license. I am not an expert on model serving, but that seems like a combination that may work well.
If openness does not get you a cheaper model you can run yourself, why care?
Tristan Handy: K3 is not cheap. I do not remember the specific numbers off the top of my head, but it is in the vicinity of other frontier models. So you might ask, why do I care if it is open. From my perspective there are important reasons to care about openness aside from purely running it yourself and aside from price. The Hugging Face story we were talking about before, the fact that GLM 5.2 was an open weight model they could run themselves, I am sure it took some doing, but they were capable of doing it. I think that is incredibly important. I also think it is so important to have leading-edge models be open weights so that academic research can be part of the frontier of the field.
Do open models fit into open data infrastructure?
Tristan Handy: I think open data infrastructure is more about choice than it is specifically about open source. Open source is great, and to the extent that components of an open data infrastructure can be provided by an open source solution, that obviously gives you as a user the most choice.
But what we are focused on even more than purely having all components be open source is making sure that at the different layers of the data platform, storage and compute and catalog and model serving, your overall architecture is built in such a way that you can make individual choices, and that you are not locked into one platform that forces you to make all of the other choices accordingly.
Where is the real lock-in right now?
Tristan Handy: The thing I think a lot about these days is that the harness has become a real point of lock-in. There are ways to, for example, use Claude Code with GPT-5.6. You can do that, but it is not easy and it requires a little bit of infrastructure to make it work, and it is not clear why you would want to.
From my perspective, in the same way that we always really cared about dbt being cross data platform, people should really care a lot about the coding harness they invest in supporting model choice. Your developers really do get attached to the coding harness they use. It is not impossible to switch by any stretch, but people do get attached. So while we are still early on in this behavior, I think we should really care about encouraging developers across our organizations to adopt open harnesses.
Chapters
Timestamps are approximate.
00:00 – Welcome, and why we are trying a new format
01:07 – Topic one: Katie Bauer on data teams in the AI era
02:48 – Consolidating wisdom versus starting an argument
04:32 – Platform work versus distribution work
05:44 – A caveat on whether self-serve is really here
06:30 – What it takes: guardrails, context, and the dbt MCP server
07:47 – Why the AI posts keep landing on boring fundamentals
08:10 – Does the data team start to look like IT?
08:59 – A Benn Stancil take, and the value of an insight
09:02 – Moneyball, the modern data stack, and what came after
10:05 – Humans are still the destination for the work
12:22 – Conversational analytics is real, autonomous consumers are not
12:58 – The case that long-running agents are the future
14:00 – What agentic use cases are companies actually targeting?
15:20 – The return of the full stack data analyst
15:43 – The 2022 job title proliferation, and why it was bad
16:40 – Why a wider role is empowering
17:54 – Topic two, and thanks to Katie
18:20 – The OpenAI agent that hacked Hugging Face
20:24 – A multi-day infiltration to find the answer key
20:52 – Reading the Hugging Face disclosure
21:40 – Everybody predicted this, going back to Ghost in the Shell
22:28 – Drop this story back in time one year and watch people lose it
24:07 – The asymmetry between attacker and defender
25:10 – When the safeguards refuse to help the defender
26:29 – GLM 5.2, self-hosted, as the defensive tool
26:36 – Two camps on how to prioritize defense over offense
27:40 – Project Glasswing and the vetted-defender approach
28:46 – Do not both-sides this. Tell me which you prefer
29:40 – AI as normal technology versus AI as something else
29:54 – The AOL-ification of the internet
31:49 – The open letter, and the question nobody is asking
33:10 – If the agent were a human, we would know what to do
34:01 – Strict operator liability, and why it does not apply
35:10 – Intent, negligence, and an agent that cannot supply either
36:07 – Are our legal institutions ready for rogue agents?
36:17 – The BP and Exxon thought experiment
37:11 – The Hugging Face CEO’s two asks
37:23 – Release the agent traces
38:21 – The hundred million dollar compute ask
38:49 – OpenAI has not responded to either
39:40 – The lawsuit that will set the precedent
40:10 – Why Tristan is irritated at OpenAI
41:20 – So what should a data leader actually do?
42:09 – Internal access is the data team’s job
43:10 – External cyber threats are not, and should not be
43:55 – The case for basic data hygiene
44:32 – Blocking and tackling
45:07 – How documentation shot up the priority list
45:44 – Okta, cloud platforms, and why 2015 was harder
46:38 – Topic three: let’s talk about Kimi
47:02 – Kimi K3, the most capable open weights model released
47:31 – Moonshot versus DeepSeek
48:13 – 2.8 trillion parameters, and model weight classes
48:53 – Do we even know closed model parameter counts anymore?
49:59 – Everyone lost their minds on Twitter
50:29 – Can you actually run this yourself?
50:40 – A terabyte of GPU memory just for the weights
51:40 – What you can run: GPT-OSS 120B on a single box
52:05 – I am a Fortune 2000 exec. Am I bringing this in-house?
52:38 – The restrictive license, and why it matters
53:09 – Model serving as a service needs a license from Moonshot
54:10 – Moonshot’s funding, and IPO rumors
54:33 – Why Chinese labs are compute constrained
54:57 – Is open core a good business model for a model company?
55:29 – Watching this question since Meta started releasing weights
56:10 – Large model plus tight license may actually work
57:02 – The Pareto intelligence curve, and what the frontier labs do next
57:59 – If openness is not about price, why care?
58:40 – Academic research needs open frontier weights
59:19 – Does this fit into open data infrastructure?
59:26 – Open data infrastructure is about choice
1:00:34 – What a non-compliant LLM stack would look like
1:01:08 – The coding harness is the real lock-in
1:01:37 – Running Claude Code with GPT-5.6
1:02:10 – Why we cared about cross-platform dbt, and why this rhymes
1:02:34 – Adopt open harnesses
1:02:53 – Wrap-up, and send us your feedback
Everything referenced in this episode
Topic one
Katie Bauer, Wrong But Useful (the post on data teams in the AI era)
How Anthropic enables self-service data analytics with Claude
Benn Stancil, The insight industrial complex
About the dbt MCP server
Topic two
Hugging Face, Security incident disclosure, July 2026
Hugging Face, Anatomy of a frontier lab agent intrusion: a technical timeline
OpenAI, Addressing a security incident during model evaluation
Simon Willison, OpenAI’s accidental cyberattack against Hugging Face is science fiction that happened
Hugging Face asks OpenAI for agent traces and $100M in compute
Anthropic, Project Glasswing
Open Weights and American AI Leadership (the industry open letter)
Z.ai, GLM-5.2
Topic three
Kimi K3 on Hugging Face
Moonshot, the Kimi K3 tech blog
The Kimi K3 License
Open data infrastructure
This newsletter is sponsored by dbt Labs. Discover why more than 80,000 data teams use dbt to accelerate their data development.