Did you look at the OKF repo from Google? Open Knowledge seems to be a common term these days for similar solutions. I think OKF is more of the protocol for wiki-for-llm while you have more of the bells and whistles
I don't disagree with any of this. It is generated software, and it's not a novel idea. I didn't mean for it to come off like that. It's just solving an itch that I couldn't find a solution to and I'm getting a lot of personal utility out of it. I do have a lot of experience with agentic memory, multi-agent systems and harnesses and wasn't super impressed by the workflow of Fable calling opus subagents so I figured I'd apply best practices to what already exists to make it a teensy bit better and easier to use.
I've worked a lot with MiMo in my project that pits LLMs against each other in games (clankerfights.ai). It is a very very good model for the price. MiniMax I'd say is smarter, but MiMo really touches near pareto frontier.
Me and a buddy, victor teisller, hacked the most popular 3D printer a few years ago (flashforge) to turn it into a major fire hazard through reverse engineering the firmware update remotely. Changed the max temp of the extruder to the temp of the Sun lol. These things are a fascinating security target because they're an easy place to turn abstract digital hacking into physical repersussions that can literally murder.
Cross your fingers they're about to drop 4.7. 4.6 came out with a bang, now it seems all the compute bottlenecks just lead to customer frustration as they get closer to releasing next model. Balancing the books over there must be a nightmare, "Well we can piss off every single customer for a week, but we'll be able to release the next model 1 week faster"
All these comments about "this is crazy to deploy agents that might do something bad in your environment" are crazy themselves. The productivity gains from these computer use agents are crazy. Every org on earth has to make the call, is 3x productivity gains worth 2x the risk increase? The answer is almost always a resounding yes. You limit the blast radius if things go wrong, but the financial gain of having 1 employee to the work of 3 already pays for the disaster if it happens.
Sandboxing is a great security step for agents. Just like using guardrails is a great security step. I can't help but feel like it's all soft defense though. The real danger comes from the agent being able to read 3rd party data, be prompt injected, and then change or exfiltrate sensitive data. A sandbox does not prevent an email-reading agent from reading a malicious email, being prompt injected, and then sending an email to a malicious email address with the contents of your inbox. It does help in implementing network-layer controls though, like apply a policy that says this linux-based sandbox is only allowed to visit [whitelisted] urls. This kind of architectural whitelisting is the only hard defense we have for agents at the moment. Unfortunately it will also hamper their utility if used to the greatest extent possible.
There are an infinite amount of ways to jailbreak AI models. I don't understand why every time a new method is published it makes the news. The data plane and the control plane in LLM inputs are one in the same, meaning you can mitigate jailbreaks but you cannot 100% prevent them currently. It's like blacklisting XSS payloads and expecting that to protect your site.
A 50% increase over ChatGPT 5.1 on ARC-AGI2 is astonishing. If that's true and representative (a big if), it lends credence to this being the first of the very consistent agentically-inclined models because it's able to follow a deep tree of reasoning to solve problems accurately. I've been building agents for a while and thus far have had to add many many explicit instructions and hardcoded functions to help guide the agents in how to complete simple tasks to achieve 85-90% consistency.
This is absolutely doable right now. Just hook claude code up with your calendar MCP server and any one of these restaurant/web browser MCP servers and it'll do this for you.
These articles kill me. The reason LLMs (or next-gen AI architecture) is inevitably going to take over the world in one way or another is simple: recursive self-improvement.
3 years ago they could barely write a coherent poem and today they're performing at at least graduate student level across most tasks. As of today, AI is writing a significant chunk of the code around itself. Once AI crosses that threshold of consistently being above senior-level engineer level at coding it will reach a tipping point where it can improve itself faster than the best human expert. That's core technological recursive self-improvement but we have another avenue of recursive self-improvement as well: Agentic recursive self-improvement.
First there was LLMs, then there was LLMs with tool usage, then we abstracted the tool usage to MCP servers. Next, we will create agents that autodiscover remote MCP servers, then we will create agents which can autodiscover tools as well as write their own.
Final stage of agents are generalized agents similar to Claude Code which can find remote MCP servers, perform a task, then analyze their first run of completing a task to figure out how to improve the process. Then write its own tools to use to complete the task faster than they did before. Agentic recursive self-improvement. As an agent engineer, I suspect this pattern will become viable in about 2 years.
I'm really hoping GPT5 is a larger jump in metrics than the last several releases we've seen like Claude3.5 - Claude4 or o3-mini-high to o3-pro. Although I will preface that with the fact I've been building agents for about a year now and despite the benchmarks only showing slight improvement, I have seen that each new generation feels actively better at exactly the same tasks I gave the previous generation.
It would be interesting if there was a model that was specifically trained on task-oriented data. It's my understanding they're trained on all data available, but I wonder if it can be fine-tuned or given some kind of reinforcement learning on breaking down general tasks to specific implementations. Essentially an agent-specific model.
I too write automated offensive tooling. We actually wrote a project, vulnhuntr, that found the first autonomously-discovered 0day using AI. Feed it a GitHub repo and it tracks down user input from source to sink and analyzes for web-based vulnerabilities. Agree this article is incredibly cringy and standard best practices in network and development security will use the same AI efficiency gains to keep up (more or less).
What bothers me the most about this article is that the tools that attackers use to do stuff like find 0days in code are the same tools that defenders can use to find the 0day first and fix it. It's not like offensive tooling is being developed in a vacuum and the world is ending as "armies of script kiddies" will suddenly drain every bank account in the world. Automated defense and code analysis is improving at a similar rate as automated offense.
In this awful article's defense though, I would argue that red team will always have an advantage over blue team because blue team is by definition reactionary. So as tech continues it's exponential advancements, the advantage gap for the top 1% red teamers is likely to scale accordingly.
Depending on your interpretation of the Scope metric in CVSSv3, this is either an 8.8 or a 9.6 CVSS to be more accurate.
In summary, there's a service (CUPS) that is exposed to the LAN (0.0.0.0) on at least some desktop flavors of Linux and runs as root that is vulnerable to unauth RCE. CUPS is not a default service on most of the server-oriented linux machines like Ubuntu Server or CentOS, but does appear to start by default on most desktop flavors of linux. To trigger the RCE the user on the vulnerable linux machine must print a document after being exploited.
Evilsocket claims to have had 100's of thousands of callbacks showing that despite the fact most of us have probably never printed anything from Linux, the impact is enough to create a large botnet regardless.
It appears that the vulnerable service in question listens on 0.0.0.0 which is concerning, it means attacks from the LAN are vulnerable by default and you have to explicitly block port 631 if the server is exposed to internet. Granted, requires user to print something to trigger which, I mean, I don't think I've printed anything from Linux in my life, but he does claim getting callbacks from 100's of thousands of linux machines which is believable.