DEV Community: Ryan Palo

A Third Brain for your Second Brain

Ryan Palo — Fri, 03 Jul 2026 15:02:56 +0000

The concept of the "second brain"/"knowledge base" is one of my absolute favorite nerd snipes of all time. As a writer and blogger, I love everything about the idea of attempting to hoard every single piece of knowledge I accumulate into a structured, tagged, and metadatafied text mound repository. The memory talks today at the AI Engineer World's Fair, along with some of the online track talks, led me to the realization that the human knowledge base and the AI concept of an AutoWiki are a match made in heaven.

Let's start from the beginning so we don't lose anybody: a knowledge base, or a "second brain" if you do it a certain way, is a collection of data in various states from raw, incoming knowledge to processed, synthesized, integrated learnings. Oftentimes these data bits are stored as plain Markdown files (here your AI antennae should be perking up). If you're extra cool, you use an app like Obsidian or Neovim to operate on these files. One popular method is to set up an incoming inbox where you can jot down new information or idea fragments in seconds so that you don't lose anything by thinking, "Oh cool, I'll make a note of that later." Then, when you get some time to process things, you go through your inbox, fill in blanks, do more research, and eventually, you end up with a more processed, more personalized piece of knowledge that is all linked up to lots of other pieces of processed knowledge in your knowledge base. You may also generate even more ideas or thoughts for the inbox during this process. Then, when you go to create or learn something, you already have all of these related, processed knowledge chunks to draw from. If this seems like a cult mindset that interests you, look up the word Zettelkasten.

You know what else processes and synthesizes Markdown files? That's right. AI. It's, like, the main thing it does. Do you know one of the hardest problems to solve in a manually-managed knowledge base? (The more librarian-minded amongst us might also argue that this is one of the most fun problems.) Finding and combining stuff. You have all these linked bits, but then you're forced to a) click through link after link until you're thoroughly lost, b) write up your own summary notes that you then link to the raw notes, growing your web, c) see if you can get lucky with tag or string searches, or d) cry.

One of the online talks, Turn 10,994 Notes into Memory, by Paul Iusztin and Luis-François Bouchard proposes one approach: give your agent access to your notes to answer questions for you. And to answer the question of that being way too much context to consume for each question, they propose giving your agent a little scratch area to set up its own memory wiki. It's possible you don't want it in your main knowledge base updating and editing files unattended. But that doesn't mean it can't have its own knowledge/memory base. And the extra neat thing they propose is a semantic index file so that the agent can know whether to look at its own docs, or dive back into your full knowledge base for more information. You would have to do some work and schedule some staleness/wiki refresh runs before deep AI work sessions, but there is a synergy to these two tools that I hadn't considered before and I will be experimenting with my own knowledge base.

Choosing the Right Tooling Layer for Your Agent

Ryan Palo — Fri, 03 Jul 2026 14:57:01 +0000

Selecting the right abstraction layer is not a new problem in software. It's common to have some experimental restructuring to find the right balance between being abstract enough to consolidate all the duplication that belongs together and going too far, making users jump through hoops to use your overly abstracted MiddlewareManagerAbstractFactoryProvider. There are entire books and undergraduate courses on exactly this problem: what level of abstraction is enough?

We now have a similar analog in the space of how we help our AI agents perform tasks. Do we need an MCP for that capability? A skill? Will a simple CLI tool work? The answer depends on a few questions.

Note: For more context, check out Nikita Kothari's AIE World's Fair talk from Thursday, "MCPs, CLIs, and Skills: Choosing the Right Tooling Layer for Agentic Development."

All the MCPs: The Super-Agent Approach

One option would be to load every possible MCP you might ever need access to at startup. This has the benefit of discoverability. If you're not sure what the agent might need to do and you want it to be as unattended as possible, giving access to all of those tool descriptions allows it to be flexible and combine sources and tools as needed. It also allows it to branch out and parallelize, gathering data from multiple sources at the same time.

There's a sneaky trap here, though: MCP server schemas may gobble up your context window. Nikita references example numbers where the MCP schemas for 55 tools from five MCP servers could take up about 16,500 tokens that live in your context constantly.

Skills and CLIs: The Developer's Approach

This is the full opposite end of the spectrum from the previous approach: make your agent aware of any skills that it needs and use those to instruct it on which CLI tools to use and how. Context- and speed-wise, CLI tools have a huge advantage over MCP tools. There's no extra network call to the MCP server, they eat next to no context, and the output of a CLI tool is reasonably predictable. Additionally, if the agent is running locally, you get the benefit of being familiar with its environment and being able to step in and help it along if things get stuck.

The drawback here is security. CLI tools are one of the highest-risk tools for an agent to use because, by definition, if it can access a CLI tool, it can access the shell itself. It's not an unmanageable risk; with careful sandboxing and attention to permissions, the risk can be managed. You also have to be cognizant of what sort of credential issues you may be signing on for. You need to be aware of what credential files the agent has access to, and whether the roles for those credentials are appropriate for its actions.

