Tagged: ai

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”.

Armin Ronacher:

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:

Benedict Evans:

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.

Arnav Gupta:

But the truth is that these layoffs, even if they they are not because AI is replacing you, and even if they are some form of AI-washing. These layoffs are still because of AI. And these layoffs will continue till we learn to use AI. Till we learn to convert AI-tokens into outcomes and not just input. Till we learn to re-align the speed of "alignment" with the new speed of coding. And till we figure out, beyond our 2 good and 8 stupid ideas, 10 more ideas that we can chase with our increased productivity.

This is a very refreshing take on the layoffs in large tech companies. It’s the best take I’ve read on this.

Aparna Dhinakaran:

Someone asked me at a hacker event last week: "Can anyone actually tell me what a harness really is?" It was said with real skepticism. The kind of skepticism that says we all use the word "Harness" in the industry, but nobody actually knows what it is.

Fair question. Let me try.

This is a good post and does the important job of defining a term that is getting used increasingly in the context of AI agents.

Perhaps a good addendum would be to define an agent as something that wraps the harness into an app that users interact with. Claude Code is a harness and a coding agent merged into one. Codex cli is a coding agent that builds on the codex-app-server harness. Cursor is also a harness + coding agent, but they are also experimenting with Claude Code as a harness!

T3Code is a coding agent that demonstrates this difference best: it does not ship with its own harness and can instead use Codex, Claude Code, or OpenCode as harnesses.

One exception I take with the linked post is that not every component that it describes as making up a harness is actually necessary in every harness.

As an obvious example, you could very well build an agent without subagents (if you do want subagents, it would have to come in at the harness level as subagents are exposed as tools to the LLM).

So what are the absolute minimal components in a harness? I think it's just the agentic loop. That includes assembling the system prompt, tool definitions, executing the tool calls & assembling the results, etc.

Context management and compaction is not required (it could live outside the harness). Skills are not required. We already talked about subagents. Built-in prepackaged skills should probably not be there in any harness. Lifecycle hooks are nice to have. Session persistence & recovery is optional. So is a permission & safety layer.

Dave Griffith:

So: where are we? The technology exists and is impressive. The infrastructure buildout is underway and massive. Workflows are being redesigned in early-adopter organizations, often via guesswork. We've got one (1) product area (software development agents) where we're past "early adopter" and moving onto mass-market. Legal frameworks are being written badly by people who have never used the technology, which is traditional. Business models are being discovered by trial and error, also traditional. Fortunes are being made and lost, another time-honored tradition.

The critics who say nothing has changed are measuring at the wrong resolution. The critics who say change should have been instantaneous have a broken model of how change works. The honest answer is: this is going extremely fast, it will often feel slow until suddenly it doesn't, and the people who have built understanding now will not be scrambling in three years.

Amen. Good, entertaining read.

I'm going to refer people to this when they say either that things will not change dramatically or when they say that the dramatic change has already happened (so much more to come).