In my last post, we talked about the danger of monolithic prompts—those mile-long blocks of text where we ask an LLM to be a data fetcher, an analyst, and a formatting engine all at once.
When you are starting out or actively working to improve your development skills, it’s incredibly easy to fall into this trap. You start building out your own tools, things get messy, and you wonder: Am I missing something here, or am I just on my own weird path?
You aren’t on your own path. In fact, you’ve stumbled right onto one of the most critical design patterns in modern AI engineering: treating AI skills and agents exactly like software functions.
Let’s look at how refactoring a messy Account-Based Marketing (ABM) and Sales Intelligence workflow into modular “functions” completely changed how I build.
The Sandbox: Dialing in Sales Intelligence & ABM
To anchor this, let’s use a real problem I’ve been tackling across my development projects (including early iterations of my HoneOS Vision platform).
In B2B sales and ABM, lazy lists of names and emails are useless. You want targeting packages—deep insights into a company’s actual pain points, existing tech stacks, and active buying triggers so you can build hyper-customized assets for them.
If you try to build a single prompt to handle that entire workflow, it looks something like this:
Read this unstructured company data. Determine if they fit our target profile.
If they do, extract their tech stack, their biggest pain points, and why they
might buy from us. Then, draft a personalized outreach email based on that data,
and output everything as clean JSON.This prompt is a ticking time bomb. It’s trying to be a gatekeeper, an intelligence analyst, a copywriter, and a database administrator all at once. When it inevitably breaks, you have no idea which part failed.
The Mindset Shift: Prompts are Just Functions
When you are learning to code, one of the first major concepts you learn is modularity. You learn to break a giant, unmanageable block of code down into small, predictable functions that do one thing well.
Why should AI be any different?
When we treat an AI capability as a “Skill” or an “Agent,” we are really just containerizing a function. A well-constructed AI skill should follow the exact same rules as a traditional code function:
- It has a clear Input contract (e.g., raw text).
- It has a single responsibility (e.g., only extract the tech stack).
- It has a predictable Output contract (e.g., a clean text list or explicit token).
Instead of one monolithic prompt, our ABM pipeline becomes a chain of isolated, functional building blocks:
skill_QualifyLead(company_data)-> Returns[MATCH]or[SKIP].skill_ExtractTechStack(company_data)-> Returns a clean list of infrastructure tools.skill_DraftABMAsset(tech_stack, pain_points)-> Returns a highly tailored outreach draft.
Why This Matters for Improving Developers
If you are relatively new to programming or leveling up your stack, mapping AI to traditional coding principles like functions is a massive superpower.
1. You Learn System Architecture Naturally
By breaking prompts apart, you are forcing yourself to design data pipelines. You start thinking about how data flows from Function A to Function B, how to handle state, and how to catch errors. It turns “prompting” into actual software engineering.
2. Debugging Stops Being Guesswork
If your final outreach email looks generic, you don’t have to rewrite a 1,000-word prompt. You just look at the output of skill_ExtractTechStack. Did it fail to find the data? Or did skill_DraftABMAsset fail to use it properly? You can isolate, tweak, and fix the specific breaking point instantly.
3. Faster Iteration, Better Assets
Because these skills are modular, you can build them faster and reuse them constantly. If I build an incredibly solid text-extraction skill for an ABM pipeline today, I can drop that exact same “function” into a completely different project tomorrow without rewriting a line of core prompt logic.
It’s Just Software Engineering Now
If you’ve been leaning toward treating your AI interactions like structured, containerized functions, congratulations: you aren’t lost. You are building clean, predictable architecture.
In the next post, we’re going to look at the fun part—putting on our developer hats and writing the actual code to orchestrate these individual skills into a functional, automated pipeline.