Lesson 2: Choosing the Right Tool
By the end of this lesson, you will be able to:
- Explain why the most sophisticated platform is rarely the right one, and name the costs every additional capability carries (K8, S27)
- Identify a situation where a simpler platform is the better choice than an agentic one (K8, S27)
- Handle information gaps in an assessment by surfacing and resolving them rather than assuming them away (K25, S27)
- Commit to a platform for your own project and write the first half of your recommendation, justified from your five-dimension assessment (K8, S27)
The most capable platform is rarely the right one
There is a trap that catches capable practitioners more often than careless ones: reaching for the most sophisticated platform available rather than the most appropriate one. The sophisticated platform is more impressive in a demonstration, more satisfying to configure, and more defensible to a sceptical colleague who equates capability with quality. None of those is the same as being the right choice.
The right tool is the simplest tool that reliably meets the requirements of the use case, given the constraints of the organisation. Sophistication is not a virtue in itself. It is a cost you accept when the use case truly needs it, and a cost you should refuse when it does not.
Every additional capability carries a cost, and the costs are real rather than theoretical:
Configuration time. A more capable platform has more to set up, more options to understand, and more ways to get the configuration subtly wrong. The capability you do not need still sits in front of you, demanding decisions.
Maintenance burden. Whoever maintains the automation after you carries the weight of its complexity. A simple workflow is approachable for the next person. An elaborate agentic configuration may be maintainable only by someone with the same expertise you brought, which your organisation may not have once you have moved on.
Audit complexity. An agent that determines its own sequence of actions is harder to audit than a workflow with fixed steps. For any use case under regulatory or governance scrutiny, that audit difficulty is a direct cost, not a side issue. A predictable workflow you can explain step by step is often worth more to a compliance reviewer than an adaptive agent you cannot.
Vendor dependency. A platform with hundreds of integrations and deep capability tends to embed itself more thoroughly into your operations, which raises the cost of ever leaving it. The more a platform can do, the more of your process tends to depend on it.
The instinct to over-engineer is strong precisely because the more capable platform feels safer. Name it for yourself directly: choosing the simpler tool is a more confident decision than choosing the elaborate one, because it requires you to have understood the requirements well enough to know what you do not need. Under-engineering and over-engineering are both failures; the skill is matching.
🔑 Right tool for the right job: The right platform is the simplest one that reliably meets the use case within the organisation's constraints. Every capability beyond that carries a cost in configuration, maintenance, audit difficulty, or vendor dependency. Match the tool to the requirement, rather than reaching for the most capable option available.
A worked situation: when simpler wins
Consider an operations team automating a supplier acknowledgement process. When a delivery confirmation arrives by email, the system extracts the order reference, updates the order status in their system, and sends a templated acknowledgement to the supplier. The process is identical every time. There are no judgement calls and no ambiguity to resolve.
A practitioner drawn to capability might reach for an agentic platform, reasoning that an agent could handle exceptions intelligently. A practitioner applying right tool for the right job asks a sharper question: what in this process actually requires a tool to decide its own actions? The answer is nothing. Every step is known in advance. The process is a fixed workflow, and a workflow-first platform runs it reliably, cheaply, and auditably. The agentic platform would add cost, audit difficulty, and maintenance burden in exchange for adaptive capability the process never calls on.
The simpler platform is not a compromise here. It is the correct answer. Choosing it reflects a clear understanding of the requirement, which is a stronger position than choosing the elaborate option out of a vague sense that more capability is safer.
The same supplier-acknowledgement use case built two ways. The over-engineered agentic version (left) adds cost, audit difficulty, maintenance burden, and slower delivery in exchange for adaptive capability the fixed process never uses. The right-sized workflow-first version (right) is cheaper, cleaner to audit, maintainable by the team, and faster to build. Both technically work — but only one matches the requirement, and matching the tool to the requirement is the skill.
Commit to a platform for your project
You have a scored five-dimension assessment from Lesson 1 and the right-tool lens from this one. It is time to make the call: which platform do you recommend for your project, and why? This is the first half of the platform recommendation that is your Module 3 deliverable — you will complete it in Lesson 4 after you have stress-tested it against the jagged frontier.
Committing is a decision, not a summary. A good commitment names one platform, states the project shape it will run, and gives the reasoning that made it win — which usually comes down to a small number of dimensions that decided it, not all five equally. Crucially, it also names what you are giving up by not choosing the runner-up, because a choice whose trade-off you cannot articulate is a choice you have not really understood.
Your Companion can help you draft this, but the commitment must be yours. Use it to turn your assessment into clear prose and to argue the opposite case — but you make the call, and you own the trade-off.
How to run it:
- Decide first, in your own words: name the platform and the one or two dimensions that decided it. Do not open the Companion until you have.
- Then ask your Companion to argue against your choice — to make the strongest case for the runner-up. Paste the prompt below.
- If the counter-case changes your mind, good — that is the assessment working. If it does not, you now know precisely why your choice holds, which is exactly the reasoning your recommendation needs.
I am recommending [platform] for my project, running it as a [fixed / AI-augmented /
agentic] workflow. Using the project context and the five-dimension assessment you
already hold, make the strongest possible case AGAINST my choice and FOR the
runner-up. Be specific: which dimension most favours the alternative, and what would
I be giving up by not choosing it? Do not tell me I am right — try to change my mind,
so that if I hold my choice I know exactly why.
[DECIDE IT — 15 minutes] Make your commitment, then record how it survived (or changed under) the counter-case.
Platform Commitment — First Half of Your Recommendation
Commit to one platform for your project, justified from your five-dimension assessment and stress-tested against the runner-up. You will carry this into Lesson 4 and complete the recommendation there. Complete it in one go and save as a md file. Save the md file within the same source folder you've given Evidence Companion access.
⏭️ Up next - Lesson 3: You have committed to a platform on paper. The next lesson pressure-tests it against reality — evaluating vendor claims critically and mapping the jagged frontier where AI is unpredictably strong and weak, so your recommendation rests on what a platform actually does rather than what it promises.