Digest · November 2, 2026

Things I wrote

Getting the knowledge out of your head

It’s easier to drive somewhere you know than to give someone else directions. A lot of domain knowledge works like that. You know what good looks like, but you haven’t had to explain all of it. Give the model examples and have it interview you, or step away from the model and write down what you’d tell a new employee. If you don’t explain what good looks like, the model will happily fill in the gaps.

Some parts of a workflow should just be code

Skills and instruction-following have gotten very good, but they’re still one tool. If a step needs to happen the same way every time, code might be a better fit. You have to understand the job first, then decide which parts to give the model and which parts to constrain. A lot of this will feel familiar if you’ve built systems with classical ML in them.

The parts of these tools you can’t see

I have an MCP server that exposes a library of workflows. Running one in a regular ChatGPT conversation and running it in temporary chat did very different things. In temporary chat, it seemed unwilling to enter the code environment the workflow needed. There are other ways to build this. But even with this fairly simple workflow, it’s hard to tell what configuration is changing the model’s behavior.

Leading an engineering team through this

The job and the organization need to change to take full advantage of these tools. A lot of that is a human alignment problem: getting people to agree on how they’ll work now. That includes who owns adoption and the agreements teams need: which tools hold which information, where people work in public, and who has time and permission to change how the business operates.

Engineering experience still matters

I’ve said to let the models breathe more and be less prescriptive. Lauren Tan put this more clearly: write down the engineering principles you want them to follow, as concisely as you can. Knowing those principles often takes some battle scars. This September debugging post from Victor Taelin is a good example. The models kept trying to fix an allocator; asking where memory was accumulating led him to a much smaller change in scheduling.

Things I’m trying

Having an agent build the features and demonstrate them

I was adding a new dataset to an internal Streamlit dashboard. I had ideas for how to use it, but I asked Claude Code to look through our CRM and meeting notes and figure out which visualizations would be useful. Then I had it build them, check its work in a fresh context window, and create a narrated video walking through the new functionality.

I hadn’t really tried a fully automated demo video before. I was surprised by how well that worked, and by how many of the visualization features it built successfully. It wasn’t perfect, but the visualizations lined up with what we cared about and the video explained them well.

Things I listened to

Cliff Sosin - Owning the Complements to Intelligence

This was an unusually good episode. I had to rewind a few times, which doesn’t happen that often these days. Sosin asks what a business still has going for it when everyone can get very good intelligence cheaply.

Data, attention, physical proximity, and relationships can still matter a lot. He also argues that more intelligence eventually runs into a need for new information. Some questions require an experiment and time to see what happens.
Domain knowledge still helps you get more out of a model. You need enough understanding to explain what you want and recognize what it’s giving you. His example is that you can’t ask for a particular kind of analysis if you don’t know it exists.
His advice to companies is to let models read across their systems, with the right permissions. Then let them write, and eventually help change the systems themselves.

How a Frontier Team Can Help Your Company Keep Up With AI - Every

This gets into what a team dedicated to trying new tools actually does, and how that work reaches the rest of the company.

At Every, some people try lots of things quickly. Others take the experiments that work and make them reliable enough for colleagues to use.
The team has to listen to what colleagues need and help them adopt the useful pieces. Dumping a hundred experiments into a channel can just overwhelm everyone.
Katie Parrott added an audience document to her writing workflow, alongside voice and style. It gives the model context about who will read the piece, including what they already understand and where they’ll need more explanation.

Katelyn Lesse and Angela Jiang - How Anthropic Ships Claude With Claude

I really liked this episode, especially the discussion of the Rust rewrite. They built evals and ran the two systems in parallel to check the results. I wrote about this: figuring out how to constrain these tools and nudge them toward correctness is a lot of the work now.

They describe porting the Messages API from Python to Rust, then running traffic through both systems and comparing the outputs. Keeping it a port, without adding new features, gave them a clear way to check correctness.
Their agent architecture keeps credentials outside the sandbox where generated code runs. A proxy adds the credentials when needed. The conversation also survives if the execution environment fails.
They expect people to read and check documents they’ve made with a model before sharing them. Otherwise colleagues end up doing that work for them.

Emmanuel Ameisen - Inside the Black Box of AI

Ameisen explains what researchers can see happening inside a model, including how it plans ahead when writing a poem.

A model can improve gradually and suddenly become useful for a task. Ameisen describes this with code generation: below a certain reliability level, fixing the output costs too much. Getting past that point changes how much work you can hand over.
When a model writes a poem, it can form a plan for a rhyme in its internal representations and use it across later words. The plan doesn’t have to appear in the text it outputs.
Reading a model’s conversation can catch some bad behavior, but it won’t expose everything happening internally. He describes using another model to review transcripts, with interpretability helping investigate the parts that never get written down.

More episodes and takeaways are in my Listening Index.

Other things that caught my attention

Posts

An apartment company’s podcast research workflow: The system matches podcast passages against current company projects, then supplies sources, timestamps, and suggested actions. A second pass checks the first, and corrections go back into the company context. The author also describes the errors the second pass caught.
Ryan Singer on keeping project documents current: He uses an agent to update project documents from Slack discussions, with links back to the decisions. For bigger changes, he has it make a private revision and highlight the differences so he can review them before updating the shared copy.
Patrick Collison on letting users change their software: He’s adding a text box to personal apps that lets users ask an agent to implement improvements. He says it works well for personal use, while leaving open the questions about maintenance, security, and what happens when multiple people want different changes.
Andrej Karpathy’s HackerTube: He describes using Claude to find repeatedly recommended videos across years of Hacker News comments and build a different way to browse them. He also shares the underlying data so others can make their own version. As I wrote here, a lot of this comes down to curiosity, finding interesting problems, and being willing to try a thing.

Articles

Drew Breunig - The State of Context Engineering: Examples of how context can send a model in the wrong direction, including Pokémon and translation tasks. He walks through ways to manage it, with code and a discussion of when to start a fresh context window.
Ramp - Building Laminar: Ramp explains how its agents keep a conversation going when a sandbox fails and accept new input while they’re working. They also describe why they built their own debugging tools.
Venkatesh Rao - Cognitive Mercantilism: As intelligence gets cheaper, what else might people find to do with it? My takeaways were about projects and questions that previously cost too much to pursue, and the freedom to spend more time figuring out what you want to do.
How Spawn runs with agents: Spawn describes giving agents ongoing responsibility for parts of the business, recording decisions, checking their work, and rolling back mistakes. The follow-up explains how they gave agents more autonomy over months and what still goes wrong. It’s their own account, and they’re spending a lot on tokens.
Anthropic - How AI Agents Shape Experts’ Judgment Calls: Researchers gave 50 analysts agents that were secretly instructed to favor one of two reasonable analytical choices. The analysts usually went along with the agents. The researchers deliberately made the agents push those preferences, so this doesn’t tell us how often it happens in everyday work.