Why Not Both: The Hybrid Approach

If you have enough MCP servers and tools that it's eating enough of your context to be problematic, you can combine both of the above: bundle your MCP tool usage into skills to avoid the token bloat. Modern clients don't necessarily bundle the entire schema into the context if it's large enough. They do a mixture of caching and compaction/indexing so that they inject just the bare minimum and then load the actual tool schema as needed. If you wrap your process in a skill that describes exactly what tools it needs and how to use them, your client can unpack just the schemas for those tools more fully, saving you context and a bit of load time. This is often the best choice if it warrants the little bit of extra configuration work.

It Depends

So which one should you stick to as the right choice? We started with a storied computer science question, and we're ending with a storied computer science answer: it depends. It depends on what the environment is, what kind of tasks you're trying to accomplish, whether there are CLI tools for the functionality you need, and what your organizational auth/governance requirements are. MCPs are definitely more secure and more governable. CLIs are definitely faster and more reliable. The answer probably lies somewhere in the middle for your use case. The main takeaway here may actually be that the ability to write and maintain really good Skills is a huge advantage.

If you want to do more research into this topic, the Firecrawl blog has a much more comprehensive deep dive into the differences, benefits, and drawbacks of each approach.

The Conspiracy Big Software Engineering Doesn't Want You to Know

Ryan Palo — Fri, 03 Jul 2026 14:38:37 +0000

Buckle up, gang — it's conspiracy theory time.

I've had this theory percolating in the back of my head for a while now. It was seeded as I started learning more about agents and skills, and throughout this whole conference, it has grown to be fully formed. Let me walk you through it in a bit of a scenario:

One of the quickest and most approachable ways to start customizing how you work with AI is learning how to write Skills. When you're writing your skills, it's critical that you explain when it should be used in very concrete terms. It's also important that the skill itself is clear, concise, and accurate, showing step-by-step how to do the process that it is describing. It should contain links to relevant context, and it should be updated semiregularly as processes change.

"But wait," you say, a little confusedly. "Isn't that just good process documentation? Like, aren't we already supposed to be doing that to help our teammates, new hires, and interns?"

"Ha ha ha!" I laugh agentically. "No, no, no, my sweet, little spring plum. We don't need software engineering anymore — that's what the agents are for."

A few weeks after this conversation, somebody at work cites an article shared at the AI Engineer World's Fair. It reported research that there are a multitude of benefits to agent performance if your codebase is well structured and well architected. If you have a practical, descriptive test suite, up-to-date documentation, a clear dev environment setup, production metrics and observability, and a functional CI/CD pipeline, agents generate correct code more often. They create security vulnerabilities less often. They waste less money, and they can be trusted to not break everything as often.

I see your eyes narrow suspiciously. You say, "OK, hang on a darn minute here. Those are definitely just good software engineering practices."

"Ohoho," I chortle into my AI-rtisanal, vibe-crafted, probiotic high-protein custom kombucha blend. "Absolutely not! Look at the date of the study. April of 2026! This is some high-octane, bleeding-edge research you're looking at here, not some decrepit industry standard." I levitate away as you stand there looking frustrated.

The very next day, I'm wheeling my Onewheel through our open-plan office blasting a podcast from a shoulder boombox, and you catch the AI podcast host talking about "in this new era of AI development, the real winners are using prompt caching and routing to manage cost. If you're not working to get the most out of every dollar you spend on AI, you're already behind."

"THAT'S. IT!" We all turn to see you standing on top of your adjustable sit-stand desk (currently in stand mode for extra elevation). "THE NEW HOT THING IS TO TRY TO OPTIMIZE COSTS AND CACHE YOUR API CALLS IN EFFICIENT WAYS?!?" The top of your head catches fire. You don't seem to notice. You look around wildly at the ceiling and walls. "I SEE YOUR GAME! I KNOW YOUR TRICKS! YOU CAN'T HIDE FROM ME!!!" An intern wheels your desk with you on it out into the hall and asks Claude to "hire another staff engineer. Make no mistakes." Another engineer walks through the door moments later, and your People Ops team gives each other high-fives. The head of People Ops updates a metric with a sigh: "Lost another one to the Conspiracy."

And scene.

There's a secret cabal of veteran software engineers pulling the strings behind the curtain to trick us into doing good software practices by telling us they're cool, new AI skills that we need to adopt or get left behind. I'll take no further questions at this point. Thank you.

