Making AI Agents More Effective Without Fine-Tuning or RAG

Things evolve so quickly in the Generative AI space that, if you're not frequently reading about it, you might miss a significant number of changes. I've noticed that not everyone is aware of, as of February 2026, the main mechanisms that you can use to "enhance" your Agentic AI usage, without having to resort to advanced topics like fine-tuning or RAG, so here is my small contribution.

What follows are some simple but powerful ways to transform your generalist agent into one or more specialized roles, while also making them work better with your specific codebases, scenarios or simply preferences.

Security note: Treat agent-readable files and scripts as untrusted input. Review any downloaded instructions or skills, avoid exposing secrets, and be cautious with tools that execute code.

Instruction files

AGENTS.md

https://agents.md/

It is a standard, adopted by almost everyone and every tool, except Anthropic.

The link explains in great detail what it is, but the TL;DR is that it is a place to write general instructions for AI agents.

They are written often in Markdown, but LLMs adapt quite well to esoteric formats. One increasingly common special case is that if you use @<path>. This signals to most Agents that they should check that file or folder path, and if it is a file, read it. We'll see a great example in the next section, but keep in mind that this now can be used from everywhere: instruction files, skills, rules, sub-agents...

One note regarding the @<path> semantic: This does not guarantee that the Agent will read it, nor that it will read it at all times. The same can happen with the general instruction files. For critical workflows, explicitly ask the agent to confirm what files it loaded to confirm.

You can also have hierarchical files, and the agents should pick the relevant ones automatically.

AGENTS.md                   -> only AGENTS.md
ios/AGENTS.md               -> root AGENTS.md + ios/Agents.md
web/AGENTS.md               -> root AGENTS.md + web/Agents.md
web/my-service-a/AGENTS.md  -> root AGENTS.md + web/Agents.md + web/my-service-a/AGENTS.md

As they will be frequently included in the session's context/memory, try to keep them as short as possible. To do so, leverage both the hierarchical support of multiple instruction files, and the other features that will be mentioned in this article.

CLAUDE.md

Anthropic's version of AGENTS.md. Predates it, but everyone else has migrated to the standard.

My advice is to have the file always present for Claude Code wherever you have an AGENTS.md file, but as a pointer to AGENTS.md. This is done by setting as the content Read @AGENTS.md, or even more succinct, @AGENTS.md.

As an alternative, you can create a symbolic link:

cd <your-repository-folder>
ln -s AGENTS.md CLAUDE.md

GEMINI.md and Others

Make all of them also pointers to @AGENTS.md, if they don't yet support directly reading the file (e.g. Gemini CLI does).

Skills (previously Slash Commands)

https://agentskills.io

Anthropic created an open standard that is being adopted by most tools: Codex, Gemini, VS Code and Cursor.

In most tools, you can invoke the skill via /<skillname>, and in all of them you can tell the agent to use it. For example, if you have a git-commit skill, you can simply tell it "examine the current unstaged changes, and commit them".

Their purpose is two-fold:

1. You offload "commands" from the instruction files, saving agent context
2. They can optionally invoke script files, which is quite powerful. That's why they are folder-based, so you can include for example Python or Bash scripts.

Rules

Cursor created the concept of rules as a way of introducing smarter custom instructions based on triggers, such as file extensions. Now Claude also supports them, so maybe others will follow. Note that Cursor has a /migrate-to-skills command for rules and commands, so it could also happen that everything converges into skills.

They are basically conditional instructions, nothing more and nothing less. So again, you save context space by not having them always included.

Subagents

If we should have the smallest instruction files as possible, how do we deal with scenarios where we want to a) parallelize multiple tasks and/or b) have different roles or personas? Subagents are the answer.

Each subagent is defined by a separate instructions file (including specifying which tools they can use), and when they run, each has its separate context window. They will also "report" to the parent main agent when their job is finished.

Claude Code's subagents seem to work great. In GitHub Copilot CLI, they work when you ask the main agent to use them; otherwise it tends to forget that they are available. And Cursor had subagents only in the nightly build until very recently, so I haven't tried them yet.

While the multiplexing aspect is very dependent on the main task, a sequenced approach is quite useful. For example, a Requirements Analyst defines user stories, your Software Architect and Testing Expert add technical details, the Python Developer builds them, and then the Testing Expert and Code Reviewer check the output and provide feedback.

Here you can go way more in detail, for example detailing specific Python patterns to follow (and to avoid), specific architecture preferences, or very concrete optimizations to apply in certain cases.

Based on my experience, the quality of the results will vary a lot depending on two factors:

1. Blank state vs existing codebase/elements
2. The quality of your subagent instructions

LLMs are amazingly good mimicking existing content. Point your testing subagent to an existing test suite that you like and ask it to use as inspiration, and it will perfectly define the same structure (e.g. more or less fixtures, naming patterns, what level of mocking to apply...). On the other hand, if you just download some amazing-fullstack-subagent-template, it might be a poor attempt, with just a few basic concepts. Review ruthlessly any downloaded instructions, remove the slop, and be in a constant state of "instructions improvement"; any time you see something you like, add to the relevant instructions' mechanism. e.g., any time your testing subagent fails to detect an edge case, add it to the list of "edge cases you should check are covered by tests".

And a final trick that as tools keep evolving might not even be needed in the future, but for now, it's quite useful: Imitate what humans do in a software company, make your subagents write things down in markdown files. In my case, only the xxx-developer subagents write code. The tester, the code reviewer, the requirements analyst... all the others write specs, plans, or whatever fancy name you want to call them ("documents"). Then they pass it to the next subagent, and that one might check the action items, or maybe create its own worklog/document, and so on. This helps a lot when a) you exhaust the context window (which will inevitably happen) or b) the subagents go bananas and begin implementing a terrible approach. You can safely stop and rollback to the previous step, and ask the subagents to try again, maybe with a tweak or some extra detail.

AI Guidance Documentation

I left this point for the end because this more of a pattern than a specific tool or feature. A fancy name that you might see this referred to as is Progressive Disclosure, but it simply is about offloading documentation out of the different instruction files (including rules and the like), towards a folder that contains one or multiple markdown files with (hopefully) descriptive names. Inside this folder, you can place LLM-optimized versions of documentation, AI-specific guidelines, and other content that previously you would have directly put in an AGENTS.md file.

As an example, in the past you might have instructions like the following inside your top-level AGENTS.md:

[...]
- To run unit tests, use `make test-unit`
- To run integration tests, use `make test-integration`
- To run end-to-end tests, use `make test-e2e`
- To run all tests, use `make test`
- To run linters, use `make lint`
- To run linters with fixing, use `make lint --autofix`
[...]

Now you can move that content to ai-guidance/testing-and-linting-commands.md, and replace those lines in the file by:

[...]
- If you want to run tests or linters, check @ai-guidance/ for instructions
[...]

You can also write it as the following, and the Agents usually pick it the same:

- If you want to run tests or linters, check the `ai-guidance/` folder for instructions

Conclusion

I didn't mean for this list to be exhaustive, nor to cover more complex workflows that others have created. That said, if you know of more simple tricks that could be good additions for the article, please let me know!