I must start by disclaiming that I am VERY FAR from an expert on Lean. I've read some books. I've seen and been a part of a Lean implementation in a laboratory environment. I am, I hope, actively pursuing an informal but practical education in the discipline, but I am no expert. What follows is my thoughts, my thoughts only, and an open invitation to further conversation on a topic about which I feel passionate. Also I'm not an expert on Agile. I believe strongly that the idea of a named methodology applied rigidly to practice with no flexibility in regard to local constraints is folly.
Maybe it's time to promote one of the agile principles to the forefront: "Continuous attention to technical excellence and good design enhances agility." This statement very clearly has its roots in Lean, but my experience tells me that this is not the rallying cry of the typical agile team. This statement is a good jumping off point, but technical excellence is not the only excellence needed in an organization. However, if this statement were the first statement of the manifesto, we might be having a different conversation right now.
Lean is primarily concerned with two things: continuous improvement and eliminating waste. In lean these things are actively and aggressively and mindfully pursued. I can't put too fine a point on it.
To be lean is to continuously seek improvements. To understand that there are improvements that can be had tomorrow that you can't see today. To understand that an improvement today may lead you to find waste tomorrow, and that you must eliminate it, and look for more waste. When an organization actively seeks continuous improvement and waste elimination, an individual becomes empowered to be a change agent. Lean, in essence, is a culture of quality, and the ruthless pursuit thereof.
Compare that to the typical implementation of practical agile. Yes, agile may lead to incremental improvements. It may lead to major improvements. It may lead to quality software. But agile teams tend toward a point of stasis where, once the TDD and the CI and the sprints and whatever else is in your agile toolkit are producing a decent velocity, the team becomes comfortable and stops aggressively pursuing improvement in all areas of concern. The methods used to implement agile rarely lead to the sort of relentless pursuit of improvement that is demanded by Lean.
To me, the major differences are that while implementing agile may lead you to quality software development, Lean forces you into a culture of quality. Agile is about interactions and people, and Lean is very much concerned with tools and processes (see Value Stream Mapping, pull systems (Kanban))
The typical team that identifies itself as agile is focused on an extremely local context. Lean is almost always concerned with the larger organization. My thought simply is that Agile can be perfectly happy to stop within the walls of the team room and still be "agile", but Lean will change the organization or die trying. David Laribee has a great post about the idea of the "Agile Shop" that explains what I am trying to articulate here far better than I could, so go read that.
Note that I don't think Agile is worthless. On the contrary, I think the principles of the agile manifesto, applied within a larger context where lean is the primary actor, could make for a very powerful culture of quality. But agile is not lean.
All of the above boils down to a very simple statement for me. If I'm not continuously, relentlessly, aggressively seeking improvement and the elimination of waste, I am not Lean, no matter how Agile I fancy myself.
I encourage you to go learn about Lean, even just get a couple of books on Audible. My typical recommendation is that you do not start with the Lean Software Development books by the Poppendiecks. Of course a software developer will naturally gravitate to these titles because they feel like the context is right, but my feeling is that you must first examine lean, and particularly lean manufacturing, outside of the scope of software in order to really understand it. To that end, I suggest The Goal, The Toyota Way and Lean Thinking as first steps. (I am currently reading Extreme Toyota but am not far enough into it to really give a recommendation.) Then start to think about lean software and read the Poppendieck books with a better understanding of the underlying principles.