Core Idea
Tool-first automation begins with a platform, connector, AI agent, or workflow engine before the team has named the operating problem. It feels modern because something moves automatically, but it often automates ambiguity, duplicate data, weak ownership, and poor control design.
A practical example is an AI workflow that summarizes vendor questionnaires before the team has defined risk acceptance criteria. The output becomes faster, but the judgement remains vague. The Companion should teach the learner to design the decision surface before selecting the automation surface.
Use In Teaching
Invoke this card when the learner wants to buy, script, or agent-build before they can explain the trigger, owner, decision, source of truth, and failure mode. It is a useful warning before lab-builder produces any automation exercise.
Use it before any lab involving scripts, agents, connectors, or GRC platforms. The learner should first write the plain-English operating loop: trigger, data source, owner, decision, exception, and review. Only then should the Companion help them decide whether automation reduces friction or merely accelerates a bad loop.
A reviewer should check that Tool-First Automation names a visible symptom, the hidden operating cost, and the safer pattern the learner can practise next. Without those three parts, the anti-pattern becomes a complaint instead of a learning tool for changing behaviour.
Contrast
This is not anti-tooling. Tools are leverage. The card pushes back against treating tools as rescue missions for unclear processes. Good automation makes a good operating model faster; it does not make an absent operating model appear.
Practice Prompt
Before choosing a tool, can you describe the manual version of the process well enough that a new teammate could run it correctly?