Business Skills for AI Agents

It is 2026. Neural networks write almost all the code, and programmers are being promised a swift extinction. I barely write code myself these days either, but that has not put me out of work. Quite the opposite: I used to spend most of my time doing something I was comfortable with - writing and refactoring code. Now the useful part of my workload has shifted toward business analysis, where every task makes me properly strain my brain.

Code review now takes the time that writing code used to take. On pet projects, you can get away without reviewing anything - who cares how it works if it makes no money and you are the only user? But with a commercial product, where you are merely a hired hand, responsibility for the code does not disappear. When things go wrong, they will fire the human, not the neural network.

So review is unavoidable, but how do we reduce the cognitive load? How do we get rid of the routine and actually move from babysitting agents to being business analysts, or something like that?

Finding the root of the problem

What is the most obvious way to reduce the time spent on reviews and fixes? Delegate the review and fixes to another agent? No, that road leads straight to hell, because you lose control. The right move is to teach the agent to write code and make decisions as if it were you.

Every mature project has its quirks, for example:

the codebase is imperfect, with compromises that had to be made
the architecture differs significantly from the examples the models were trained on
commands such as tests or builds have their own peculiar way of being run
the project uses custom packages and libraries the model knows nothing about
and so on

This gap between the model’s basic knowledge and the real project is what creates all that routine later: the agent runs the wrong thing, puts classes in the wrong place, and comes up with awkward names. You then have to fix it by hand or write yet another list of corrections.

The evolution of tooling and instructions

The obvious solution is to describe all these quirks once instead of repeating yourself every time. At first, people used system prompts and various personalization fields injected into every session. But as harnesses and coding agents evolved, those instructions moved into AGENTS.md.

The AGENTS.md file became the main dumping ground for agent rules: code formatting, architecture, tool usage, and assorted business rules all went in there. The convenient part is that the agent reads the file at the start of every session, so you can bundle all your expectations into it and stop repeating yourself. But once the file grows, it starts eating more and more context, the results become pretty meh, and the cost goes up.

Say the model only needs to fix a button, but AGENTS.md loads the entire 200k-token knowledge dump about the project along with it. Nothing good will come of that. The obvious next step is to split the knowledge into small pieces and load them only when needed.

And so AGENTS.md started turning from a dumping ground into a short index. The documentation and expectations lived somewhere else, for example in docs/ or even .agents/docs/, while the index merely listed the available files and explained when to read each one. Sound familiar? Yes, this pattern stuck around and was later formalized as the Skills standard.

Technical Skills

Skills are knowledge packaged into separate parts: always available, but loaded only when needed.

A skill usually lives in .agents/skills/{skill}/ (Codex also supports .codex/skills/{skill}/) and has a main Markdown file called SKILL.md. Its YAML frontmatter contains the required name and description fields, followed by the instruction body. Optional references/, scripts/, and assets/ directories can sit alongside it. You can find the full specification here.

For example, you can explain once how to connect to a remote server and run the required script, then ask the agent to turn that process into a skill. It will package the command sequence, details about what lives where on the server, and instructions for running it into a small file for future sessions. A minimal version might look like this:

---
name: deploy
description: Use when you need to run deployment on the remote server.
---
Connect to the server, pull the latest changes and run the deployment script:
`ssh user@yourhost 'cd /home/user/repo && git pull && ./scripts/deploy.sh'`

Or perhaps your project has complicated infrastructure: everything is wrapped in Docker, and tests must run inside a container. Without that knowledge, the agent will try the local interpreter every time and rediscover the same problem every time. Explain the correct steps once, ask the agent to turn them into a skill, and that particular piece of routine disappears for good.

What belongs in technical skills? First of all, everything related to tooling and infrastructure: tests, builds, linting, and perhaps working with a debugger. It is also incredibly useful when the agent has access to the error tracker and task tracker. In general, every tool you need is a tool your agent needs too.

The same applies to all the little quirks and edge cases. Perhaps the database is obscenely huge, and you cannot casually run select * from events without bringing everything to a halt. The agent needs to know that. The best place for this knowledge is a database skill: how to connect, how to run queries, where to put backups, how to import a file, and which operations are forbidden.

Architecture and code-style Skills

Linters handle some code-style rules, but you may also have preferences about what the code should look like so it is easy to review. For that, you can create a skill describing your preferred constructs, for example:

- use fail-fast principle instead of nested if-else statements:

if ($something) {
    return false;
}

- extract complicated conditions from "if" statements into something human-readable:

$isApplicable = $something && $anotherThing && $yetAnotherThing;

if ($isApplicable) {
    return true;
}

- never use dynamic method calls, e.g. $model->{$method}()

- never use dynamic class names, e.g. $class = "MyClass"; $obj = new $class();

Such a skill should make code simpler - the simpler the code, the easier it is to read and understand. A review should feel like reading a light book. Clever but obscure techniques and unpredictable magic are sacrificed in favor of simplicity and predictability.

An architecture skill sets broader rules, for example:

namespaces, domains, and what belongs where
expectations for splitting logic between large services and atomic actions
whether empty layers should be preserved or simplified whenever possible

Okay, suppose we have described all our code-generation preferences and created something like a junior developer, perhaps even a mid-level one, capable of handling basic tasks and small fixes. But how do we turn it into a senior? The kind of agent you can actually consult while designing a feature. What is missing? Business knowledge.

Why should a coding agent understand the business?

