AI Agents: Four Skills More Important Than a Good Prompt
Type: kb/sources/types/snapshot.md
Author: Kyrylo Balalin Source: https://mezha.ua/articles/shi-agenti-chotiri-navichki-yaki-vazhlivishi-za-dobriy-prompt-311970/ Date: 2026-06-04T19:03:00+03:00 Translation of: kb/sources/shi-agenti-chotiri-navichki-vazhlivishi-za-dobriy-prompt.md
If I had to choose the single most important article from this whole series on AI agents, it would be this one. The third part of the series covered the technical foundation of agentic AI: tools, MCP, skills, commands, subagents, plugins. It is a map of what an agent's work is made from. But the map leaves one important question open: how do you work with it deliberately, so the results are consistently good rather than random?
As corporate AI adoption shows in practice, nobody has a problem spreading technological solutions. There is not even much of a problem teaching users how to operate them on a purely technical level. Our own previous article, after all, gives the basic concepts of agentic AI. The problem is preparing people for the right perception of AI and the right interaction with it.
One extreme is credulity and optimism: we can see the consequences in LinkedIn feeds full of "useful" thoughts generated by chatbots. The other extreme is embodied by neo-Luddites who celebrate every AI failure and wait for the bubble to burst. But the truth is not even in the middle. It lies in the plane of the English word "mindset," in the sense best rendered as "way of thinking." Because when a person has such a multifaceted tool as AI at their disposal, they have to adapt their way of thinking to it.
One possible answer is a framework called AI Fluency, which Rick Dakan of Ringling College of Art and Design and Joseph Feller of Cork University Business School developed in 2023-2024 from their own research into how AI changes creative and business processes. Anthropic later joined the initiative to turn the framework into a free course. The course and supporting materials are available on Anthropic Academy at anthropic.skilljar.com/ai-fluency-framework-foundations. The course is in English, so if your language level allows it, it is worth taking in full - 12 lessons take only a few hours, and it is an excellent investment in yourself.
The framework defines AI Fluency, or fluency with AI, briefly: the ability to work with AI effectively, productively, ethically, and safely. Before going deeper, it is worth stating the article's main claim. The quality of AI work depends on how consciously a person holds four parallel levels: what they hand to the model, how they describe it, how they check it, and what they ultimately take responsibility for.
Why "prompt engineering" is not even a quarter of the work
Prompt engineering is a real and useful skill. How to formulate a request well, how to give examples, how to divide a complex task into steps, how to use role context. All of this works. There is no argument there. The problem is that users who develop only this skill hit a ceiling fairly quickly. You can write a brilliantly formulated prompt, but if the task was a poor fit for the model, the result will be technically correct and useful to nobody. You can get a beautifully formatted text with a quiet error in one of its points because the user did not look critically. These are gaps in other skills that prompt engineering, by definition, does not cover. The framework we are moving to starts from the thesis that high-quality AI work needs four parallel competencies. Prompt engineering is a special case of one of them.
The four skills of AI Fluency
AI Fluency consists of four competencies. In English they are called Delegation, Description, Discernment, and Diligence, so in the authors' terminology they are also called the "four Ds."
Translating the words is useful for understanding, but there is no need to invent extra entities, so the four English terms will be used below: - Delegation: deciding which tasks to hand to the model and which to keep for yourself. - Description: the ability to describe a task so the model can do it without guessing. - Discernment: critically evaluating what the model produced and how it behaved while doing so. - Diligence: responsibility for the final result, transparency about AI use, ethics, and accountability.
These four skills work in parallel. In real work they are active at the same time, and weakness in any one of them damages the result of all the others.
Three modes of working with AI
Before unpacking the four skills individually, we need to look at the three interaction modes, called modalities in the original, that the framework distinguishes.
Automation: a person gives AI a specific task and the model executes it. Classic examples: "Rephrase this paragraph more formally," "Turn the table into CSV," "Write a short summary of this document." No further dialogue, no collaboration, just execution according to a clearly specified instruction.
Augmentation: the person and the model work as partners thinking together. The person sets a task, the model answers, the person sees what is useful and what is not, sends a refinement, gets a better answer, repeats. This is the mode in which most substantive knowledge work happens. Returning to the second part of this series, the whole chain with NotebookLM, Claude, GPT Image 2, and GPT-5.5 for the infographic was pure augmentation. In principle, even a long dialogue with a chatbot is the simplest example of this mode.
Agency: the person configures AI so it performs tasks independently within pre-agreed rules. This is the mode of the experiments from the first part (writing an Android app) and the conceptual base from the third part. The assumption is that you no longer need to "sit over" the model; you can configure it and give it some room to work.
Why are these three modes important for a discussion of the four skills? Because different modes load the skills differently. Automation mostly loads Delegation and Description: choosing the right task and formulating it correctly. Augmentation loads all four skills at once, which is why it is a harder mode for most people. Agency additionally places the highest demands on Diligence, because the more autonomous an agent becomes, the more important it is before launch to have a clear understanding of boundaries, responsibilities, and verification methods. Agency also changes the character of Discernment: when the model produces one letter, checking is a one-off act; when an agent carries out a multi-step task by itself, discernment becomes more of a continuous process of monitoring and auditing the chain of actions than a one-time proofreading of a finished result.
Delegation
The hardest of the four skills, and not accidentally the first one in the framework. Delegation is harder than answering the question "what, among everything I do, should I give to AI?" It is better formulated as: "do I understand this task well enough to make a justified decision about whom to give it to?" In the framework, mature delegation is divided into three levels of awareness.
Understanding the goal and the task. "What do I actually want to get?" "What result will I consider good, what will I not, which components of the task or plan really matter, and which have been invented?" In principle, this skill is very useful in life even without AI. If the operator cannot describe quality criteria without saying "well...", AI cannot fix that, because it will aim at a blur. At this level, a person decomposes the task into components: which of them should be done by a human, which can be entrusted fully to AI, and which should be done together.
Understanding platform capabilities. "What exactly does this tool do well, and what does it do badly?" This is also a concrete question. Claude and ChatGPT behave differently with literary text. Cursor, Codex, and Claude Code have different strengths when working with code. The same request to a model without internet access and to a model with access will produce very different answers. Knowledge of specific strengths and weaknesses is a separate skill, accumulated through practical use rather than by reading marketing pages.
Distributing tasks between human and AI. Once you understand the task and the platform's capabilities, you need to make a concrete decision: this part is done by the model independently, this part is done jointly by the human and AI, this part is done by the operator, and the model helps only at certain points. The target should be maximum usefulness, not maximum automation. These are different things.
A simple test of delegation quality from the second part of the series is the story with the logo. GPT Image 2 draws them perfectly, while Claude Design produces something miserable.
Description
If delegation is the decision about "what to hand over," then description is the decision about "how to hand it over." A good task description involves three different kinds of description, which usually go together.
Product description. What should be produced as output. The request "help me choose a laptop" leaves the model so much room that the result will be a vague general overview. A more precise version would sound roughly like: "with a budget of 100,000 hryvnias, prioritizing video work, fan noise under load matters, the body must be metal, and I expect four years of use; suggest three options with justification." The more concrete the product description, the less the model invents on its own and the less you have to redo afterward.
Process description. How exactly to get to the result. This includes instructions like "first write a plan, then expand each point separately," or "check every number in the source before using it," or the author's life hack from the first part: "before starting, ask me every question you need to be 95% sure." Process description sets the route the model will follow to get to the result. It does not directly define the final product. If one message is not enough, dialogue begins. Sometimes it is correct to lead the model to the result step by step instead of trying to squeeze the whole task into a single request.
Performance description. How the model should generally behave in any interaction of a given type. "If you are not sure, do not guess; ask." "Do not give evaluations without a source." "Always separate the assumptions your answer is based on." These are instructions about working style and are less about a single concrete task. In the framework, this kind of description relies on directive prompting because it sets model behavior in advance. How underestimated this layer is can be seen from the data: according to the AI Fluency Index that Anthropic released at the start of 2026, only about 30% of conversations have users telling the model how exactly they want it to interact with them at all.
None of these three types reduces to "prompt engineering" in the narrow sense. Prompt engineering is most often product description and a bit of process inside a single message. Process description now more often involves something like skills. Performance description is often moved into a system prompt, project instructions, or the same CLAUDE.md/AGENTS.md discussed in the third part. In other words, a high-quality task description for repeated work almost never lives in one place. It is distributed among the message, instructions at different levels, skills, and other methods of controlling LLM behavior. Seeing Description merely as advice about prompts reduces description to one of its three layers. For those who want to improve prompting specifically, the course has a separate advanced block with six techniques, but it is deliberately presented as part of Description, not as the whole job.
Discernment
The third skill is the riskiest to skip because AI results now look so good that taking them on faith has become a temptation of its own. An obviously bad result can be seen and rejected without effort. The dangerous failure looks like this: the text is smooth, structured, literate, and the arguments sound convincing, but there is a quiet error inside. A wrong date. A distorted fact. A quote that seems to be from a source but is actually hallucinated. The text can be 95% correct, with the remaining 5% surfacing exactly when you least want it to.
Discernment is the skill of looking critically at the result as if it had been produced by a competitor. The evaluator's stance must be attentive and ready to catch anything that looks doubtful. Like description, discernment decomposes into the same three layers: product, process, and performance. The same three layers used for description are the ones used for checking. This is why description and discernment are so tightly linked.
Product discernment. "Does the result actually satisfy the task requirements?" "Is it factually accurate?" This requires at least some knowledge of the domain in which the model was working. For example, a polished text on a topic may contain claims based on sources from five years ago. Without domain knowledge, product discernment effectively does not work, and this is a separate warning we will return to.
Process discernment. "Did the model arrive at the result in the right way?" "If the model was supposed to check three sources and use fresh data, did it actually do that, or did it answer from memory and then present the answer as if it came from search?" "If we were having a dialogue, did the model keep it properly, or did it eat half the context and answer a simplified version of the question?" More complex processes bring more complex questions. With long answers, this kind of discernment is critical.
Performance discernment. "How did the model behave in the interaction itself?" "Did it answer with excessive confidence where doubt was appropriate?" "Did it swallow half the request and answer only the most convenient part?" This kind of discernment is the hardest to develop because it requires users to have some awareness of the principles of their own interaction with the model. Conceptually, though, it is simply diagnostics of the tool the user is interacting with - something like "has the knife I use to slice sausage gone dull?" or "can my computer still run modern games?"
The previous article covered an extended example of discernment. When GPT Image 2 produced the first version of the infographic, the picture looked fairly good. Colors were okay, fonts were okay, composition was okay. But there were significant flaws in the details. The first version went into the trash, the author rewrote the task description, and after several iterations the final product emerged. That is the work of discernment. But not only discernment - discernment in connection with description.
Description-Discernment loop
If description and discernment are considered separately, the most important point can be missed: in reality, they do not exist without each other. The loop is: description, checking, looking at what went wrong, refining the description, a new result, checking again.
In the AI Fluency framework this cycle is called the description-discernment loop. It sounds like the banal phrase "iterative approach," but there is an interesting observation inside it. Each iteration of description does two things at once. The obvious one: the operator fixes the wording based on what the model produced. The less obvious and more important one: the previous result tells the person something about their own task that they themselves perhaps did not know before.
A normal work situation: if you attach a table of monthly sales to Claude or ChatGPT and ask it to "analyze the dynamics and give conclusions," the first answer will come back with statements like "the best month was March, the worst was May, average growth for the year was 12 percent." After reading it, the operator may notice that what they needed was specifically an explanation of why May collapsed, not a general overview. The model could not know that because the request itself did not contain a goal at that level. So the second request will be more targeted: "focus on the May drop, check what in the data itself might explain it, and separately mark what cannot be inferred from this data at all and would require additional information." The second answer will be much more useful. The reason for success is that the first attempt showed us that we ourselves did not fully know what we were looking for.
This loop is the real form of working with a model. The idea of finding the perfect prompt almost always leads nowhere. It is more productive to spin the description-checking loop as many times as needed for the task to take its final shape. Sometimes that is two passes. Sometimes five. Sometimes the entire experiment ends with the realization that the task was framed incorrectly and returns to delegation with a new formulation. Each such cycle simultaneously teaches the operator to describe better and discern better. It is acquired only through practice, but preferably conscious practice with an understanding of the theory.
Diligence
The fourth skill is discussed least and is the hardest to develop. The right translation of the word Diligence here is broader than "carefulness" in the sense of neatness. It is the set of ethical and accountable practices around working with AI. Roughly speaking, it answers the questions "who is responsible for this result" and "how ready am I to put my own name under what the model produced?" Otherwise people either keep their distance from AI out of fear ("what if something goes wrong; better not use it") or rush to use it without discrimination ("well, if the mistake is not mine, then no big deal"). Both extremes remove the ability to act effectively. Conscious responsibility restores it because the person accepts the consequences and behaves accordingly. Diligence also decomposes into three levels.
Creation diligence. Ethical norms in the process. Awareness of possible model biases. Understanding the impact on people who will encounter the result. This also includes attention to what data the model was trained on and where systematic distortions may appear. This is the level at which it is appropriate to stop and think about whether the task being delegated to AI is ethical to delegate at all. If, for example, you automate rejection letters to job candidates, a technically simple task hides a whole set of risks that LLMs will not notice themselves - people will have to build the process very tightly at minimum.
Deployment diligence. This is the most important part in everyday work. Fact-checking, testing, validating claims before sending the result into the world. Readiness to answer for the consequences. The operator is responsible for all AI errors, because AI, for now, is not a subject of responsibility either legally or logically. The subject is the person who used the tool. Only by accepting responsibility do we get the freedom to do serious things with AI's help.
The third level, transparency diligence, is treated seriously by the framework, but in practice its weight differs depending on the domain. In academic work, the rules are strict. In work documents between colleagues, professional common sense is often enough. The specific rules depend on where and to whom the result is being delivered, and people are responsible for that too.
The authors of the framework themselves show well what Diligence looks like in real practice. The source document has a separate summary block: all texts created with Claude 3.7 were checked and edited by humans, and the authors take final responsibility for the content, accuracy, and presentation. This wording works as a ready-made working model: the tool is allowed into the process, responsibility for the result remains with the people who sign the work. The phrase "AI helped me" does not release anyone from anything; it only honestly describes the way of working.
You can start with Diligence instead of Delegation
The usual order of the four Ds puts Delegation first because it is the logical start: first decide what to delegate, then describe it, check it, publish it. But there is another sequence for people who are just starting to build their own work with AI: start with Diligence.
The logic is this. Until a person has defined their own boundaries, values, and quality criteria, all delegation decisions hang in the air. The answer to "Can I delegate work with confidential client data to AI?" depends on professional obligations and conditions. "What am I ready to put my own name under, and what am I not, even if the result is technically acceptable?" depends on personal standards and convictions. "Can I trust the model with decisions about tone in difficult communication?" depends on what "professional" means to the specific person and where they draw the line. All of these questions belong to Diligence. If there are no answers to them, delegation becomes random. People either reject AI out of fear or take everything indiscriminately. In both cases, quality suffers.
That said, not everyone has to go through this route. If the context already provides clear boundaries - corporate policy, academic rules, personal principles - you can start with Delegation. Precise advice is difficult because this is more a matter of subjective feeling.
The four skills as simultaneous layers
The previous section is a reminder that the most common mistake in learning AI Fluency is treating it as a checklist. First D1, then D2, then D3, then D4, done. It does not work that way. In real work, all four skills are active at the same time. When an operator writes a request to a model, they are simultaneously thinking about delegation (is this the right task for AI?), describing the task, preparing in advance to discern the result, and keeping in mind their own responsibility for the final output. These are parallel layers of work. Weakness in any one of them spoils the result of the others.
The perfect prompt will not save a poor delegation decision. You can spend hours polishing the wording of a task that was framed incorrectly from the start. Flawless delegation will not save a lack of checking. Irresponsibility can wipe out every result.
The framework is useful precisely because it gives language with which you can talk even to yourself about your own practice. An unsatisfactory AI interaction can be diagnosed as a failure in one of the four Ds. If the answer is "I do not know," then AI Fluency has already performed its first function: it has shown where you need to dig deeper.
Practice
The previous article suggested five steps for people who want to move beyond ordinary AI chat: find a repeated task, make a project with instructions, move repeated operations into a skill, use a safe external tool, and update instructions after each cycle.
With the framework in mind, a step zero is added to these steps: define your own boundaries and quality criteria before deciding what to delegate. This may sound like unnecessary bureaucracy, but in reality it takes fifteen minutes and looks roughly like answering a few questions: - What kinds of tasks am I willing to give AI at all? - What data must not go into external models? - How will I check the results? - How do I define that a result is good enough to use? - What am I ready to put my own name under, and what am I not, even if the model has already done everything?
You do not have to have ready answers to all of these questions immediately. It is enough to know which ones remain open and not pretend the answers exist when they do not. That is practical Diligence at the start.
The remaining steps stay the same, but now each of them can be taken with awareness of which skill is being developed at that moment. Finding a repeated task and making a project is delegation. Recording instructions in the project is description. Updating instructions after each cycle is part of the description-discernment loop. Moving a skill out and teaching the model on repeated cases is description in long-term form. Diligence is present at every step: am I keeping in mind what I am ultimately responsible for?
What the AI Fluency framework does not give
Before closing the article, it is worth being honest about the limits of a framework with such a loud claim to "AI fluency." These limitations do not make the framework less useful. They make it honest, which in an industry where every second author now sells their own "AI framework" is rare in itself.
AI Fluency is not a checklist, as noted above. You should not expect that studying the four Ds will guarantee a result. The framework gives language and structure for further thinking of your own. The same "mindset."
AI Fluency does not replace domain knowledge. The framework will not make a person who does not understand finance capable of reliably checking a model in financial analysis. Discernment requires enough knowledge of the subject to notice an error. More generally, AI is a powerful multiplier of capability where the operator already has experience.
AI Fluency does not tell you which tool to choose. Claude or ChatGPT, Cursor or Codex, local model or cloud, free tier or Pro - all these decisions lie outside the framework. The framework helps you work with any tool consciously, but it does not say which specific tool to take. This is very welcome given that the initiative is now under Anthropic's wing, yet all its points are not tied to Claude.
AI Fluency does not become a guarantee of ethicality. A person can formally study all four skills and still use AI for something dubious. Diligence in that case assumes "internal" personal and professional responsibility. External AI regulation is a separate discussion that the framework does not claim to resolve.
What next
The AI Fluency: Framework and Foundations course is completely free, open on Anthropic Academy, and released under the Creative Commons BY-NC-SA 4.0 license. This means the materials can be freely used, translated, and adapted for non-commercial purposes, with attribution and the same license preserved on derivative works, including this article.
With all that said, prompt engineering still cannot be ignored even in 2026. The four skills listed above really are more important than a good prompt, but the prompt remains the foundation of AI interaction. At the same time, users' attention is shifting to other methods of influencing AI agents' work. Context engineering is responsible for what the agent knows while doing the work. Intent engineering, so to speak, gives the agent the right desires. That is what we will discuss next time.