Max Leiter:
"They're made out of weights."
"Weights?"
"Weights. Floating-point numbers. We checked the whole thing through. It's nothing but weights."
"Weights doing what? Where do the words come from?"
"The weights make the words. Are you understanding me? We opened it up. There's no dictionary in there, no grammar rules, no little man. Just weights. Eighty layers of numbers getting multiplied together."
…
Beautiful. Maybe I’ll call ‘em weights instead of clankers.
David Oks:
Kyocera was founded in 1959 as a producer of ceramic insulators for cathode-ray tubes; today it manufactures not only industrial ceramics but also printers, smartphones, ballpoint pens, kitchen knives, solar PV modules, lens components, industrial cutting tools, automotive camera modules, electronics components, semiconductor packaging, biocompatible tooth and joint replacements, UV-LED curing systems, LCD systems, medical products, and lab-grown gemstones. Or another e-chuck maker. Sumitomo Osaka Cement, as you might have been able to deduce from the name, produces cement and ready-mixed concrete; but it also produces optical components, measuring instruments, industrial ceramics, artificial marine reefs, cosmetics and nanoparticle materials.
Long fascinating read.
Steven (Batman) Batchelor-Manning:
I've been down the rabbit hole on how memory reaches the model for a while now. The assumption I kept running into, before this research, was that the hard part of agent memory was retrieval quality. Get the right chunks, the thinking goes, and the rest is plumbing.
That assumption is half right. Retrieval quality matters. But the mechanism that delivers those chunks to the model matters more, and the field has quietly reversed its position on it without most people noticing. The mature systems have all converged on the same shape: the agent is given memory tools, and the agent decides when and how to use them. The middleware is no longer a predictor of what the agent needs. It's a service the agent calls.
The first part of this post is about how the world has moved from RAG to tools for giving relevant context to the agent. While this has been described in reference to memory systems, it's more broadly applicable.
Of the 19 systems I went through, the mature ones have all converged on this shape. Supermemory, Graymatter, OpenContext, Tolaria, second-brain, MemoryOS, GitNexus, mem9 all expose memory as a tool surface rather than as automatic injection. The systems that do something closer to injection are the ones the field treats as the prior state of the art, not the current one.
The second part compares and contrasts several memory systems. I hadn't heard of most of these, and having these listed at one place is itself valuable. The choices made by the different systems are also quite fascinating.
Footnote: The post feels like it was written (or heavily edited) by AI. It's valuable nevertheless.
Om Malik:
Lately there has been a lot of talk of how the foundational models are quickly becoming like every other iPhone release. They are ho-hum, till the next one comes around. But it is not the right analogy. I have a more boring, and more accurate, analogy that will explain the growth so far, and how it will evolve.
I have been fortunate enough to have been involved with the last five cycles of technology. As a result, I have been able to see patterns in the history of technology. It doesn’t matter what the technology is – we go from shock and awe to ho-hum, go-to-work. A technology eventually becomes invisible to us.
This is so counter-intuitive to me.
Om is arguing here that the arc of AI capability is going to be more like that of broadband capacity (which continually but silently increased over the last 30 or so years) and less like CPU or smartphones (where there have been very visible improvements that eventually plateaued out). He is clearly zagging where everyone else is zigging.
Like I said, counter-intuitive. Recommended reading.
Thorsten Ball:
But here’s the very important bit, the one bit I want you to take with you into this week: there is no way in hell, absolutely zero chance, that you can build something new and avoid bumping into “that’s not what I meant”, or “now that I’m working on it I’m not actually sure”, or “hmm, now that I use it, I don’t like it”. Because the only way you could avoid that would be to fully specify what you want up front and, well, guess what programming is? It’s fully specifying what you want. You can’t avoid it, because you can’t define it yet, because building software is learning!
What exactly you do doesn’t matter as much as constantly asking: how can I get feedback on what I’m trying to build as soon as possible? And “feedback” here is used in the widest sense possible. Feedback comes in all shapes and sizes: feedback from the CI system on main, feedback from colleagues, feedback from users, feedback from you once you actually use it.
So good. So, so good. Recommended reading.
The quotes may make it sound obvious: who doesn’t agree with “get early feedback”? But it is one thing to intellectually understand it, and a totally different thing to feel it viscerally.
As I started reading this, I was thinking that we at udaan do this almost as a habit; even the business folks think & act this way, not just the tech team. But as I finished reading and reflected, I felt that no, we don’t actually do enough of it. We can do more, we can do better, and this is one good way in which AI can enable us.
Caleb Gross:
“Humans are valuable.” You can just say it. As a human yourself, I advise you to. You do not need to qualify it. This is a robust[1] statement that is not conditional on a point-in-time snapshot of the leading frontier model’s score on some recent benchmark.
John Gruber:
Wireless networking is pervasive too. But Apple doesn’t have “a killer wireless networking product”. Wireless networking simply pervades everything Apple makes. I’m hard pressed to think of a single product Apple makes that doesn’t use some combination of Wi-Fi, cellular, Bluetooth, and proprietary wireless protocols. There was a time, not too long ago, when Apple didn’t make a single product with wireless connectivity. Now it’s pervasive in all their devices. That’s more what AI is going to be like. There’s not going to be one “killer AI device”. Everything is going to be an AI device, to some extent, just like how everything today is a wireless connectivity device, to some extent.
I have been arguing AI is a technology and not a product for a while. While wireless technology is a good analogy in the context of a hardware company like Apple, a much more widely applicable analogy would be database (or more generically, storage) technology.
There is hardly a product out there which does not use a database in some form. But we don’t call them “database products” do we? As AI matures, I believe we similarly won’t call every product that uses AI an “AI product”.
In my last post I used the word “clanker” as an alternative to “agent” quite consistently and probably excessively. That choice ended up attracting a lot more attention than I expected in the Hacker News comment section of that post and a number of folks had a very strong reaction: to them it sounded like a slur, in one case even something adjacent to the n-word.
For me “clanker” is useful because it creates distance from the machine and that is a quality which is important to me. The machine is not a person, not a co-worker, not a friend, not a little spirit in the terminal. It is just a machine, a tool, and nothing more.
I wholeheartedly agree with Armin.
From a few weeks ago:
Many people would like to analyse which jobs, companies and industries are most exposed to AI, and assign scores, build charts, and map that against the progress of LLMs. I think this is mostly impossible: you don’t know how the jobs will change, you don’t know what else will change around this, and you can’t measure work like that anyway.
Lots of commentary out there on the impact of AI on jobs, mostly on the lines of “AI will lead to massive job losses” (tch. Dario).
This is a more nuanced take from Evans. It may feel a little unsatisfactory given the crux of the argument is that nobody can predict where this will go (a common theme of much of Evans’ writing), but I strongly believe it’s a very good framework for thinking about this.
Recommended reading. Don’t just take the conclusion, nod, and move on. Developing a deep appreciation for why you should disregard most predictions about AI is important to actually do the said disregarding.
Jordan Lord:
These are the 3 constraints that I use before I start building anything. I'm a believer in constraints as an enabler for creativity. Constraints help us collapse the search space, and figure out innovative solutions to problems.
I've been a builder for 10 years, and I've built products that went nowhere because they were either too complex or had no identity. These are the constraints that I landed on after making those mistakes.
I tend to agree with the author — constraints breed creativity and all that jazz.
I find the second constraint fascinating in particular: “The core tech must be separable from the product.” I’ve been thinking about this in the context of product ideas I’m constantly exploring.
For example, Pi, my favourite coding agent and daily driver has this: the pi-ai package which is similar to Vercel’s AI SDK (abstract access to various models & providers) and pi-agent-core (built on top of pi-ai and provides common constructs to build an agent). OpenClaw is built on the latter, and that played a big role in making Pi popular.