This is where things get interesting, and very few people are writing about it yet. Suppose we have eliminated the routine and handed all the manual busywork and minor fixes to agents. Simple tasks like “add a filter to the admin panel” or “adjust the columns in the report” can go straight to an agent.

But more complicated tasks like “add an admin section for importing products from third-party suppliers” require knowledge that is not reflected in the code, for example:

who are these “third-party suppliers”?
what pricing rules apply to them?
what file types can be imported? What does their internal structure look like?
which user roles should have access to this section? And so on.

A developer who has been on the project for a long time understands the task immediately: they know how the office operates and already have the answers to these questions. The agent knows nothing about this business process. And so the routine returns at another level: you have to explain exactly what to build, what form it should take, what the result should be, which files contain relevant examples, and so on.

At best, the agent can walk through the files, find the relevant places, and try to reconstruct the real office processes from vague and mysterious rules and conditions. First, this is inefficient: without a source of truth, the agent must reconstruct the same meaning again and again. Second, there is no guarantee it will imagine those processes the same way next time. Most importantly, if the code is the source of truth, the code becomes untouchable: the agent will preserve existing logic even when a new task implicitly allows that logic to be simplified or changed. That is how you end up with branches for “backward compatibility” where no backward compatibility is needed.

Ideally, the agent should have a clear picture of how customers use the application, how the office works with the admin panel, which non-obvious scenarios exist, and all the rest. Skills are a great fit here too.

Business Skills and how to design them

Technical skills are simple - show the agent the steps once, and the skill is done. Packaging business knowledge into a skill takes more thought. This is not a sequence of actions but a collection of process descriptions, terms, edge cases, and real-world entities. So how do we structure it?

Let us start with how an agent selects skills. The agent sees a short description along the lines of “use this skill for X.” This description acts as a hook or trigger for the model, so it needs keywords that clearly define the boundaries of the knowledge inside. If the description is too abstract or unclear, the agent will dismiss the skill as irrelevant. If it is too broad, the agent will load it even when it should not.

This is roughly the same problem we face in software architecture: knowledge must be split into atomic parts with a nested structure and a clear entry point. The exact structure depends on the project. For example, you can organize knowledge by feature if there are only a few features and the processes behind them do not overlap much. Or you can organize it by area, such as the admin side and the customer side. That works well for ecommerce applications, where customers and managers use different parts of the product.

The key rule is to start from real processes:

a customer selects products and makes a purchase
managers process the order
an admin imports products, and so on

For a typical ecommerce application, we can start with this structure:

./agents/skills/business-catalog/SKILL.md
./agents/skills/business-purchases/SKILL.md
./agents/skills/business-fulfillment/SKILL.md

business-catalog contains everything related to how users search for and select products: how filters work, how products are ranked, how prices are displayed, what matters on the product page, and so on.

business-purchases contains everything related to purchasing: payment methods, types of discount codes, how discounts are applied, how vouchers work, which analytics events should fire, and so on.

business-fulfillment packages the processes around created orders: order statuses and the processes behind them, transitions between statuses, notifications sent to the user, order cancellation, returns, and so on.

Each of these skills can be split into smaller documents. For example, business-fulfillment can have a separate document for cancellation, returns, completion, and other processes:

./agents/skills/business-fulfillment/references/cancel-order/SKILL.md
./agents/skills/business-fulfillment/references/return-order/SKILL.md
./agents/skills/business-fulfillment/references/complete-order/SKILL.md

The main business-fulfillment/SKILL.md file would then link to those documents:

- Read `./references/cancel-order.md` for cancellation process details
- Read `./references/return-order.md` for return and refund workflows
- Read `./references/complete-order.md` for order completion details

Yes, this looks a lot like where we started - splitting an overgrown AGENTS.md into smaller documents. And yes, in a sense this is now part of a developer’s or business analyst’s job: documenting terms, business rules, statuses, the purpose of pages and buttons, expected behavior, special flags in models, and everything else. I would not be surprised if IT teams eventually create a dedicated role for this alone.

Best Practices for Business Skills

All I have are Captain Obvious tips along the lines of “do things well, do not do them badly.” But this is a new field, and there simply are no better rules yet:

Do not overcomplicate things too early. Start with a single flat index inside the skill; artificial grouping only gets in the way at this stage.
If one document grows beyond roughly 4,000 characters, consider splitting it into child documents.
The main rule for splitting is simple: if the agent loads this entire file, how likely is it to need all the information inside?
Add cross-references. A convenient structure for an agent is a well-connected graph. A clean hierarchy mainly matters to humans, so do not obsess over it.
Watch which skills and documents the agent loads while working. Reading irrelevant documents or skipping relevant ones means the descriptions need work.

The truly unhinged can try building a special skill that makes the agent create and split business skills by itself. For example, you could throw a meeting transcript at it and let it extract the business rules and put everything somewhere. But that is an entirely different level of ~~laziness~~ mastery, and the odds of getting a garbage dump out the other end are much higher.

To keep it from turning into a garbage dump, you can borrow ideas from garrytan/gbrain. One good approach is to preserve immutable source material from chats, meetings, and descriptions, then synthesize business skills from those sources. If the model invents something, you can at least verify it against the originals.

Development is not going anywhere

Developers have gone from fleshy typing machines to puppet masters for agents. We used to group and structure code, refactor it, design architecture, and think about how different parts of an application interact and pass data around. Neural networks now handle that thinking, but a new and fairly difficult engineering task has emerged: designing skills, configuring tools, and setting up the agents themselves. Development has moved to another plane, but it has not gone anywhere.

And that is interesting. It is a new field for research and experimentation.