The more independent an agent becomes, the more you notice the cost of old instructions. A multi-page AGENTS.md, dozens of skills with vague descriptions and mandatory reading of half the repository may fail to improve quality and instead eat up context and get in the way of the model choosing the right next step.
With the release of GPT-6 Astra, OpenAI advises rethinking the usual prompting practice: a strong model doesn’t need every turn described to it. It needs a clear environment in which it’s easy to find the relevant knowledge, make a decision safely and carry the work through to a verifiable result.
Skills should be routers, not encyclopaedias
A skill is usually kept in a Markdown file and describes a repeatable workflow: a database migration, a deploy, working with a specific API, preparing a document or an internal procedure. It’s a useful format as long as the skill helps at the right moment rather than loading on any word match.
The trouble starts with descriptions that try to cover every neighbouring area. For example, the phrase “use when working with databases, queries, models or storage” will nudge the agent to open the skill even for a small tweak to an SQL query. The context ends up full of instructions that have nothing to do with the task.
A description with a precise boundary is far more useful: “use when adding or changing a migration, and when checking its rollout plan”. It doesn’t recount the whole content of the skill, but it answers the question well: when to open it.
This is an important shift in thinking. A skill description shouldn’t be advertising copy with as many keywords as possible. Its job is like good routing: lead the agent to the right instruction, and not lead it there without a reason.
Progressive disclosure saves context for the work
OpenAI singles out progressive disclosure: revealing details step by step. A big skill can have lots of scenarios, exceptions, commands, examples and historical decisions. Loading all of them for one small edit makes no sense.
A working structure looks like this:
- the root
SKILL.mdbriefly explains the purpose and the entry points; - specific scenarios live in separate files;
- repeatable mechanics move into scripts;
- the agent reads only the branch that relates to the current task.
This approach doesn’t mean “hiding knowledge”. On the contrary, knowledge becomes more accessible because it’s easier to find and apply. The model doesn’t spend attention on deploy rules when it’s fixing a typo, and doesn’t read database documentation when it’s changing interface copy. We covered how unnecessary context costs money and eats into usage limits in the token-saving checklist.
For teams it’s also a way to reduce contradictions. The more instructions are loaded at once, the higher the chance that two of them describe priorities differently or demand unnecessary actions.
AGENTS.md shouldn’t be a warehouse of old anxieties
AGENTS.md is especially important because it applies to almost every task in the repository. That’s why traces of past problems get into it so easily: prohibitions, mandatory reading, long checklists and requirements written for older generations of models.
A typical bad example: requiring the agent to open the architecture document, the database description and the deploy instructions before every change. For a one-line change this adds needless delay and eats context. Instead it’s more useful to give navigation: the architecture document is needed for service boundaries, the database documentation when the schema changes, and the deploy rules when preparing a release.
The difference isn’t a formality. The first option makes the agent follow a fixed template; the second helps it work out what really relates to the current task.
Strong models already understand better what information they need. So a good AGENTS.md today should be a map of the project and a set of clear boundaries, not an attempt to replace the model’s ability to reason. What’s worth putting into an agent’s context at all, and what to keep out, is covered in the piece on context engineering.
Decision boundaries matter more than blanket bans
Once an agent has done too much without permission, the team’s natural reaction is to add a hard rule: “do nothing without confirmation”. That may protect against risk, but at the same time it stops safe work the agent could have finished on its own.
Instead of a blanket, anxious rule, it’s more useful to describe the real decision boundaries:
- which actions are safe to perform locally;
- when approval is required;
- what counts as production, money, data or external communications;
- which checks the agent may run itself;
- where it must stop and show the result to a human.
For example, you can explicitly allow local tests on disposable fixtures to be run and rerun while the agent fixes a bug within the task it was given. Changing production data, publishing a post or sending a message to a client, on the other hand, remain separate actions that need confirmation.
This approach doesn’t weaken security. It makes it understandable for both the model and the human: the agent doesn’t ask permission for every harmless step, but doesn’t cross the line where the cost of a mistake is high.
Define done before the work starts
OpenAI notes one more trait: Astra can be thorough, yet come back for review right after the first implementation. If the task should end with a working, verified result, that’s worth saying explicitly.
The phrase “add authorisation” leaves a lot of room for interpretation. The agent might write the code and stop. The wording “add authorisation, run the local scenario, check the main flow, fix any errors you find and run the affected tests” sets a more useful finish line.
There’s no need to turn the task into a step-by-step instruction with a hundred points. It’s more important to name the criterion for done: what should work, how to check it and at what point it’s really time to come back to the human.
This is especially useful for agentic tasks, where “the first working version” and “finished work” are different states. The second includes running it, checking it, fixing breakages and a clear report on the result.
What you can check in your own instructions right now
A new model is a good reason not to rewrite everything from scratch, but to run a short audit.
- Look at your skills’ descriptions. Is it clear from one line in which situation the skill is needed?
- Split bulky instructions into a short router and detailed branches by scenario.
- Remove “just in case” mandatory reading from
AGENTS.md. - Revisit prohibitions that appeared because of quirks of older models. Do they protect against real risk or just stop the work?
- For typical tasks, define what counts as done: code, a run, tests, a check of the result, a report.
The main takeaway isn’t that prompts and skills are no longer needed. They are, but their role is changing. They often used to serve as crutches for the model. Now they’re decision-making infrastructure: compact pointers, relevant context, clear boundaries and a verifiable end to the task.
Conclusion
A strong agent doesn’t become more useful from having as many rules as possible. It becomes more useful when it can quickly tell what matters from the background, understands the limits of its authority and knows the work isn’t finished until the result has been checked.
So when moving to new models it’s worth asking not only “what can they do”. An equally important question: which instructions are we still carrying around from the days when an agent had to have every step explained?
