From Applets to Agentlets

Know What You're Building Before You Build It

Introduction

Everyone’s “building agents” now. Drop a custom prompt into Kiro or Claude Code, wire up a skill, maybe add an MCP server and suddenly you’ve “built an AI agent.”

I was chatting with a junior engineer recently and encouraged him to automate some of the tasks he was doing with AI. He was excited but wasn’t sure how to write an agent he could share with his team. We use Kiro extensively, and on deeper probing, I found he wanted to build some skills, agent scripts, and bundle an MCP server that the coding agent can execute to get the job done. He wanted to build a profile, what I call an Agentlet, not an Agent.

He’s not alone. I see this confusion daily, and it’s not anyone’s fault. The services we’re given blur the line. With the AI blitz, teams scramble to customize every new release for their internal users as fast as possible. When OpenClaw went viral, teams rushed to sandbox and ship it internally, and many released half baked solutions that only expert developers could use, when what they really needed was a finished product bundled with the right skills and room for teams to add their own.

The real distinction isn’t about quality or effort. It’s about where AI fits in your stack. Applications of AI have no limits, it being integrated vertically across domains and used in as many applications as possible. I find it useful to think in two categories: AI for Productivity and AI for Production. The line between them isn’t always sharp, and real systems often sit somewhere in between, but the mental model helps clarify what you’re actually building.

AI for Productivity: Agentlets

I think of these as agentlets: custom prompts, skills, MCP tool configurations, or context files wired into an existing coding agent. An agentlet shapes what an agent does but doesn’t own the loop.

Agentlets rely on the underlying coding agent like Claude Code or Kiro as the runtime. Without the host agent, they’re just files sitting on disk.

Take a code review skill in Claude Code. You write a skill file with review conventions, linting preferences, security checks, and your team’s style guide. Claude Code does the orchestrating: reading files, running tools, managing context, deciding what to look at next. Your skill tells it what to look for and saves you time. It's valuable, but it's an agentlet, not an agent.

This is where most builders should be spending their time. While I experiment with every AI tool that launches and automate routine tasks often, I barely use all of them all the time. Following the 80/20 principle, I use 20% of the tools 80% of the time. If I find myself repeating any task more than once, I write a skill. MCP servers are great, but I try to use very specific ones with fewer tools. I wrote a post on how you can use a vector DB with semantic search to identify the right tool instead of polluting the context. But skills with the right front matter solve most problems. For structured, predictable, and auditable control over AI agents, you can use agentic scripts.

The “fat skills, thin harness” philosophy, recently demonstrated by Garry Tan’s gstack, reinforces this. The productivity gap between engineers isn’t about which model they use. They’re using the same models. The difference is in the skills they’ve written: reusable markdown procedures that encode judgment, process, and domain knowledge. The host agent (Claude Code, Kiro) is the thin harness. Your skills, prompts, and context files, your agentlets, are where 90% of the value lives.

One principle I enforce in my own workflow: if I have to ask the AI for something twice, I automate it. The first time, you do it manually. If it works, you codify it into a skill. If it should run automatically, you put it on a cron. Every agentlet you write is a permanent upgrade. It never degrades. It never forgets. And when the next model drops, every skill instantly gets better.

AI for Production: Agents

In this post, I use “agent” to mean a fully autonomous system that operates independently over extended periods, using various tools to accomplish complex tasks. It owns its orchestration, manages state across steps, decides what to do next, which tools to call, when to retry, and when to stop. The agent IS the application.

You build agents with frameworks like Strands SDK, LangGraph, or CrewAI. You write the control flow, the tool selection logic, the state machine. You handle failures, branching decisions, and multi step coordination. This is software engineering and more than just prompt engineering.

Source: https://strandsagents.com/blog/strands-agents-model-driven-approach/

Take a travel agent. You tell it, “Book me a trip to Tokyo next month for under $2,000.” It autonomously searches flights, compares prices, checks hotel availability, cross references your calendar, manages booking state, handles payment failures, retries with alternative options, and coordinates across multiple APIs. It owns the entire loop from request to confirmation. You build that orchestration with something like Strands SDK and deploy it on a runtime like AgentCore that handles hosting, scaling, and session management. It runs as an independent service and that’s an agent.

The Litmus Test

One question settles it: Who owns the control loop?

If the host application owns the loop and only calls your code when it decides to, you built an agentlet. Your CLAUDE.md file doesn’t boot up and start reviewing code on its own. Your Kiro skill doesn’t orchestrate anything until Kiro decides to read it. They are configurations that rely on a harness’s event loop.

If your code owns the loop, you built an agent. Your application decides when to call the LLM, when to hit an API, when to evaluate state, and when to terminate. The orchestration logic is yours.

Conclusion

Servlets, applets, and now agentlets. Agentlet is not a real word. I came up with it to reminisce about my old days building applets. Agentlets customize the loop. They’re skills, prompts, and tool configs wired into coding agents like Claude Code or Kiro, running on top of a host agent that does the real orchestration.

Agents own the loop. They’re built with frameworks like Strands SDK, LangGraph, or CrewAI. They’re deployed on runtimes like AgentCore. They run as independent services.

Looking back at the evolution from Applets to Agentlets, the one constant in software is that the landscape is always shifting. It reminds me of my early career when I first came to the US on an H-1B visa. There are restrictions on what one can and cannot do on a Visa. I would delay things until I get my permanent resident status and then until I get US Citizenship. In hindsight, I could have gotten my Masters degree while on a Visa and there was no need to wait for getting my permanent residency. I told my young colleague that we find reasons to delay doing things waiting for the right moment. The right moment is now and I don’t see any reason for him or anyone to wait for Anthropic to release Mythos or whatever the next LLM or AI framework ends up being.

Start building your skills and build agentlets or agents. Consider your use case and refer to my earlier post on Prompts vs Skills vs Agents if you are unsure. Build agentlets for 80% of the work you do, and it will help accelerate the remaining 20% around building agents.