Description
AgentSkillsProvider injects a concrete fictional resource path into the model's system instructions:
- Use `read_skill_resource` to read any referenced resources, using the name exactly as listed
(e.g. `"style-guide"` not `"style-guide.md"`, `"references/FAQ.md"` not `"FAQ.md"`).
In repeated .NET agent runs, the model sometimes interprets references/FAQ.md as an available resource after loading a skill, even though that skill neither references nor contains that file. It then calls read_skill_resource with the example path and receives a missing-resource error.
This occurred across unrelated skills, indicating that the framework-generated system instruction is the common primer rather than any individual SKILL.md.
Expected behavior
Framework instructions should not introduce fictional resource names. They should direct the model to:
- Read only resources explicitly referenced by the loaded skill.
- Pass the resource path exactly as written.
- Never infer or guess resource paths.
Steps to reproduce
- Configure AgentSkillsProvider with skills that enable resource support.
- Include a skill that does not reference or contain references/FAQ.md.
- Run a task that loads that skill and may benefit from supporting resources.
- Inspect the model's tool calls.
Depending on model sampling, it may copy references/FAQ.md from the system prompt into a read_skill_resource call.
The model behavior is nondeterministic, but the ungrounded concrete path is deterministically included in every generated prompt when resource instructions are enabled.
Code Sample
var skillsProvider = new AgentSkillsProvider(skillsPath);
// The generated system prompt advertises the fictional path:
// references/FAQ.md
// Observed model-generated call:
// read_skill_resource(
// skillName: "some-unrelated-skill",
// resourceName: "references/FAQ.md")
Error Messages / Stack Traces
Error: Resource 'references/FAQ.md' not found in skill 'some-unrelated-skill'.
Package Versions
Microsoft.Agents.AI: 1.2.0
.NET Version
.NET 10
Additional Context
The same concrete example currently appears in both implementations:
dotnet/src/Microsoft.Agents.AI/Skills/AgentSkillsProvider.cs
python/packages/core/agent_framework/_skills.py
This is distinct from #7008 / #7031. Those fixed the Python example incorrectly dropping the .md extension. The remaining problem is that any concrete fictional resource name in executable model instructions can be mistaken for an actually available resource.
A safer rule-only instruction would be:
Use `read_skill_resource` only for a resource explicitly referenced by the loaded skill.
Pass its resource path exactly as written in that skill.
Never infer or guess resource paths.
Description
AgentSkillsProviderinjects a concrete fictional resource path into the model's system instructions:In repeated .NET agent runs, the model sometimes interprets references/FAQ.md as an available resource after loading a skill, even though that skill neither references nor contains that file. It then calls read_skill_resource with the example path and receives a missing-resource error.
This occurred across unrelated skills, indicating that the framework-generated system instruction is the common primer rather than any individual SKILL.md.
Expected behavior
Framework instructions should not introduce fictional resource names. They should direct the model to:
Steps to reproduce
Depending on model sampling, it may copy references/FAQ.md from the system prompt into a read_skill_resource call.
The model behavior is nondeterministic, but the ungrounded concrete path is deterministically included in every generated prompt when resource instructions are enabled.
Code Sample
Error Messages / Stack Traces
Package Versions
Microsoft.Agents.AI: 1.2.0
.NET Version
.NET 10
Additional Context
The same concrete example currently appears in both implementations:
dotnet/src/Microsoft.Agents.AI/Skills/AgentSkillsProvider.cspython/packages/core/agent_framework/_skills.pyThis is distinct from #7008 / #7031. Those fixed the Python example incorrectly dropping the
.mdextension. The remaining problem is that any concrete fictional resource name in executable model instructions can be mistaken for an actually available resource.A safer rule-only instruction would be: