Reasoned Tool Selection

1. Status

This is a living document, same as every paper in this series. It states current practice, it will be revised out loud when practice teaches otherwise, and nothing here should be read as a permanent ranking of tools against each other. It's a description of how a choice gets made, not a scorecard for which choice wins.

2. Motivation

This project has, at this point, a real number of ways to get work done: a native AskUserQuestion prompt, a tracked multi-session /architect-action interview, a published /architect-action-extended voting artifact, a same-session /loop, an in-memory CronCreate reminder, a cloud-hosted /schedule routine, a bounded multi-agent Workflow fan-out, a long-running daemon with a PID lock — and, underneath all of it, actual AWS infrastructure (EventBridge rules, scoped-IAM Lambdas) that no chat-facing mechanism touches at all. Paper 1's P5 already named one instance of the underlying problem for loop tiers specifically: "pick the narrowest tier that actually fits." That instinct turns out not to be special to loops. It's a general one.

The failure this paper exists to prevent isn't "used the wrong tool and it broke." Most of these mechanisms are competent enough that reaching for a bigger one than the job needs usually still works, technically — which is exactly what makes it a sneaky failure. Reaching for /architect-action-extended when one AskUserQuestion would do doesn't error out; it just costs more owner attention than the decision was worth — and owner attention, per Paper 2's core claim, is this project's actual scarce resource, not headcount. Reaching for a /schedule cloud routine for something that needed real AWS credentials doesn't error out cleanly either — it quietly can't do the one thing that mattered, and that's only found by checking, not by assuming from how capable the tool sounds.

3. Core Thesis

Reasoned tool selection is this project's name for making the mechanism choice deliberately, against the actual shape of the work, instead of defaulting to whichever available tool is most powerful, most familiar, or most recently used. This project already runs two separate, documented decision tables that are instances of the same underlying discipline, not competitors with each other:

A naming note, since this series already has one "five" in it: the five-tier table above answers which mechanism runs repeated or unattended work. It is not the same five as Paper 3's five-phase loop shape (vision intake, iteration body, check, branch, gate), which answers what happens inside whichever tier gets picked. Every row in this paper's five-tier table still runs Paper 3's five phases internally — this table is about the container, Paper 3 is about what the container holds.

Neither table is an escalation ladder where the bottom row is "for beginners." Both are shape-matching tables: the right row is the one whose fit matches the work in front of it, and the wrong row is wrong in either direction — reaching too high costs attention it didn't need to spend; reaching too low fails to actually cover what the work required.

4. Principles

5. Worked Example

This one's real and it's recent, and it's the reason this paper exists instead of staying a one-line footnote on Paper 1's P5.

A backend ops-checks effort needed a way to run recurring health checks — the kind of thing /schedule (§12a's "scheduled routine" tier) exists for: cloud-hosted, survives session end, no open terminal required. On naming and surface shape alone, that looked like a clean fit. Checking it against T3 before committing surfaced the actual constraint: /schedule's cloud sandbox has no access to this machine's AWS CLI credentials or SSO session, and no local files beyond whatever it clones from GitHub. Most of what the ops checks actually needed to inspect — DynamoDB tables, Cognito state — was exactly the part a /schedule routine categorically cannot reach, regardless of how the tier's name reads.

The fix wasn't to force it, and it wasn't to reach for something heavier out of caution either. It was to recognize that AWS-dependent recurring checks aren't a chat-agent execution-tier problem at all; they're a backend infrastructure problem, with an existing precedent already proven in this repo (backend/lib/constructs/cognito-backup-construct.ts): an EventBridge Rule on its own schedule, invoking a scoped-IAM Lambda that already has the access a chat-facing routine never will. That's backend/lib/constructs/ops-scheduled-checks-construct.ts and backend-lambda/handlers/ops-scheduled-checks-worker.ts in this project's own tree today.

The other parts of the same effort — comparing seed JSON against live DynamoDB (audit-seed-drift, a real DescribeTable call) and scanning rps-pages-{env} for branch fan-out (audit-stale-branches, a real paginated Scan) — still touch live AWS. Getting that part right isn't "these need no credentials"; it's that a session-run invocable inherits the operator's already-authenticated local AWS CLI/SSO session for free, the exact access a /schedule cloud routine categorically lacks. That's the actual T3 distinction, and it's narrower than "no AWS access required": both checks stayed exactly where §12a said they belonged — real invocables (audit-seed-drift, audit-stale-branches) runnable inside a session, reaching AWS through the human already sitting at the keyboard, not through any infrastructure of their own. Same effort, same afternoon, two different mechanisms — one needed credentials only a scoped-IAM Lambda could hold on its own; the other needed credentials it could borrow from the operator for free.

6. Practices — What Actually Runs Today

• The three-tier decision-communication table, applied by shape of decision — T1/T2, running, docs/GuidanceForClaudeCode.md §6b. Workflows: Owner ↔ AI Decision Tiers is the diagram version of this axis.
• The five-tier loop taxonomy, each with its own documented kill switch — T1/T2/T4, running, §12a-12b. Workflows: Loop Tiers is the diagram version of this axis.
• The /schedule-cannot-reach-AWS corollary, found and corrected the same session it was written, now a standing constraint — T3, running, §5 above.
• The EventBridge-Rule-plus-scoped-IAM-Lambda pattern, reused rather than reinvented — T2/T3, precedent cognito-backup-construct.ts running in production; current instance ops-scheduled-checks-construct.ts written and in this project's own tree today, not yet confirmed deployed (see §5 — that's the accurate claim for it, and this bullet isn't entitled to a stronger one just because the section header says "running today").

7. Non-Goals

• Not a claim that bigger, more capable tools are always the wrong choice. Sometimes the work's shape genuinely needs the heavier mechanism.
• Not a rigid flowchart that removes judgment from the decision.
• Not a universal claim about all software organizations' tool shelves.
• Not a finished or permanent ranking of any mechanism against any other.
• Not part of the Perspectivity Research Reports series. Picking the smallest tool that fits doesn't get more interesting just because a fictional shelf exists two tabs over.

8. Revision History