feat(agents): declarative tool catalog + per-agent tool allowlist (#51) - #59
Merged
Conversation
First slice of opening PAGS to third-party creators (#58): make the tool vocabulary DATA instead of a hardcoded per-surface switch. - Expose the tool groups as a catalog (TOOL_CATALOG + CREATOR_SELECTABLE_TOOLS) so the authoring UI (#55) and pre-review scanner (#54) can enumerate what an agent may do. Deliberately excludes permission-gated find_confirmation_link and the legacy submit_job_application. - AgentCapabilities gains a declared `tools[]` allowlist (sanitizeToolList). When present it is authoritative: the agent gets exactly those catalog tools plus the universal BASE facilities — replacing the per-surface default. - toolNamesFor honors the allowlist; absent → today's surface-derived behavior is unchanged, so no existing agent is affected (fully backward-compatible). 680 workers/api tests pass. Next in #51: migrate repo-chat to declare its tools as data (dogfood), then the formal declarative agent schema. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
This was referenced Aug 1, 2026
5 tasks
serge-ivo
pushed a commit
that referenced
this pull request
Aug 1, 2026
) sanitizeAgentDefinition / AgentDefinition had zero non-test consumers — built as a "pure library, wiring deferred to the next PR" that never came. The lead-finder (and every agent so far) is a standalone worker or a config chat agent; nothing consumes the declarative definition. Removed agent-definition.{ts,test.ts} plus the helpers added solely for it (sanitizeDeclaredCapabilities, DeclaredCapabilities, KNOWN_RUNTIMES, KNOWN_WORKFLOWS). KEPT (live): the tool catalog + capabilities.tools allowlist (PR #59) — repo-chat uses it via migration 0050 through toolNamesFor. Recoverable from PR #62 history if/when the create/update wiring is actually built. 715 workers/api tests pass; typecheck clean.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
First slice of the open-to-third-party program (epic #58, workstream #51).
Why
The agent tool vocabulary is currently implied by a hardcoded per-surface
switchintoolNamesFor(repo→KB-read, coding→coding, else everything). A third-party creator can't scope an agent's tools without a platform code change. This makes the vocabulary data.What
TOOL_CATALOG(groups + tier) +CREATOR_SELECTABLE_TOOLS, exported so the future authoring UI ([3P] Creator experience: onboarding + authoring UI + Coder flywheel #55) and pre-review safety scanner ([3P] Automated pre-review safety scanning #54) can enumerate what an agent may do. Excludes the permission-gatedfind_confirmation_linkand the legacysubmit_job_application.AgentCapabilities.tools?: string[](validated bysanitizeToolList). When present it's authoritative: the agent gets exactly those catalog tools plus the universal BASE facilities (memory/tasks/fetch/context), replacing the per-surface default.toolNamesForhonors the allowlist; absent → behavior is identical to today, so no existing agent changes.Safety / compatibility
toolsyet, so every current agent resolves exactly as before.Tests
agent-do-tools.test.ts(allowlist precedence, override-vs-surface, ungrantable-names ignored, empty-list fallback, catalog shape) andagent-capabilities.test.ts(toolsresolution both paths,sanitizeToolListdedupe/cap/junk).workers/apitests pass.Next in #51
Dogfood by migrating
repo-chatto declare its tools as data (replacing its surface special-case), then the formal declarative agent schema.Part of #58.