Feature Request: Force tool execution in agent files via pre_response_actions or knowledge_bases config

Problem

Custom sub-agents need to load external knowledge base files before responding, but there is no way to enforce this. Agent file instructions cannot force tool execution — the model bypasses them and responds directly from training.

Use case: A legal advisor agent must load a cost benchmarks file (jack-lawyer-tactics.md) before answering, to validate lawyer quotes and identify overcharging. Without guaranteed loading, the agent's core anti-hoodwink mission is unreliable.

---

What Was Tried

Four prompt engineering approaches were tested. All failed (0 tool calls in every test):

| Attempt | Approach | Result |
|---------|----------|--------|
| 1 | Procedural instruction: "MANDATORY FIRST ACTION: Read this file before responding" | 0 tool calls |
| 2 | Instruction reordering — moved protocol to top of file before agent identity | 0 tool calls |
| 3 | Chain-of-thought verbalization: required "[PROTOCOL CHECK] Step 1: Loading..." | 0 tool calls |
| 4 | Transparency workaround: required status output (LOADED / DEGRADED MODE) | 0 tool calls |

Emphasis level made no difference. Instruction position made no difference. The model pattern-matched on the query type and responded immediately, ignoring the protocol entirely.

---

Root Cause

Agent file instructions operate at the procedural instruction layer — low priority in the model's instruction hierarchy. The trained "answer immediately" behavioural pattern is system-level — high priority. Procedural instructions cannot override it without API-level enforcement.

All platforms that successfully force tool execution (OpenAI tool_choice: "required", Anthropic API tool_choice: "any", Google Vertex AI forced function calling) do so via API parameters — not prompt engineering. Claude Code agent files are prompt templates, not API configuration files. There is no access to tool_choice from the agent YAML frontmatter.

---

Current Workaround (Imperfect)

The knowledge base was embedded directly in the agent file (~6KB of cost tables and red flags). This works but:

• Knowledge is static — updates require editing the agent file
• Size is constrained — the full 30KB knowledge base cannot fit
• Multiple agents cannot share a knowledge base
• Defeats the purpose of having separate, maintainable knowledge files

---

Proposed Solution

Add pre_response_actions or knowledge_bases to agent YAML frontmatter, enabling API-level enforcement:

Option A — Pre-response actions:

---
name: jack-legal-advisor
model: opus
pre_response_actions:
  - tool: Read
    file_path: /path/to/knowledge-base.md
    required: true
---

Option B — Knowledge base auto-loading:

---
name: jack-legal-advisor
model: opus
knowledge_bases:
  - path: /path/to/knowledge-base.md
    load: always
---

Either approach would inject the file contents into context before the agent responds — equivalent to calling tool_choice: "any" at the API level.

---

Why This Matters

Knowledge-intensive agents are a core use case for custom sub-agents. Legal agents, medical research agents, product catalog agents, and policy agents all need to load current external knowledge before responding. Without guaranteed loading:

• Agents respond from training data (potentially outdated or less specific)
• There is no way to verify whether the knowledge was used
• External knowledge files are maintained but never reliably read

This feature would enable proper separation of concerns — agent logic in the agent file, knowledge in separate maintainable files — and unlock reliable, knowledge-grounded agents.

---

Environment

• Platform: Windows 11
• Claude Code: latest
• Agent file location: .claude/agents/
• Model: claude-opus-4-6