Skill, Prompt, Tool, or Workflow?

The situation

As agent systems grow, teams often use the same word for very different things. A database lookup, a ten-step sales process, a writing style instruction, and a complete research capability may all be described as "skills." That makes design discussions imprecise and usually leads to capabilities with inconsistent boundaries.

The naive solution

Represent everything as another natural-language instruction. If the model can understand the instruction, let it decide how to interpret and execute the task.

The hidden constraint

Different kinds of behaviour need different control mechanisms. A tool should expose a concrete action or data source. A prompt should shape reasoning or output. A workflow should enforce a sequence when the business needs deterministic order. A skill sits above those pieces and packages them into a reusable capability. If I blur those layers, I end up asking the model to enforce rules that software should enforce.

The decision

Use the simplest abstraction that matches the requirement. I use prompts for behaviour and judgement, tools for controlled actions, deterministic code for non-negotiable process, and skills for reusable capabilities that combine reasoning, context, tools, and rules around a recognisable job.

The implementation

For example, "create CRM note" is probably a tool. "Write notes in our concise account-management style" is prompt guidance. "Every refund above this value must be approved before payment" belongs in deterministic policy or workflow code. "Handle a refund request" can be a skill that gathers order context, applies policy, drafts a decision, and invokes the correct approval or refund tools. That separation means I can test each layer for the thing it is actually responsible for.

The tradeoff

The architecture feels more formal than letting one agent improvise everything. There are more interfaces between pieces. The benefit is that I can decide which behaviour is probabilistic and which behaviour is not allowed to be probabilistic.

The evidence I would look for

I would look for fewer business rules expressed only as prose, fewer tools with vague responsibilities, and clearer failure diagnosis. When a refund workflow fails, I should be able to tell whether the model judgement was poor, a tool returned bad data, or deterministic policy logic rejected the action.

The reusable lesson

Do not use model reasoning to replace ordinary software boundaries. A skill should orchestrate the right combination of judgement and control, not erase the distinction between them.

The consultant's questions

• Which current "skills" are really just tools with an overly broad description?
• Which business rules are being trusted to a prompt even though they should be enforced in code?
• Where is judgement genuinely useful, and where is a deterministic workflow safer?
• Can every action-producing capability explain which layer is responsible for the final decision?