Thor Henning Hetland’s Post

Humans are lazy in a very specific way: Adding a new rule feels safer than deciding which old rule should be removed. So prompts grow. CLAUDE.md grows. Skills multiply. Then governance adds rules for how many skills each agent may have, how they should be named, reviewed, versioned and approved and then someone adds just more. Sometimes it is just overfitting to yesterday’s failures. A mature AI framework & developper should not only know how to add instructions, skills and agents. Framework itself should know what to retrieve when needed—and what no longer deserves permanent attention. Less is not always more. But more is very often just too much more.

𝗪𝗵𝗮𝘁 𝗔𝗿𝗲 𝗔𝗜 𝗖𝗼𝗺𝗽𝗮𝗻𝗶𝗲𝘀 𝗗𝗼𝗶𝗻𝗴? I do not believe the current hype. Major AI companies sell products with obvious flaws. I watched a recent presentation from an Anthropic developer. They discussed using claude.md to instruct agents. They now call this context "memories." The presentation moved to a "memory layer." This layer tracks these memories. They claim agents update these memories themselves. Then came the problem. This setup fails in production. To fix agents working against old code or stale assumptions, they suggest versioning and hashing. They call these "guardrails." They then mention portability through a clean API. The goal is a self-learning loop to make agents better. But they do not explain the baseline. They do not explain how they measure improvement. The use of the word "learning" is also wrong. It sounds like they confuse this loop with fine tuning. This looks like a way to get people to burn through tokens. This setup will not work in complex, production-grade systems. Source: https://lnkd.in/g7GtAVzH Optional learning community: https://t.me/GyaanSetuAi

𝗣𝗹𝗲𝗮𝘀𝗲 𝗦𝘁𝗼𝗽 𝗖𝗵𝗮𝗻𝗴𝗶𝗻𝗴 𝗔𝗴𝗲𝗻𝘁 𝗣𝗿𝗼𝗺𝗽𝘁𝘀 𝗕𝗹𝗶𝗻𝗱𝗹𝘆 Building AI agents often leads to random testing. You change a prompt and think the system improved. This is a mistake. LLM systems work differently. A change that helps one example often breaks another. Stop relying on vibes. Use a structured evaluation loop instead. Start with a small dataset. You do not need thousands of examples. Use 10 to 25 strong cases. Your dataset should include: - User input - Expected tool - Expected parameters - Expected output - Edge cases - Failure cases This creates a stable baseline. Treat every prompt change as an experiment. Change one variable and run your entire dataset again. This tells you if your change helped or hurt your overall performance. Use different types of evaluators for different tasks: 1. Code-based evals Use these when rules are clear. If code can check a result reliably, use code. It is faster and more consistent. 2. LLM-as-a-judge Use this when you need to judge quality. Ask the LLM specific questions like: Is the summary clear? Use labels instead of vague scores. 3. Human evaluation Humans are still necessary for complex tasks or subjective feedback. Watch for regressions. A regression happens when a new update makes the system worse at an old task. You might improve writing quality but break tool selection. Without evals, you will miss this. Test your evaluator too. If you use an LLM to judge your agent, compare that judge against a known correct answer. This ensures your judge is accurate. A good evaluation result shows more than one score. It should show: - The new score - The old score - The difference Do not say: The new prompt is better. Say: The new prompt increased tool accuracy from 80% to 90%. Evaluation-driven development turns vague feedback into specific fixes. Create test cases. Small datasets beat vibes every time. Source: https://lnkd.in/gXcmUDUp Optional learning community: https://t.me/GyaanSetuAi

