The LangChain podcast where @hwchase17 interviews agent builders is full of alpha. Recent one with @EnoReyes was the best one yet. Sharing m…

The LangChain podcast where @hwchase17 interviews agent builders is full of alpha. Recent one with @EnoReyes was the best one yet. Sharing my unstructured notes: Eno keeps bringing back some core concepts: signals (events that trigger things), workflows (context, skills, and harness config) and missions (the task to achieve). Factory builds on top of these concepts. An example workflow could be code review and an example trigger could be a message in a Slack channel, or a PR being pushed. > The goal of a software factory is to build the workflows which go from signals to deployed code and add as much automation as possible. They discuss memory, a very over-loaded term. There are now many more terms: config, skills, files, wiki, context...? Strong consensus that memory is your moat (https://x.com/satyanadella/status/2076323181154230284), so you really want to keep access to it and own it as an enterprise. Key point of disagreement: Eno thinks wikis are for humans to stay in the understanding loop, while Harrison thinks wikis are for agents to gather context better. Maybe we need two names? Indeed both of these make sense but their shape and requirements will diverge (or will it?). They discuss verifiability. This keeps coming up everywhere in technique discussions for agent building. Once again Eno champions that being able to verifiably check a task with deterministic tests is the way to raise the ceiling and achieve long horizon tasks. This includes computer use, code coverage, unit testing, integration testing, evals, ... Factory's missions have a very specific set of verification tests. He says they spend a lot of time on these and make them quite exhaustive and specific, and that's a huge determinant in the success of the mission. Speaking of evals, Factory do a lot of them. They don't need to be large! Small "Regression tests" with an N of 10 still hold value (examples he gave were compaction or caching checks). What's interesting to me is that these sound like tests, and the word "eval" has outgrown its initial specific meaning. It used to be a very ML thing with F2 scores and given metrics and properties, and now it captures anything that has to do with testing around LLMs. A lot of human time is spent doing these (example of the guy writing more and more complex lint rules). Of course they discuss how product and engineering roles are evolving. Eno is in the camp that engineers are splitting in two: product eng and deep systems eng. I would argue this was already the case, great engineers typically are one or the other archetype. In enterprise, costs are starting to become an important conversation. This is bullish for two things: open models and model routers. There's this psychological trick where if you do a blind test on users on which model is best you get one distribution, but if you tell them what the models are a lot of preference flows towards the big models from the big labs. Marketing? Eno has a hot take of the platonic representation hypothesis: representations in AI models are converging independently of the architecture. In other words, intelligence is discovered and distillation unpreventable, since we end up in the same place and therefore we can borrow the destination (distill) to get there faster. Building a model-agnostic harness. Is this a disadvantage or an advantage? Actually not at all obvious as they showcase quite well. The massive advantage of owning the model is that you can RL your harness, but the disadvantages also exist: you can't mix and match models and leverage the competition, you have biases in your tool call mechanisms (example given is how to apply a diff) which might work slightly better in some areas than others. In the past, models were very prompt sensitive (adding "Don't stop until you're done" changed an OpenAI benchmark by over 30%...), nowadays the models are all getting much stronger which means less arcane word magic and therefore more transferability of prompts between the models. Eno has a fun analogy: preferences aren't optimal. So being left handed isn't better than right handed. You might do stuff much better with your left hand but your performance on the end task is nearly identical. Same thing with how a model would implement a thing (like using a CLI for searching or another, how to apply a diff, etc...). A tactical point Eno makes is that cache-breaking is often worth it, and he sees this as a harness problem, not a gateway problem. I suspect this is still an open question and we'll see more experimentation and data play out in the next 6 months (lots of talking about gateways recently). Media

Source: Harrison Chase (X) | 2026-07-27