Support modular, file-based agent definitions in the Toolkit (skills + Python tools)

Summary

The Cognite Toolkit forces an agent to be defined as a single monolithic YAML file — config (name, id, description, LLM), instructions, the skills list (external IDs to pre-existing skills), and tools (including inline Python source) all in one file. We need a modular, file-structure-based agent definition that the toolkit parses at deploy time, so skills and Python tools can live as standalone, testable, version-controlled source files that are created and attached to the agent automatically on deploy.

Pain points

The monolithic YAML blocks normal DevOps practice (isolation, unit tests, review, reuse). Concretely:

• Skills cannot be deployed from source. A skill should be an isolated directory containing a SKILL.md (possibly other supporting files as well, as per the emerging standard). But the toolkit references a skill only by external ID — the skill must already exist in CDF. There is no way to point the toolkit at a SKILL.md and have it create and attach the skill on the fly during deploy.
• Python tool code is trapped inline. Executable Python tools embed their source directly in the agent YAML, so the code cannot be unit-tested or run standalone during development. Functions already support a modular layout — a directory with utilities/supporting Python files that gets packaged on deploy — and Python tools should work the same way.

My opinion is that you need to keep these things in mind whenever you introduce new features. We as the users need to be enabled to use workflows that follow best practices. Devops should not be an afterthought, but be baked in from the start.