Creating effective skills is crucial to making AI agents successful. But a skill is so much more than a carefully crafted prompt. Here's a cheat code for making better skills. At its core, a skill is a set of instructions that an agent can use to perform a task more effectively. Those instructions can consist of three things: prompts, code, and data. Prompts are the part of the skill everyone thinks about first, and many skills are nothing more than instructions that the agent is supposed to follow. The problem with prompt-only skills is the core problem with agents in general: they don't reliably follow instructions, especially in a long-running task. There is no way around this reality at present, it's a fundamental property of transformers (the technology underlying LLMs). Skills become significantly augmented when they have access to code they can run. Code follows instructions exactly, every time. Code can process operations at millions of times the speed of LLM token generation. And in a world where token usage is increasingly a major cost line item, code is basically free to run. Data is information that agents and/or code can access to make themselves more useful. A skill to find and book an available conference room needs to have data on what conference rooms exist, what buildings and floors they are located at, how many people can fit, what equipment they have, etc. When I have an idea for a new skill, first I tell my agent to create a small database and write a simple CLI to perform CRUD operations on it (any agent will understand that). The CLI should be self-documenting and return clear errors. Then I describe what I want the skill to accomplish, and ask it to create commands and tables to execute it. I then test it myself a number of times to get a sense of how it fails. It will likely be pretty weak at this point; that's ok. Here's the cheat code: I then tell the agent to think of as many examples of tests as it can of the skill's functionality. Then I tell it to run a loop (/goal) where it spawns a sub agent with fresh context to execute each of those tests 10 times. After each battery, the main agent uses the failures to update the skill. It can change the prompt; the CLI's commands, docs, and error messages; and add mocked test data to the database as necessary. It's not allowed to change or skip any tests, and it's not allowed to give up until all attempts in a battery are passed with a 99% success rate (or 95%, or 100%, whatever is appropriate to my use case). Then I move on to something else. What emerges is a largely bulletproof skill that follows instructions extremely well and runs more quickly and cheaply than any prompt. While this doesn't work for every class of skill, it's been quite a useful pattern for me!

SkillScript We build with AI agents every day, and one tension kept nagging me: an agent is only genuinely useful when it can do real work on its own. But handing an agent the keys to your systems is a hard thing to get comfortable with. One solution is a harness like NanoClaw, where the agent lives in a container and can only operate in channels you allow. But a container answers where an agent can act, not what it does once it's in there. Inside those allowed channels, the agent is still improvising every step with a frontier model: non-deterministic, hard to review before the fact, and a little different every run. For a one-off task, fine. For work you want running unattended, every morning, on every alert, "trust me, I'll figure it out each time" isn't something you can sign off on. What we wanted was a way to let the agent write down what it intends to do, have a human approve that once, and then have it run the same way every time, with no improvising at execution. So we built Skillscript: a small language that agents write their own automations in. The agent drafts a skill; a person approves it (it literally can't approve its own; that's a cryptographic boundary, not a policy); and from then on it runs as a fixed, auditable procedure. Least privilege at the action level, not just the network level. It's captured a lot of our repetitive agent work, briefings, monitoring, and research into procedures we trust, and lets us route the cheap, bounded work to small local models instead of burning frontier tokens on it. It's early, and honest about that, but it's genuinely useful to us, so we wanted to share it: https://lnkd.in/eQZJyHqt http://www.skillscript.ai If you're building with agents and wrestling with the same "useful but trustworthy" tension, I'd love your thoughts.

𝗔𝗽𝗽𝗿𝗼𝘃𝗲 𝗜𝗻𝘁𝗲𝗻𝘁, 𝗡𝗼𝘁 𝘁𝗵𝗲 𝗗𝗶𝗳𝗳 When you use AI agents to write code, you face a hard choice. You can let the agent run free. If it drifts from your goal, you might not notice until it is too late to fix. You can stop the agent at every step. This makes you the bottleneck. Your autonomy disappears. Most people choose a middle ground. They show the human the full diff. This is a mistake. The volume of changes is too high. Humans stop reading the diffs, and your intent is no longer protected. You must change what the human judges. The machine should handle correctness. The human should handle intent. Use this decision table to decide what to show at your approval gates: • Behavior-shaping artifacts (Rules, docs, agent definitions): Show the full text. The text is the intent. • Control plane (Hooks, permissions, CI configs): Show the full text. These change the rules themselves. • Implementation code: Show an intent summary. Tell the human what the change aims to do. • Evidence-side files (Tests, lint configs, coverage): Show the full diff. These prove the code works. • Deterministic gate FAILs (Secret scans, lint errors): Show the specific error line. To keep the summary honest, you need one specific rule. Every summary must include a "Divergence from plan" declaration. The agent must pick one of three values: - None - Yes - Needs re-approval This forces the agent to admit when it changed the plan. It turns a silent omission into a falsehood. A review agent is an inspector, not an approver. It can find bugs, but it has the same blind spots as the agent that wrote the code. Never let an LLM close the loop alone. Stop checking if the code is correct. Start checking if the code is what you actually wanted. Source: https://lnkd.in/gWH3irUd Optional learning community: https://t.me/GyaanSetuAi

The problem is simple: how do you trust a system that can lie? We've all been there. The AI said it was done, we looked, it wasn't. You could ask it to finish the work, but you still don't trust it. The real solution is asking for hard evidence that connects a promise to the correct definition of being done and a real receipt at the end. Let me break it down. Say you're asking your AI to "build a web page". Your AI may build it, but not deploy it. You check, and it's not live. Then it says, "But it's right here." The problem in this example is that the page exists, but your definition of 'done' was too vague. "The page returns status code 200 in my browser" is better. Your agent can then see that just building the page wasn't enough. It has to publish its work, open your browser, and show you the status code. That's hard evidence. If you want to learn how to create systems that produce verifiable output, we go deep, here: https://lnkd.in/g4fNEx_J

You've heard "AI agent" a 1000 times and you're still not 100% sure what it is, right? Let's break it down from the start. 𝗣𝗿𝗼𝗺𝗽𝘁: A prompt is what you type in. Like: "𝘋𝘦𝘧𝘦𝘯𝘥 𝘮𝘺 𝘥𝘦𝘤𝘪𝘴𝘪𝘰𝘯 𝘵𝘰 𝘱𝘶𝘵 𝘱𝘪𝘯𝘦𝘢𝘱𝘱𝘭𝘦 𝘰𝘯 𝘱𝘪𝘻𝘻𝘢. 𝘛𝘰 𝘮𝘺 𝘐𝘵𝘢𝘭𝘪𝘢𝘯 𝘧𝘳𝘪𝘦𝘯𝘥𝘴. 𝘎𝘰𝘰𝘥 𝘭𝘶𝘤𝘬." That's a prompt. You've been doing this for years. You're basically a senior prompt engineer. Yay! 𝗦𝗸𝗶𝗹𝗹 = saved instructions + prompt. You take a good prompt, save it, and now it loads every time instead of you retyping it. That's a skill. 𝗔𝗴𝗲𝗻𝘁 = skill + tool. Give that skill a tool, and now it can act on its own instead of just answering once. That's an agent. "𝘖𝘬 𝘣𝘶𝘵 𝘸𝘩𝘢𝘵 𝘪𝘴 𝘢 𝙩𝙤𝙤𝙡?" A tool is the thing that lets the AI actually do something instead of just talking. Search the web. Send an email. Read a file. Run code. Check a database. "𝘐 𝘢𝘭𝘴𝘰 𝘩𝘦𝘢𝘳𝘥 𝘢𝘣𝘰𝘶𝘵 𝘵𝘩𝘪𝘴 𝘵𝘩𝘪𝘯𝘨 𝘤𝘢𝘭𝘭𝘦𝘥 𝘔𝘊𝘗..." An MCP is quite simple. It's just a package of tools. For example, a Gmail MCP comes with tools like: read your inbox, send an email, search messages, create a draft, add a label. One connection, a whole set of tools ready to go. So the chain is simple: prompt becomes a skill, skill plus a tool becomes an agent, and an MCP is just a bundle of tools you plug in. 𝗡𝗼𝘄 𝗺𝗼𝗿𝗲 𝗶𝗺𝗽𝗼𝗿𝘁𝗮𝗻𝘁𝗹𝘆: 𝗽𝗶𝗻𝗲𝗮𝗽𝗽𝗹𝗲 𝗼𝗿 𝗻𝗼 𝗽𝗶𝗻𝗲𝗮𝗽𝗽𝗹𝗲 𝗼𝗻 𝗽𝗶𝘇𝘇𝗮? Tell me your take. And let me know if something clicked today

What are Agent Skills? Agent Skills are a lightweight, open format for extending AI agent capabilities with specialized knowledge and workflows. At its core, a skill is a folder containing a SKILL.md file. This file includes metadata (name and description, at minimum) and instructions that tell an agent how to perform a specific task. Skills can also bundle scripts, reference materials, templates, and other resources.

“I want to learn Agentic AI, but I don’t know where to start.” Here’s the order I’d learn it in 2026: Apply to Agentic AI roles: https://lnkd.in/dcFxi2hp 1. LLM fundamentals - Transformers, tokens, context windows, parameters, prompting. 2. Prompt engineering - Zero-shot, few-shot, CoT, ReAct and especially prompt evaluation. 3. APIs + external data - Learn JSON, APIs, structured outputs, and how models interact with real systems. 4. Context engineering - Memory, state, token management, and what information the model actually needs. 5. RAG - Embeddings, vector databases, retrieval, reranking, and grounded generation. 6. Tool use - Function calling, APIs, tools, and MCP integrations. 7. Agentic workflows - Planning → acting → observing → reflecting → retrying. 8. Multi-agent systems - Only after you understand single-agent reliability. 9. Advanced autonomy - Long-term memory, planning, feedback loops, RL, fine-tuning, and self-improving systems. My biggest advice? Don’t start with “Which agent framework should I learn?” Start with: 1. How does the model get context? 2. How does it choose an action? 3. How do I know it worked? Frameworks change all the time, but those problems don’t.