Tools change every quarter. The capabilities a regulated team needs change much more slowly. This chapter starts from capability and control requirements, gives a repeatable way to evaluate any AI tool, and only then maps the concepts onto two coding agents as dated, non-exhaustive examples. Durations and counts on this page are illustrative.
The discipline is portable; the tool is replaceable.
1. Capability first
Write down what the team needs before anyone looks at a product page. A requirement names a capability and the control around it, not a feature name.
| Capability | Control requirement that comes with it |
|---|---|
| Shared team context | Instructions live in the repository, are reviewed like code, and load the same way for every user |
| Reusable prompts and skills | Versioned, owned, and listed in the asset catalog |
| Tool access | Least privilege per task; tool servers approved like any other integration; actions logged |
| Hooks and policy | Organization-managed policy that a user cannot switch off; local hooks treated as advisory |
| Delegated work | Output always lands as a reviewable artifact (a pull request (PR), ticket or document) for a human approver |
| Model choice | Only models approved for the data class; administrators control which models are enabled |
| Evidence | Traces and audit events exported to the evidence system of record with defined retention |
| Data handling | Contracted terms for retention, training use and residency that match the data classification |
2. The evaluation method
A tool evaluation is a repeatable decision, not a demo. Every step has a question, the evidence that answers it, and a gate owner who can stop the evaluation.
| Step | Question | Evidence | Gate owner |
|---|---|---|---|
| 1 · Requirements | Which capabilities and controls do we need, for which roles and risk tiers? | Requirements list from section 1, ranked; intake cards for the target use cases | Enablement lead with the business owner |
| 2 · Security gate | Can the tool meet our access, logging, network and secrets rules? | Security questionnaire; architecture review; threat model incl. prompt injection and excessive agency | Security |
| 3 · Privacy gate | What data reaches the provider, where is it kept, and for how long? | Data flow diagram; privacy impact assessment; residency and retention terms | Privacy office |
| 4 · Legal gate | Who owns outputs, what are the licence and indemnity terms? | Contract review; intellectual property and open-source licence position | Legal |
| 5 · Third-party gate | Is the vendor acceptable under third-party risk management (TPRM)? | Vendor risk assessment; sub-processor list; continuity plan | Procurement and third-party risk |
| 6 · Representative benchmark | Does it do our tasks well, on our code and documents? | 20 to 50 tasks (illustrative) from the real backlog, scored against an evaluation set with negative test cases | Quality assurance (QA) lead with the team lead |
| 7 · Total cost | What does it cost per useful outcome, including review time? | Licence and usage cost; platform cost; reviewer hours per accepted output; evaluation upkeep | Finance with the enablement lead |
| 8 · Integration and operations | Does it fit identity, repositories, CI (continuous integration), logging and support? | Integration test; single sign-on and provisioning check; support model; incident contact | Platform owner |
| 9 · Accessibility | Can every user on the team use it, including with assistive technology? | Accessibility conformance report; test with real assistive technology users | Accessibility lead |
| 10 · Portability and exit | Can we leave without losing our context, prompts and evidence? | Where instructions, prompts and skills are stored; open formats; export of traces and audit logs | Architecture |
| 11 · Provider change handling | How are we told about model or feature changes, and how fast can we re-evaluate? | Change notice terms; version pinning options; re-run of the benchmark after a change | AI or model risk |
| 12 · Pilot design | What does a fair pilot look like, and what ends it? | Pilot plan: team, tasks, baseline, metrics from chapter 10, stop criteria, duration | Enablement lead |
| 13 · Recommendation with expiry | What do we recommend, for which tiers, and until when? | Tool evaluation decision record with scope, conditions and an expiry date | Decision owner named in the leader decision brief |
Benchmark rules. Use tasks from the real backlog, not vendor samples. Include tasks the tool should refuse or abstain on. Score blind where possible, and include the reviewer's time in every score.
Expiry is required. A recommendation lapses after a fixed period (for example, 12 months, illustrative) or at once after a material change in the tool, the model or the contract.
3. Concept map for coding agents
The same concepts appear in most coding agents under different names. The table maps them for two widely used tools. It is an example, not an endorsement and not a complete list.
Last verified 2026-10-29 — check current vendor documentation and your contracted configuration. Features, names and availability differ by plan, by administrator settings and over time.
| Concept | Generic description | Claude Code | GitHub Copilot |
|---|---|---|---|
| Repository instructions file | A file in the repository that gives the agent the team's rules and context on every task | CLAUDE.md | .github/copilot-instructions.md; path-scoped *.instructions.md files; AGENTS.md; can also read CLAUDE.md |
| Reusable prompts | A named, versioned prompt a user runs on demand | Custom slash commands | Prompt files in .github/prompts/*.prompt.md |
| Skills | A packaged set of instructions and resources the agent loads when a task needs it | Agent skills defined in SKILL.md | Agent skills defined in SKILL.md |
| Custom agents | A specialised agent with its own instructions and tool set | Subagents in .claude/agents | Custom agents in .github/agents/*.agent.md |
| Hooks and policy | Code that runs at fixed points in the agent's work to check, block or log an action | Hooks such as PreToolUse, PostToolUse and UserPromptSubmit, configured in settings | Copilot command-line tool: preToolUse and postToolUse hooks, plus administrator-managed policy hooks |
| Tool servers (MCP) | Approved external tools reached through the Model Context Protocol (MCP) | .mcp.json | .vscode/mcp.json; MCP servers configured per custom agent |
| Terminal agent | An agent that works in the developer's terminal, reading files and running commands | Claude Code command-line tool | Copilot command-line tool, generally available February 2026, with plan and autopilot modes |
| Background agent to pull request | An agent that works on a task without a live user and returns a PR for review | Headless and CI usage of the command-line tool | Copilot coding agent: assign an issue, and it opens a PR using GitHub Actions |
| Model choice under admin policy | Which models a user may pick, controlled by administrators | Claude models; enterprise managed settings | Model picker that can include Anthropic, OpenAI and Google models, enabled by administrators |
Reading the map. The same control can sit at different enforcement points in different tools. Repository and user-local hooks can be bypassed and should not be the sole release control. Administrator policy hooks can enforce workstation actions where supported; CI (continuous integration) and branch protection independently enforce what may merge (chapter 7).
Official sources checked (2026-10-29).
- Claude Code docs
- Claude Code hooks
- Claude Code subagents
- GitHub Copilot CLI general availability
- Copilot custom agents
- Copilot hooks reference
- Copilot AGENTS.md support
What portability means here. Keep the substance in plain files the team owns: rules, prompts, skills, hook logic and evaluation sets. If the tool changes, the files move; only the file names and wiring change.
4. The business side
Not every use case needs a coding agent. Business teams have other tool categories, each with its own fit and its own controls. Product names are left out on purpose; categories change more slowly than products.
| Category | Good fit | Poor fit | Key controls |
|---|---|---|---|
| Low-code agent builders | Internal assistants over approved documents, with citations; simple drafting helpers | Consequential actions; logic that must be exact every time | Connector approval; data classification per source; evaluation set; owner per agent |
| Workflow automation | Multi-step processes with clear rules and a human approval step; routing and notifications | Decisions that need judgment the rules cannot capture | Approval gates; least-privilege service accounts; run logs; failure alerts |
| RPA (robotic process automation) | Repetitive screen-based tasks on systems without an API (application programming interface) | Processes that change often; tasks where an API exists | Credential vault; change control on bots; monitoring for silent failures |
| Managed enterprise platforms | Organization-wide assistants and agents with central administration, logging and model choice | Teams that need deep repository-level context | Tenant configuration; retention and residency settings; administrator policy |
| Open-source and self-hosted | Strict data residency; full control of models and logs; custom evaluation | Teams without the people to run, patch and monitor it | Patch and vulnerability management; model provenance; licence review |
| No suitable tool | A valid outcome: the need is real but no tool meets the controls yet | Never a reason to allow unapproved tools | Record the gap; fix the process or use deterministic code; revisit at the next review |
When the answer is no tool. Some needs are better met by deterministic code, a shared library or a process change (chapter 4). In the due-date example, the main fix was adopting shared-datetime, not buying anything.