v0.2.77
v0.2.77 — Per-agent skill allowlist
Agent skill access is now governed by an explicit per-agent skillBindings allowlist instead of the previous implicit "all org skills visible to every agent" default. Operators choose which skills each agent can read via a new SkillSelector in the agent editor's Tools tab; agents with no bindings see no skills, no expand_skill tool, and no "Available Skills" prompt section.
💥 Breaking Changes
- Agents no longer inherit every uploaded org skill by default.
skillBindingson the agent config is now a hard allowlist — empty or absent means the agent has zero skills at runtime (noexpand_skilltool registration, no skill disk reads at turn start, no "Available Skills" prompt section). Existing agents will see zero skills until an operator opens each one and binds the skills it needs; there is no automatic backfill. (#1742)
🚀 Features
- New SkillSelector in the agent editor's Tools tab, matching the existing tool/integration/workflow binding patterns, with full en/de/fr translations and a dedicated
agents/$agentId/skillsroute. (#1742) buildSkillContextnow intersects bound slugs with the org's actual skill directory and silently drops stale bindings, so renaming or deleting a skill on disk no longer breaks agents that referenced it. (#1742)
Upgrade
Run tale upgrade to update the CLI, then tale deploy to apply the new version.
Migration Guide
After upgrading, every existing agent will start with an empty skill allowlist. For each agent that should keep using skills:
- Open the agent in the platform UI.
- Go to the Tools tab.
- In the Skills section, select the skills the agent should have access to.
- Save.
No data migration, schema change, or CLI command is required — the binding lives in the agent config and is applied on the next chat turn.
Contributors
Full Changelog: v0.2.76...v0.2.77