The middle layer of AI agent infrastructure (the “scaffolding” between the raw model and the work being done) is where most of 2026’s confusion sits. This article walks through the full stack from smallest to largest: prompts for one-off tasks, skills for reusable processes captured in markdown, plugins for installable workflow packages, MCP servers and app connectors for live data access, and hooks and scripts for the deterministic guardrails. Each piece is distinct, but they nest inside each other, and knowing which is which is what separates people who build reliable agentic workflows from people who keep copy-pasting prompts.
The real skill is no longer just prompting. It is drawing clean boundaries around repeatable units of work, deciding which parts should be left to the model’s judgment and which parts should be pinned down with deterministic scripts, and packaging the result so a teammate can install it and run it without rebuilding the setup. Bloated, department-wide plugins fail. Tightly scoped, single-job plugins (one for refunds, one for activations, one for upgrades) succeed.
Most importantly, this work is no longer the exclusive domain of engineers. Domain experts who understand their own workflows, including operators, marketers, customer success leads, and analysts, are now the right people to design and package these plugins, because they know where the deterministic edges live. The article closes with a quick decision heuristic for when to reach for each component, and a reminder that human judgment remains the final layer for whether the output is good enough.
The Scaffolding Around the Model
When people talk about AI agents, the conversation tends to fragment into shorthand. Prompts, skills, MCPs, connectors, hooks, scripts, plugins. If you live in the engineering world, those words are familiar. For everyone else, they form a foggy middle layer between “the model is smart” and “the work got done.” How you set up your model to actually do the work is one of the most common questions I get.
The reason to care about this is not that Codex happens to connect to lots of apps, though it does. Claude does that too. It is not because everyone needs to become a plugin developer, though you can if you want, and it has never been easier. It is not even because the plugin directory is the most exciting part of Codex. The real reason is that you need to understand how the secret sauce for an AI agent works. What is the scaffolding you put an AI agent inside of so it actually works?
Think of it like Darth Vader’s mech suit. Or the metal suits Transformers wear to get the job done. That is how LLMs work. They have suits around them that help them get work done, and Codex plugins are a handy way to see that scaffolding clearly.
The story is not that GPT 5.5 suddenly got smarter, although it did. The story is not that Codex happens to have extensions. The story is that agents are now capable enough to do very rich work, and the tools have gotten simple enough that even non-engineers can confidently build the scaffolding around the agent themselves. A little prompt engineering here, a local script there, a bit of work on an MCP server. These are real things that lots of non-engineers are now able to do.
OpenAI describes ChatGPT 5.5 as “better at messy multi-part work like planning and using tools and checking its work and navigating ambiguity.” The key phrase is “messy multi-part work.” If you want to do real frontier work, most people get stuck not because they lack the tool, but because they lack an understanding of the harness around it. There has not been a clean, clear instruction set explaining what all of these pieces are for. That is what this is.
What This Section Covers
The order is deliberate:
- Prompts
- Skills
- Plug-ins (which package up a workflow)
- MCPs and connectors (how agents access tools)
- Hooks and scripts (covered later)
- Marketplaces (how all of this gets distributed)
A super-practical workbook version, with a workflow audit, a decision tree for prompt versus skill versus plugin versus MCP, examples of what belongs in a skill.md file, a starter plugin structure, a testing checklist, and the trust questions to ask before you install or build something, will go on Substack.
Prompts: For Doing Something Once
A prompt is what you use when you want to do something one time. That is where we are in 2026. If the task is temporary, small, or highly specific to the moment, you probably do not need any of the rest of the infrastructure.
But a prompt is a poor home for anything you repeat constantly or consistently. A prompt can describe a process, but it does not really package up a workflow in a way that is repeatable. It does not carry tools with it. It is just a single piece of text you stick in. It does not carry permissions. Can you share your prompt with your team? There are little tools for that, but a prompt does not carry most of what we need it to carry if it is going to be reusable.
Prompts are useful for one-off asks, but most people index too heavily here. They put so much into the prompt that they generate hours and hours of wasted effort every week, because too much is being crammed into a format that was not built to hold it.
That is where skills come in.
Skills: Teaching a Tool a Reusable Process
A skill is where you teach a tool, Codex, Claude, whatever, a reusable process. For example, your team might have a particular way of reviewing pull requests, or a particular way of writing marketing documents. You want to be clear about what that is and how you do it. It is your house style, and you want to make sure that whatever LLM you use always uses that across your whole team. That is what a skill is for.
A skill, amazingly enough, is just a clear markdown document that describes in good detail how you do that work. And yes, there are skills to write skills. I have made skills to write skills over on the Substack. AI can absolutely help you write them.
Prompt Versus Skill: The Mental Model
The simplest way to hold the distinction:
- Prompt: one-offs.
- Skill: anything you want to reuse and reinvoke.
Because skills are universal, you do not have to worry about whether something is a “Codex skill” or a “Claude Code skill.” You just write the skill, then use it with whatever tool you happen to be using.
A Concrete Example
- Prompt territory: a one-off note to a client that is complicated and needs custom backstory pulled in.
- Skill territory: a batch of cold outbound notes with particular content pulled from a particular set of documents, customized to each individual, but following a consistent structure for how to do that work.
The skill in that second case basically says: this is what a good structured outbound email looks like. These are the paragraphs in it. This is the data we want to pull in. This is the beginning, middle, and end, and how you write a strong close.
You can write skills for marketing, for customer service, for success, and for engineering tasks. Literally anything an LLM can do more than once is a candidate for a skill. They are extremely flexible.
The Power Law of Skills
Once people get the idea, the biggest issue becomes that they write so many skills it is hard to keep track of them. There are tricks for that, but the core principle is to think of your skills as having a power law relationship: 20% of your skills will deliver 80% of the value. You have to find the right 20%, the ones repeated often, with high sensitivity to what goes right or wrong, and just jump in.
Plugins: Wrapping a Whole Workflow
If a skill is a way to do a thing consistently, a plugin is a bigger package around that. A plugin can include skills, but it can also include app integrations, MCP servers, hooks, assets, commands, and metadata. It takes a whole workflow, gives it a name, wraps around it, and makes it installable.
If you want to add an entire workflow in one go, and it is much bigger than a skill, that is a plugin. What is beautiful is that plugins are extremely shareable. A plugin is something your team can use without everyone manually reconstructing the setup.
Skill Versus Plugin, in the Outbound Email Example
Imagine you need a live connector to data, pulling from Salesforce to grab the right name and details about the client.
- Skill: says here is how to do the work.
- Plug-in: says here is the workflow package you can install, and all of it gets done for you, including the live data pull.
Real work rarely lives entirely in the prompt. It lives in the connectors we pull in live (Slack, Figma, GitHub, other data sources), in where we send our revisions for review, and in the technical skill we apply as we go. Everything I am describing is essentially training wheels that help the LLM understand how to do the work that matters. The clearer you are about that, the easier it becomes to get AI to do the real work.
Plug-ins wrap up a bunch of individual components and say: here is the whole thing, in a neat package. Copy it into your app, and the whole workflow is at your command.
You Are Already Doing the Plugin Work
If you think (a) AI cannot do this, or (b) it is too hard, here is the news: if you are any kind of serious AI user, you are already doing the plugin work. You copy from one app, paste into the chat, ask the model to reason, go get data from somewhere else, check the result, come back. It goes on and on. You are the human plugin. If you do not want to be the human plugin, consider making an actual plugin. And no, you do not have to be an engineer to make one in 2026.
MCPs and App Connectors: How Agents Reach the Systems Where Work Lives
Prompts, skills, and plugins are three different scales of scaffolding, with plugins being the biggest. So what are MCPs and app connectors?
This is how an agent gets access to the systems where work actually lives. When I said “we will plug into Salesforce for outbound,” that is an MCP. It is an app connector. It plugs in, figures out where to go to get live data, and comes back with real data. Most apps are better when they have real data.
Think of these as internet plugs. They plug in, get data back out. I am old enough to remember when we literally had to plug into the internet, before Wi-Fi. That is what you are doing with an MCP. It is a universal plug to data: put in, get back out. You can build an MCP, but increasingly, SaaS tools and the places where work happens are aggressively building their own MCPs and data connectors, so you do not have to.
Why MCPs Get Confused with Plugins
One reason I am doing a plugin video is that people misunderstand the relationship and assume an MCP connector is just the same as a plugin. It is not. The reason it is confusing: a plugin can contain an MCP, but a plugin typically has more to it. It is not just an MCP server. There is a whole piece of workflow being tackled with the plugin, which may include a call to live data plus a bunch of other things you do with that data along the way. A plugin is the larger package.
So far the map looks like this: prompts versus skills, skills versus the whole-workflow package of a plugin, and plugins versus the narrower MCP and app connector layer that plugins can include.
Hooks and Scripts: The Deterministic Layer
Hooks and scripts are for the parts of your workflow where you should not rely on the model remembering to be careful. Some things ought to be deterministic, by which I mean some things should not be left to the model.
Examples of work that should be deterministic, not left to model judgment:
- Code formatting: Run a formatter. Don’t ask the model to remember.
- Schema validation: Actually validate the schema. Don’t ask the model to think about it.
- Tests: Run the test. Don’t ask the model to imagine running the test.
- Structural contracts: If a generated file needs to be valid JSON, actually check it with a script.
- Pre-stop reviews: If a review should happen before the agent stops, build that review into the loop.
This is one of the most important parts of doing good work with agents, and it’s misunderstood. People think hooks and scripts are the same as MCP connectors. They aren’t. People think these checks should be left to the model’s best judgment. They shouldn’t. A good agent workflow is designed so that the deterministic parts are correctly framed as scripts or as hooks into deterministic services.
And here’s the key: hooks and scripts fit right inside plugins.
Plugins as Workflow Packaging, Not App Store Apps
Think of a plugin as a grab-bag present where you’ve got 10 things in the box. The plugin is the whole present around it. A plugin can contain scripts. It can contain hooks into other services. You’re not limited to just a prompt and an MCP connector inside a plugin. A plugin package is big enough to hold the whole workflow and make it reusable.
That is why the app store analogy is too small. We think of plugins as apps in an App Store. They aren’t really. And it’s not as simple as saying “Codex now has extensions.” That’s not wrong, it just undersells the power.
If you think of plugins as add-ons, you ask, “What can I install?” and you go passively shopping like you do on the App Store. If you think of plugins as workflow packaging, you ask a much sharper question: “What part of my work has enough repeatable structure that the agent should be able to inherit it and use it?” And maybe it’s something my whole team wants to use. That’s the real question.
The Lego Brick Model
Don’t think of each of these things (prompts, skills, scripts, hooks, MCPs, plugins) as individual battle bots competing to serve your AI. That’s not how it works. Think of them as Lego bricks that taken together make something bigger and more useful. In that analogy, a plugin is a bunch of Legos all built up together into a structure. A plugin has lots of these components (scripts, hooks, connectors) all inside it.
So you can ask yourself: Do I want a plugin for architecture review? For how I handle marketing documents? For how I handle customer service requests?
Drawing the Right Boundaries Around a Workflow
Part of our job as humans is to ask: what’s the right unit of work here?
Take customer service at a tiny company. Do you make customer service one plugin? Or is it smarter to say:
- Refund plugin that we invoke when a refund is needed.
- Activation plugin for adding and activating customers who somehow aren’t activated.
- Upgrade plugin for making sure customers can upgrade when they want to.
Your job is to understand the semantic meaning of the workflow and say, “This is a good unit of work that has a neat edge and boundaries around it that we can make into a plugin.”
That’s a skill worth a lot of money these days because very few people know how to look at a workflow and say, “Here’s how I draw edges around it. Here’s the boundary. And once I have the boundary, here’s how I turn it into a plugin I can repeatably share across the team.” That’s gold.
If you don’t know how to explain that the work has value in a particular bounded space, you’ll always be tempted to make a workflow too big and too wide and subject to problems. If all of customer success was one plugin, could it technically work? Maybe, if you were small and stuffed a ton into it. Is it a good idea? No. A workflow has one job, and the example I gave had three (probably eight in reality). You need more than one plugin for customer success at this imaginary little company. That’s okay.
Why Scaffolding Beats Pure Prompting
If we zoom back out, the difference is significant.
- Generic model with no plugin or scaffolding: Can say something useful at a high level. Maybe, if you prompt it repeatedly and waste a lot of hours, it will be specific to you, but only because you keep loading heavy prompts.
- Truly scaffolded agent: Reviews all of your work according to your standards, uses the right tools, and gets real work done. A 10x bigger deal.
It’s the same intelligence inside. Same LLM. This is a great example of how we are a big part of the answer to making AI smarter. If you want smarter work done, you have to put the scaffolding in place.
Plugins Are Now Accessible to Non-Technical People
Part of why I’m making this video now is that I have seen story after story of people building these, and it’s not as hard as it used to be. In 2025, I couldn’t make this video. In 2026, I can, because I have literally seen people without coding knowledge figure out how to build a plugin to support their work.
Editorial Review Example
Someone built a plugin for editorial work. The workflow: how you read the text, the three different ways you read the text, the comments to consider adding, the places where the text is rough.
Did it do all of her work? No, you still need a human editorial perspective. Did it save her a lot of time? Yes. It gave her a first pass with a review on where the text was rough, incoherent, or factually inconsistent. In some ways much better than a person, and faster too. She could build that without reprompting every time. And it was much bigger than a skill because it involved understanding more information sources than just one piece of text.
Design Example
You can plug into Figma or your design tool of choice and pull down details of how a current design looks, plus how the design language looks. You can build a workflow that accounts for all of that and pops out new work. This aligns with how the hyperscalers are starting to think about cloud design. Claude Design, which dropped just a couple of weeks ago, is arguably a fancy plugin with a UI for Claude for design. The plugin was so important they made it a product. That’s how much plugins matter.
If you think you can sit around and wait for Claude or ChatGPT to launch all your dream plugins, I have a bridge to sell you. You have got to take proactive action and say, “I want this plugin for this thing. It’s not perfect, it’s too much manual work, I waste too much time in custom prompting, my skills aren’t enough. I want something with a data connector, a script that validates and makes sure it works, plus a skill.” That’s a plugin.
A weekly business report is another great example: spreadsheets, Slack context, docs, dashboards, past reports, charts. That’s a plugin.
Agentic Scaffolding Must Not Stay Vague
If scaffolding just means “some engineering stuff around the agent” to most of us, then only engineers can ever participate in designing it. That is an old 2022-era problem. In 2026, if the workflow is real, the people who understand the work must be the ones who put that knowledge in.
I have talked to person after person from non-technical backgrounds who figured this out and are now stamping out work because they know what good looks like. I talked to two of them this morning, working on complicated retail-scale workflows, because they figured out what works for them. They know which sources matter. They know when the output is wrong. They know what steps are always forgotten. That domain knowledge (“non-technical” is blurry in 2026) is what matters and what you leverage to create custom plugins.
The Mental Model: Quick Reference
The way to encode all of this has become more unclear, not less, in the last six months. Do you write a better prompt? Now we have skills, is it a skill? Do I ask my engineers to make an MCP server? Is it a connector? Maybe it is a plugin after all. Disambiguate. Understand what each thing does:
- Script: Helps you do predictable, deterministic things every time.
- Skill: Helps an LLM follow a process in a way that is clear, shareable across teams, and consistent.
- Prompt: Good for one-off work. Yes, prompting still matters. All the work you did in 2025 paid off.
- Plugin: A bundle around a bunch of things. Includes scripts, skills, reusable pieces of prompts, MCPs, and connectors.
- MCP / app connector: Connectors to live data, which can nest inside a plugin as one Lego brick in a larger model.
This is the mental model I wish people had. Engineers know this stuff, but it isn’t getting explained to the rest of us. There should not be a mysterious middle layer between the LLM and the work that gets done for you.
Decision Heuristics
- If you do it once, it’s a prompt.
- If you do it repeatedly, it’s a skill.
- If the workflow needs to travel, other people need to install it, or it needs tools, assets, or connectors, it’s a plugin.
- If it needs access to another system, it’s an MCP or app connector. That live data can nest inside a plugin.
- If the workflow has to be verified, add a check.
Not everything needs to be a plugin. Some things should stay prompts. Some should stay skills (no extra data, no other stuff needed). Some should be normal scripts that never touch an LLM. Some should stay human, the judgment to know what’s good is going to be human judgment.
The goal is not to turn your workspace into a gigantic museum of plugins you never use. The goal is to understand the parts of your work that are repeated, valuable, and structured enough to package, then figure out the right solution.
Why Leadership Needs This Too
Even CEOs need this. I don’t want a CEO asking, “Should it be a skill? Should it be an MCP?” If your CEO is confused about this harness stuff, show them this video. The C-suite (especially anyone but the CTO) tends to be non-technical enough that they don’t get it. They don’t understand that a script is a deterministic check and you shouldn’t just trust the model to check itself. So they get confused and say, “Why aren’t you using AI?” And you say, “I am using AI. I just want a deterministic script at the end.” That’s a real conversation I’ve had.
You need to give leadership enough context on this so they can actually support the AI transformation. That starts with understanding what’s in the box when it comes to a harness, so people don’t get confused.
When we talk about the difference between an LLM (even an agentic LLM in Codex or Claude Code) and a truly useful personalized workflow, this is what we’re talking about: the difference between skills, plugins, and connectors and how they matter. Make sure the people who need to see this see it in your world, so you get the support you need. I have had enough conversations with senior leadership to know that in most organizations, very senior folks have zero clue about this. Don’t be like that. Share it with the people who need to hear it. Make sure everybody has the same mental model.
This is one of the most powerful ways you can do practical AI automation today. It’s where the leverage is living in 2026.
Meta
Added: 2026-05-09