What's Actually in the AI Consultant's Bag, 2026

The tool bag changed shape this year, and most "best AI tools" lists haven't noticed. They still read like a shopping list of chatbots, ranked by benchmark. That is not where the work happens now, so it is not a useful map.

We keep a running, opinionated version of the real bag on the Kit Bag page, grounded in what our own logs actually show. This is the companion piece: the reasoning behind it. The page has the picks. This has the why.

The workbench shifted, and that reorganises everything

Two years ago the AI part of an engagement meant opening a chat window, asking for something, and pasting the result into a real deliverable somewhere else. In 2026 the deliverable gets built in the tool. The scoping doc, the migration, the evaluation harness, the governance pack: these are assembled inside an agentic workbench that reads the repository, runs the commands, and writes the files. The consultant's primary surface is no longer a document and a browser tab. It is an agent with hands.

Once you see that, the bag stops being a list of products and becomes five jobs to be done. Here they are, in the order they actually matter.

1. The agentic workbench is the desk, not a gadget

Claude Code, Cursor, the Codex class of CLIs. Treat these as the desk you sit at all day, not a novelty you open occasionally. The skill that separates consultants here is not typing, it is directing and reviewing: giving the agent a clear objective, then reading the diff like your name is on it, because it is. The failure mode is letting it run unsupervised on a large change and shipping what you did not read. Pick the one your client's stack and security team will actually approve. That constraint decides more than any leaderboard.

2. The connected workspace is where the non code work moves

Cowork class agent workspaces reach your documents, mail and calendar, which is most of consulting that is not code. The multiplier in this category is MCP servers: they turn your agent from a talker into a queryer, able to pull real data mid engagement rather than guess. We built one, and we will disclose it with a grin, because that is the house rule: the Project Wrecked MCP server puts model deprecations, rates and a red flags checklist inside your agent. The discipline that matters is curation. Every server you install is a dependency and an attack surface. Install the ones you check often, and no more.

3. Delivery and evidence is the boring spine that saves you

This is the unglamorous category clients never ask for and every wreck in our archive needed. Versioned, diffable, dated documents and decision logs, so the record of what was agreed survives a stakeholder's convenient change of memory. An evaluation harness, a few hundred representative inputs and approved outputs, built from day one, because that set is the difference between validating a model swap in four days and arguing about vibes for a month. And a data audit before you scope anything, because the bodies are always in the data and they are cheaper to find early. None of this is a product you buy. It is a habit you keep, and it is what a consultant has that a demo does not.

4. The commercial layer is where capability becomes an invoice

Proposals, contracts and pricing. The tooling here is whatever you already write in, upgraded with two things the AI era demands. A real model deprecation clause in your SOW template, so a vendor's sunset schedule becomes a scoped change request rather than an unpaid weekend. And a vendor evaluation rubric that weights deprecation behaviour alongside capability and price, because a lab that retires fifteen things on a Tuesday is a different bet from one that publishes long runways. Our store products live exactly here, disclosed as ours. And you can wire the deprecation calendar straight into your build: wreck-watch scans your code for pinned model IDs and warns when they are on the departure board, free, in CI.

5. The watchlist, held loosely

The last slot is deliberately provisional: the agent evaluation and observability tooling we are still testing, the things we have opinions about but not conviction. We keep it in the bag so you can watch us change our minds in public, which is the only kind of tool recommendation worth anything.

The honest bit

We are one shop with one vantage point. This is our opinion, sharpened by our own traffic logs but still opinion. So we are turning it into a dataset. A short Stack Survey is coming, and once enough practitioners answer, its aggregates will take over the Kit Bag page and correct us where we are wrong, in public, which is the only correction worth trusting. Until then, treat this as a well argued starting point, not a verdict. And if your bag looks different, that is exactly the data we want.