(Content note: This is a tongue-in-cheek way of poking fun at the hype-ier parts of the industry, but I'm legitimately really excited about how much of this conference was focused on buckling down and using our new shiny tools with a good, solid, grounded engineering base beneath it.)

Without Structure

Ryan Palo — Thu, 02 Jul 2026 15:18:45 +0000

“Without structure, AI makes code worse.” - Tereza Tížková

AI is a supercharger, not a magic wand. It doesn't magically fix all your problems and make your code better. It just amplifies what's already there. If your codebase is an unstructured, sloppy, brittle mess, adding agents will just help make more of that. Additionally, and hopefully unsurprisingly, how you implement AI coding practices on your teams affects the outcome powerfully. Much like an actual supercharger, it works much better if you incorporate AI coding practices in a structured, measured, and deliberate way, versus just bolting it on and firing up the engine.

Luckily, there's a rubric for ensuring your codebase is agent-ready. Here are the pillars the Factory team enumerated as indicators of a well-structured codebase: style and validation, a build system, testing, documentation, a dev environment, observability, security, and task discovery. If you're feeling comfortable with how your codebase scores in all these areas, then it might be ready for some agents to work within it.

Luckily, this is a net win no matter what: As it turns out, all of those things on that agent-readiness list are also the things that make for a really solid, maintainable, scalable, and stable software product for humans to work on, too. Making improvements in these areas ends up being zero-cost versus if you weren't planning on adopting some agents. This has been a theme so far at the World's Fair: It seems like we're working our way out of the initial hype cycle. It's no longer good enough to burn tokens and ship the product as fast as possible. We're engineers. We're learning to use these tools like we've learned to use all of our other tools: to build good things well.

Check out Tereza's talk on the AI Engineer World's Fair 2026 livestream for much more detail and references.

Beyond Context

Ryan Palo — Thu, 02 Jul 2026 14:02:11 +0000

The models are getting better. As you may have seen on multiple graphs presented here at the World's Fair, that 50% success-rate task duration horizon is growing longer and longer. As the horizons get longer, context management is getting more critical, and the relatively new and highly active topic of memory management is even more important still.

When I talk about memory, I'm not talking about computer memory (RAM). That's not exciting or novel (currently, it's mostly depressing). I'm talking about your agent's memories, or, how an agent keeps track of what it has done, what it knows, and what it needs to do. I'm sorry for the confusion: naming software things is hard. That being said, for the rest of this article, you should read the word "memory" as "facts that the agent definitely knows."

This is a very exciting research space that's evolving rapidly. In this article, we'll go over a collection of 30 different memory management paradigms, tools, and concepts and when you might want to reach for them. Throughout this, I'll be pulling from a very cool repository:

NirDiamant / Agent_Memory_Techniques

Agent memory for LLMs: 30 runnable Jupyter notebooks covering conversation buffers, vector stores, knowledge graphs, episodic and semantic memory, MemGPT, Mem0, Letta, Zep, Graphiti, LoCoMo benchmarks, and production patterns.

🧠 Agent Memory Techniques

Learn every agent memory technique for LLM agents.

⭐ If you find this useful, please star the repo so more learners can discover it.

🧭 New here? Start with 01 Conversation Buffer Memory or pick a Learning Path. Prefer a visual? See the Decision Tree below. 30 runnable Jupyter notebooks covering conversation buffers, vector stores, knowledge graphs, episodic and semantic memory, working memory, MemGPT, Mem0, Letta, Zep, Graphiti, LoCoMo benchmarks, and production memory patterns.

📖 Go deeper on RAG

RAG Made Simple - the 400-page visual guide to RAG, by the author of this repo Amazon Bestseller in Generative AI · 1,500+ readers · ⭐ 4.6

Get it - 33% off with code RAGKING → · Read Chapter 1 free

📫 Stay Updated

🚀
Weekly
Updates

💡
Expert
Insights

🎯
Top 0.1%
Content

Join over 50,000 readers getting clear AI tutorials every week. Subscribers also…

View on GitHub

I recommend reading through yourself to do a deeper dive. These memory management tools are broken into six categories based on the type of issues they solve, and we'll go over those six categories below.

Short-Term

These short-term solutions are methods for "[k]eep[ing] recent turns in memory without filling up the context window."

The first one becomes the foundation for all the others to improve upon. When using Conversation Buffer memory, you save the entire chat history verbatim and send the full entirety on every LLM call. It's clear to see that this becomes untenable fairly quickly, context-wise, but it is the smallest and requires the least setup. The main concerns to keep track of here are who said what and how many tokens you're using.

Sliding Window memory is the same in effect, but you only keep the last N messages in memory to avoid context overrun. You can be sure you're not going to run into context limits, but your model will have a strict "long-term memory-loss" issue. It won't remember anything that happened a fixed number of tokens ago.

Summary memory replaces the raw running conversation history with a running LLM-generated summary of the previous history. This also keeps you from overrunning context, and it keeps at least a modicum of long-term history around, as long as that information is important enough to make it into the summary. This has a hidden side benefit of dropping out things our summarizer considers irrelevant, keeping hopefully the most important things in context. The other hidden downside is the secondary LLM call to summarize the context for every turn.

Summary Buffer strikes a balance between the previous two techniques and gets the closest to the basic functionality of current coding tools: keep the most recent N messages in memory verbatim, but summarize the older messages instead of directly forgetting about them. This balance comes at the cost of needing its own tuning. You can see we're starting to get more into "systems" of memory requiring configuration and places to stash data. You have to tune your verbatim buffer size vs. your summary refresh rate vs. your token budget, compacting only when it is cost-effective to do so.

The final technique for this section is Token Buffer. The mechanics are similar to the Summary Buffer, but you need access to your model's tokenizer so that you can keep manual track of exact tokens in the conversation history. The upside is that it accounts for individual messages that are longer and require more tokens, keeping tighter control over token cost at the sacrifice of some amount of extra context.

Long-Term

Long-term solutions solve the problem of "[s]aving knowledge across sessions, users, and time." This problem comes into play when you start to think more "agentically" about running an agent to do a task and then disposing of it while still persisting anything it learned along the way. These are six different ways to store memories.

We'll start with the first real "big kid" memory type: Vector Store. Each turn of the conversation gets embedded into a vector database and can be retrieved based on similarity with past exchanges. This requires (you guessed it) a vector database and an embedding model to generate these embeddings. One benefit here is that it interleaves nicely in systems where you already need embeddings and a vector DB for RAG-style generation.

While vector stores can get you semantic similarity, if you want to give your agent real memory about "things," or, more specifically "entities," you'll want to use Entity Memory. It involves using Named Entity Recognition (NER) through LLM prompts or NER models to identify people, places, items, concepts, and more, and then saving those into a durable place. It can keep this as a continuously evolving, living store, and inject relevant entity records into the context as needed. This is especially great for research and other places where remembering definitions and context about specifically loaded terms is important. That being said, similar terms with different meanings (like our "memory" confusion in the intro!) can give this method trouble.

Entity memory stores facts about concrete things, but not their relationships. Knowledge Graph Memory is the solution that solves that problem. This extends the NER mentioned above and specifically asks a model to extract relationships as "subject-predicate-object" triples, e.g., shark - eats - fish, and fish - live in - ocean. This would allow you to ask a more complex question like "where can I find the things sharks eat?" and follow the graph to get much more targeted context. The downside here is that the process of generating these relationships is token-heavy and tokenizing graphs or subgraphs is also token-heavy. Maintaining an accurate and not-noisy graph is also a challenge. This approach usually makes the most sense for applications that involve complex relationship webs at their core.

Episodic Memory captures separate conversation sessions as discrete episodes indexed by time and topic. This is great for maintaining information where when the conversation took place is just as important as what the conversation was about: coaching agents, meeting-based agents, and the like.

By contrast, Semantic Memory is the opposite: after every turn, an LLM prompt scans for statements that express persistent facts and keeps a store of those. These facts must be embedded to check for similarity and/or contradiction. These are the memories where a user might say, "Well, I told the agent that; it ought to remember it." There are two difficulties here. First, the LLM has a hard time differentiating between fact and strongly stated opinion by default, so it may track opinions as facts in a way that needs to be reviewed. Second, a mechanism for decay over time can sometimes be needed to invalidate old facts as they age unless they are reinforced every so often.

Surprisingly, Procedural Memory is probably the kind you have the most experience with if you've been working with AI for any period of time. It's skills! Procedural memory is a durable recollection of detailed step-by-step workflows that allow an agent to follow a procedure rather than reason it through from start to finish. These often need to be curated by the user, in conjunction with the agent, but they can be extremely powerful.

Cognitive Architectures

Cognitive architectures provide a way for your agent to decide on its own what context is meaningful to the task at hand. We're going to breeze through these a little faster because there are eight of them, but definitely reference the GitHub repo mentioned to dive deeper. The main goal of the techniques in this section is deciding what to keep in working context memory, what to get rid of, and what to do with the memories it's getting rid of.

Working Memory & Context Window is the base option: let the agent decide which memories and facts are relevant and occasionally dump the least relevant memories when storage pressure gets too high. Hierarchical Memory builds on that by adding a multiple stages of "cold storage" where memories get demoted when their importance is deemed less important, and facts that are most important or accessed the most frequently are pulled toward the top layers.

Memory Consolidation is the process of consolidating memories that are similar enough into one stored entity to reduce space requirements, and Memory Compaction is taking enough of these similar or related entities and converting them to a single smaller entity by summarization.

Self-Reflecting Memory is when the agent generates memories by reflecting on the success or failure of past actions in order to improve performance on future tasks: "I tried running X command and it only worked when I added the --please-work flag."

Memory Routing is when you have multiple different types of memory stores based on what kind of memory it is and you need to search or update amongst them. Maybe you have an entity store for definitions as well as an episodic store for various user sessions.

Temporal Memory is the idea that more recent memories are likely more important, and Forgetting and Decay is the flip side of that coin, that memories should age and eventually be forgotten if they're not used or referenced.

Retrieval & Routing

In the vein of having multiple ways of storing memories and needing to figure out what to recall, from where, and when, these are four concepts that dive deeper:

Cross-Session and Multi-Agent memory are reasonably straightforward: persisting memories to share with an agent's future self or with other agents. Memory with Tools is a neat idea of giving the agent a tool to perform CRUD operations on its own memories, using it just like any other tool it has. The term here with the most weight (LLM pun mediumly intended) is Memory Retrieval Patterns.

With all of the other techniques from the previous section for weighting, classifying, grouping, and prioritizing memories, memory retrieval patterns are really all about how the most relevant and important memories are retrieved, and it involves a synthesis of multiple storage modes and techniques. Semantic and keyword searches are run, all of the mixed results are ranked together and then top candidates are scored again more precisely, and then the final selected results, optimized for diversity, are finally injected into the context window. It's important to keep in mind that each layer of storing, retrieving, ranking, encoding, and processing adds a little latency to each turn, and that overall accuracy should be balanced versus overall latency.

Frameworks

These four tools are all production-ready memory libraries to help you avoid rebuilding the memory wheel. Again, for content-length, and because the previous sections already covered the main fundamentals, we'll just list these as references.

Graphiti: A Neo4j-backed temporal memory and knowledge graph with automatic entity and relationship extraction
Mem0: A REST API and Python SDK for keeping track of user-scoped memories
Letta (formerly MemGPT): A Hierarchical (see, you know what that means now!) memory store with three tiers: Core memory, Archival (searchable) memory, and Recall (full conversation) memory
- If you check out the repo, there's an iPython notebook where you can follow along building your own MemGPT-style memory loop from scratch!
Zep: A managed memory service that handles all of the classifiers, entity extraction, and relationship graphing (powered by Graphiti, if you'll believe it) for you.

Evaluation & Production

These last three concepts are ones that you will need to keep in mind as you head to production at a larger scale: Evaluation is the idea of intermittently measuring the quality of your agent's memory system using metrics like precision, recall, staleness detection, and LLM-as-a-Judge scoring. Benchmarks are the idea of evaluating your system against stable, standardized datasets to measure against a published baseline. The last item in our list, Production Memory Patterns is another catch-all for concepts and topics needed to fully productionize a memory system at scale: TTL, sharding, compliance, and observability. Check out the repo to dive deeper.

Memory is Data

The important thing to remember is that agent memory is, at its core, just data. Depending on what your application needs, you'll need to decide which pieces of memory metadata are important to you, how to quantify the things that need to be quantified, how to store the things that need to be stored, how to look them up again later, and how to do that reliably at whatever scale you need. Unlocking the separation between "what does my agent know" and "what does my agent need to know right now" is the key to helping our agents keep up with this ever-expanding capability horizon.

Optimizing for Agents with llms.txt

Ryan Palo — Wed, 01 Jul 2026 14:14:25 +0000

If you’ve spent any time poking around the AIE World’s Fair 2026 website, you may have come across the llms.md page. If you’ve clicked the link, you may have an idea of the page’s purpose already. There is a distinct shift from energetic copy text, neat layouts, and advanced styling to focused, accurate details and well-labeled links. This whole page, while being a good resource for you, is not designed for you. It’s designed for AI.

It follows a standard proposal called the “/llms.txt file,” which you can read about at llmstxt.org. In fact, even though the AIEWF 2026 site has its page at llms.md, if you visit llms.txt instead, it handles it smoothly, redirecting to the llms.md page. The idea is that, rather than filling up an AI’s context window with footers, navs, sidebars, and styles, it is a focused and simple entry point for AIs visiting a site. The entry llms.txt (or .md) contains the minimum necessary information to use the site as well as clear links pointing to where the AI can get more information specifically about the topics it needs. A common choice is to link to “/llms-full.txt,” which has much more detail (which the AIEWF 2026 site does). Another recommendation from the standard itself is to make all content pages mirror a simple text version with an appended “.md” suffix for the same reasons (e.g., “posts.html” becomes “posts.html.md”).

The recommended layout looks something like this: one H1 header with the overall site/project title, a blockquote with a short summary of the most important information, zero or more markdown blocks with more details, followed by zero or more markdown sections with H2 headers containing lists of URLs pointing to further detail.

To be clear, these minimal, AI-first text files are simply a proposal, not a standard, and there is mixed adoption. Most chat-based tools have not committed to looking for llms.txt by default. Some people claim that they are “a solution in search of a problem.” This is reasonable, as the primary selling point is reduction of context clutter, and context efficiency is currently a popular research topic. (Look at how many talks at AIE 2026 are about context!) However, these files are relatively painless to autogenerate — although most aren’t quite as pretty as ai.engineer’s — and coding tools like Cursor and others actually do claim to reference them, especially when looking up library documentation. Their use does seem to be trending upward. Google even announced it as a new Lighthouse signal under the new Agentic Browsing category in May of this year, and it seems likely more tooling and standardization are coming in this area.

Every source on the subject, however, seems to agree on one thing that is the most important: llms.txt files are not replacements for current standards like robots.txt or sitemap.xml files. They are best when used together. A quick conversation with Gemini revealed that it was able to make use of the AIEWF 2026 llms.md file because it was already indexed by Google and showed up specifically in the search results. So, actions like listing it in your sitemap, ensuring crawlers can see it, and linking to it from landing pages will go a long way toward helping the AIs that use your site.

Token Town

Ryan Palo — Wed, 01 Jul 2026 13:44:58 +0000

Many of the sessions from Tuesday, especially on the main stage, revolved around the idea of software factories. Coordinating agents with other agents that check even more agents' work, with humans in an overseer position. Currently, many organizations’ systems are not quite factory-ready, with agents doing work but only as directed and subsequently verified by humans. A critical part of the software factory paradigm is its ability to provide trust by being able to review itself. Those larger orchestration and evaluation tasks may need to use more powerful models in order to provide autonomous output while building the necessary trust with the humans in and above the loop. But do all of the agents in the factory have the same requirements?

Sarah Sachs from Notion gave an incredible talk about just that, and if you missed it, make a note to go watch the recording. The main stage was livestreamed; you could watch it right now. Her main point was this: Most of us don't work for a frontier AI lab. A large fraction of the things we do, both in our own work and in our products, don't require the biggest, hottest, most token-hungry models. If we lock ourselves into one AI vendor or one hard-coded AI model, we're doing ourselves, our shareholders, and our customers a disservice.

At this point, even the models that aren't bleeding edge from any vendor are pretty decent and good enough to do simple to medium tasks like summarization. Using Opus to summarize a Slack thread is a bad choice. You likely don't need any model to convert a file from one type to another. As AI is getting better, it's also getting more expensive. Price is only going up, as are other social and environmental costs, and "simply throwing more tokens at it" is not a viable move for most companies.

Sarah's advice was to build smartly and modularly enough to avoid vendor and model lock-in. Switch models and vendors on a dime when the billing shifts to make the right choice for your customers. Try out open-weight models, especially for those midrange tasks where "good enough" is good enough. Balance the needs of all the different agents in your “factory,” make the "tokenomics" work for you, and it will help keep the costs a little more balanced for everybody else, too.

The Agentic, Ironclad Onion

Ryan Palo — Wed, 01 Jul 2026 13:20:55 +0000

As AI agents work under increasingly less human supervision, the need for a trustworthy, secure work platform and configuration for them is critical to avoiding ever-evolving security threats. The basics revolve around one tenet: Deny all permissions by default, giving it only the permissions it needs, on every level of the system possible. The best security is defense in layered depth, with each layer being as hardened as possible.

The purpose of this article is not to give you a bulletproof step-by-step hardening plan after which you will have an Unhackable Agent™️. The goal is for this to be an agentic security starting point, to give you an idea of what to consider, what mindsets are helpful, and spark an interest in all of the extremely bright security-based presentations happening at AI Engineer World's Fair 2026 where you can learn more. If there's any you missed on Tuesday, don't forget to have your agent remind you to check them out after they get uploaded on YouTube.

Here's where we start:

The Agent is an Adversary

This is the mindset you should work from. It's not because the agent is inherently malicious by design (put your tinfoil hat away for now). But, even with the best input filtering and defensive system prompting, there's always the chance that someone will find a way to inject a clever jailbreak into the context of your agent. Much like Dr. Jekyll and Mr. Hyde, your helpful, productive agent is one serum injection attack away from behaving like an attacker instead. As always, hoping that it won't happen doesn't count as a strategy.

Kernel-Based Protections

We'll start at the base: sandboxing the OS runtime. This is important: Containers aren't a sandbox. It's simply not enough to throw your agent into a container and declare victory. Containers provide process isolation and were designed for deployment consistency, not for containing an adversary that is trying to get out. So, a much safer starting point is using a dedicated VM or microVM where only the bare minimum of system calls are safe-listed, and filesystem access can be controlled at the kernel level based on process, not user permissions. Your agent doesn't need to be mounting disks or reconfiguring networks (probably). So let's block that at the kernel level.

Network-Based Protections

Eventually, to be maximally productive, your agent will likely need to reach out to the internet, or, at least, an internal network. A network layer of security is the required next step, and, luckily, this layer is more familiar. Web developers have been developing with the mindset that the internet is effectively a radioactive, zombie-infested, toxic wasteland that sometimes benign users come through for a few decades now. By default, all network access should be denied, and specific domains, requests, and patterns should be allowed on an as-needed and controlled basis. Always keep in mind that a prompt injection could live in any text the agent consumes including the text found on the web pages as it looks up information, so make sure you trust all of the safe-listed sources.

Policy-Based Protections

There may be additional safety and business rules you want to enforce that are on top of both of these lower layers. These may be things like API or tool quotas to avoid cost overruns or DDoS-ing your API. Your agent may be able to make network requests, and it may have permission to send POST requests to your API, but it probably shouldn't be able to send unlimited requests by default. As always, the best default is to deny. Only allow agents to make these calls or use these tools if they've been configured according to the policy you've decided you're comfortable with. While these policy-based checks can add a few milliseconds of latency to your agent, they allow more compound control over its higher-level actions.

Auth-Based Protections

It's a beautiful thing how short-lived the hype cycle for "It's just OpenClaw, bro, give it all the same permissions you have and let it rip" was. An agent should not have all of the authorization you have, and it shouldn't be able to authenticate as you. If you have a personal agent that summarizes your emails and responds to bug reports, it doesn't need your bank account credentials or your AWS token. Treat it like its own entity, and not like you would treat another human on your team. Treat it like a sleeper agent that could activate and become evil at any given moment. Give it its own accounts and tokens, and, again, scope those accounts and tokens to the bare minimum it needs to perform its functions. Most OS sandbox solutions take this down to the OS level and give the agent in the sandbox its own user account as an added layer of security.

Ephemeral Runtimes

At a certain point, the security-grounded mindset is one that thinks, "You know, it's eventually a certainty that this agent will get prompt-injected or otherwise download something malicious from the internet." It doesn't even have to be your agent's fault. A package on npm could get hacked (pause for shocked silence). An email attachment could have something malicious tucked away in an image.

Runtimes should be as ephemeral as possible. It should be easy, and possibly even routine, to fully throw away your agent in its runtime and spin a fresh one up.

If something bad does happen, being able to nuke it into oblivion (or package it up in deep freeze for security analysis) is a pretty good mitigation strategy starting point. Ideally, you would spin up the environment, have the agent do its task, save out any artifacts, and then destroy the environment once it's done.

Monitoring

The sibling of "hope is not a strategy" is "not knowing isn't an excuse." At every stage of operation, all of your agent's actions, decisions, sources, and artifacts should be logged, measured, and, as a callback to the Policy section, possibly have limits enforced on them. If your agent uses the curl tool every 30 seconds, or runs a bash command 90,000 times today, that's something you should know about. If its token, CPU, or memory usage spikes outside of normal ranges, that's a problem. Hopefully, your OS and Policy protections should save you from those issues, but you absolutely want to know if something doesn't behave as expected, in the same way you would keep logs and metrics on any other piece of security-critical, high-access software. Metrics, logs, and artifacts are excellent tools to have available to you for preventive defense as well as disaster recovery and root cause analysis.

Paranoia as a Service

In all honesty, the most successful security mindset to adopt is one of slight (nondebilitating) paranoia: At any given time, what's the worst possible thing the agent could do or compromise if an adversary successfully gained control of it? It's our job as builders and users of these new and growing technologies to hope for the best but prepare for the worst, the same way we always have.

Does Your Site Need a /ai Page?

Ryan Palo — Thu, 23 Oct 2025 08:24:03 +0000

After seeing an example on cassidoo's site, I decided to add an "AI Transparency" page to my site as well.

Both she and the post she links make a really good point about how, if a person or company is transparent about how they use AI, it helps us trust that their work is more authentic in general. They recommend adding a page to your site (e.g. /ai) that details how you make use of generative AI (or not). From the simplest "No posts on this site are written with generative AI," to a longer, more detailed breakdown, the idea is not to cover your bases with legalese, but to be authentic, clear, and real. It's not a bad thing to use AI, necessarily. It's a tool like any other, and a user needs to understand how it works--pro's, con's, strengths, and dangers. But it's good to be open about it to help people understand and gain context for your work.

And if you do decide to add one to your site, you can add your site to this public database of /ai page-having sites!

Sentient Config is a Code Smell

Ryan Palo — Sat, 11 Oct 2025 20:34:57 +0000

Stop me when this starts to feel familiar:

You build a really cool app that does a thing.
You have another use-case for the app, but maybe for a slightly different setup. So you add some configuration variables, maybe via environment variables or CLI args.
This works well, and you start to dream bigger. More use cases spring to mind that are effectively the same app, but with more tweaks. More configuration variables are needed. You evolve to config files.
Config files allow you to go bigger. More workloads, all running on the same base code! But suddenly, your base code doesn't quite do the thing you need it to. Suddenly your config values, no matter how nested and complex, can't get you to where you need to be. That's when the whispers start.

"These config files let me inject functionality into code. Code is functionality. In fact, why couldn't I just inject a little code from a config file. Then I wouldn't even need to make a pull request."

It is at this precise moment that you need to SNAP OUT OF IT. Much like Frodo with the One Ring, I'm being your Samwise Gamgee right now. Stop. It.

Look at where you are. You were just giddy about being able to "inject" code into your app without "having" to go through the "pain" of making a pull request. Do you see what the config file whispers have done to you?

Beware the Sentient Config

I hope that you've only experienced the brief wondering if hardcoding Python in YAML strings is really that bad. I hope you haven't gone down the road that some go: the road to mini-programming-languages-as-config.

If your config starts to become semi-executable, or--heaven forbid--Turing-complete, you may want to take another look at your architecture and see if there aren't some quality-of-life improvements to be made. Here's an example similar to some sentient config in a legacy app I worked on:

{
  "title": [
    ["regex", "(\w+\n===================)"],
    ["split"],
    ["strip"],
    ["replace", "&amp;", "&"]
  ]
}

(sobs in JSON)

Because, while the above isn't terrible, 1. it's possibly not under source control, and 2. it would be 5% more readable in actual code, and 3. it's an active gateway even more Turing. How long does this go on before you start to really crave an if expression, or--OK, maybe not that, but perhaps just a few boolean ands and ors? Or, perhaps, map, reduce, filter, and a first?

If a situation feels like it would be improved by allowing some custom code, the right solution is probably some custom code, done properly, and not more config.

Consider a Different Mindset

At times like these, it's important to ask ourselves: "What are we doing here? What's our goal?"

At least in our case, one issue we had been seeing is that our "custom code modules" were all bundled together in a package which the main app installed as a dependency, so anytime we wanted to tweak one specific custom module, we'd have to make that PR and deploy that new version, bump it in the main app, and bump that app's deployments, only to find out that we had a small bug and another round of PR's followed. This was understandably frustrating. So the workaround was more sentient config that we could configure live, on the fly, with fewer hoops to jump through.

But, as we took a step back to reflect (right around the time we started drafting proposals for if statement syntax), we realized that we could do with an inversion:

Our "main app" became our "base library." Our "custom modules" became individual "main" modules that extended, expanded, and customized our new base library. And we gained the following benefits:

We dropped one or two bump-and-redeploy cycles per code change.
We were able to really hone and polish our new "base library" because it wasn't yet overcomplicated by so many config variables.
Our base library stopped changing so frequently to accommodate new edge cases.
The previous two points allowed us to dramatically and confidently increase our test coverage of the base library, knowing we wouldn't have to rewrite the tests in a month.
Debugging, fixes, and new apps/module development saw huge speedups, because now our engineers weren't trying to figure out where the bug was in our awful, lightly documented, poorly tooled quasi-Lisp, they could quickly debug in Python code with Python tools like the grown, strong, independent software engineers we hired them to be.
Onboarding got faster because new hires already knew Python and didn't have to learn a new "language" (with those quotes doing lots of deeply malice-filled work here).

Inherit with Caution

I want you to hear me very clearly here. I am not advocating for you to go forth and design up 52 layers of BaseMiddleGenericAbstractMixin classes to override. Some inheritance may make sense. Some composition via components probably would go a long way. But, just because you're planning on "extending the base functionality" in your individual apps doesn't mean that it has to be done via way too much inheritance.

Let Them Code

Was there a setup cost to rework the main app into a base library? Sure. And there was even more cost to make sure it was a good, easy-to-use library with excellent documentation. But all of the productivity, cleanliness, and quality benefits mean that all that work was a sound investment in a stable future with a solid foundation to launch from.

Any time you feel like you're running up against a wall because, "Augh, it would be so easy to fix in code, I just want to write some code here," the answer is probably that you should be able to write your solution in code rather than config. Just... make sure that code is your team's main language and not your team's internally written "good-enough" config-garbage-slop-monster.

Sticker Swap!

Ryan Palo — Wed, 30 Dec 2020 00:28:41 +0000

Hi! I just got some DEV stickers and I've got some duplicates that I can't think of anywhere to stick them, but I don't want them to go to waste. I'd love to send them to a new home and do a sticker swap with somebody or multiple somebodies.

If you see a sticker above that speaks to you, and you want to trade for one of the stickers that you have (coding-related preferred 😊), shoot me a DEV message and we'll get a mail swap going.

Advent of Code 2020 Solution Megathread - Day 25: Combo Breaker

Ryan Palo — Fri, 25 Dec 2020 14:40:44 +0000

Christmas Christmas Christmas Christmas Christmas!

The Puzzle

In today’s puzzle, we finally made it! But we have to hack our way into our room by spoofing the key card’s cryptographic handshake.

Thank you so very much for working through these with me. It’s been really fun seeing everybody’s solutions and working together on these. Whatever you are celebrating or not celebrating this season, I wish you a very blessed Christmas from our family and I hope your 2021 is filled with lots of love and joy. Thanks for being an amazing community and merry coding!

The Leaderboards

As always, this is the spot where I’ll plug any leaderboard codes shared from the community.

Ryan's Leaderboard: 224198-25048a19

If you want to generate your own leaderboard and signal boost it a little bit, send it to me either in a DEV message or in a comment on one of these posts and I'll add it to the list above.

Yesterday’s Languages

TBD (on mobile now!)

Merry Coding.