The Executive's AI Productivity Stack Isn't a List of Tools
Every time I give a talk on executive productivity, someone asks me for the list. Which assistant, which note-taker, which agent, which plugin. I understand the request, and I stopped answering it directly, because the list is the least durable thing I can hand anyone. A tool list expires in a quarter. The decisions underneath it hold for years, and those decisions are what a productivity stack actually is.
An executive’s stack is a set of standing choices about where attention goes, what the organization’s knowledge looks like to a machine, which work gets handed off, and which work never does. The tools are the current answers to those choices, and they will change. If you can state the choices, you can swap any tool in an afternoon. If you cannot, you own a collection of subscriptions and a calendar that looks the same as it did last year.
A Tool List Ages Faster Than the Decision Behind It
Look at what happened to the executives who built their routines around a specific product in 2023. The product changed pricing, changed models, merged with something else, or got absorbed into a suite they already paid for. Their routines broke because the routine was written in terms of the tool. “I paste the transcript into X and ask for action items” is a procedure with a single point of failure and no stated purpose.
The same routine written as a decision survives the swap: every meeting I lead produces a written record of commitments within an hour, owned by a named person, searchable later. Any tool that satisfies that sentence works. Any tool that doesn’t gets removed, however good the demo looked. That is a standard you can hold a vendor to, and it is a standard your own staff can apply when they pick tools on your behalf.
I run my own setup on a mix of hosted and local models, and I rebuild parts of it every few months. The pieces move constantly. The four decisions behind it have not moved in two years.
The Four Decisions
The first is intake: what is allowed to reach you, in what form, and who or what filters it before it does. Executives drown in volume, and the first productivity gain from AI is usually triage. Summaries of long threads, a morning digest of what changed overnight, a first pass on the documents that need your signature. The design question is what the filter is permitted to drop, because a filter that never drops anything is a search box and a filter that drops the wrong thing is a liability.
The second is memory: what the system knows about your organization, your commitments, and your prior decisions. A general-purpose assistant with no context produces general-purpose output, which is why so many executives try these tools for a week and conclude they are mediocre. The tool was fine. It had nothing to work from. Giving it your strategy documents, your operating calendar, your board history, and your own prior writing is a data governance decision before it is a productivity decision, and it deserves the same scrutiny you would give any other transfer of institutional knowledge to an outside party.
The third is delegation: which tasks go to the machine, at what level of autonomy, and with what review. Drafting a first version of a routine communication is a different class of task from reconciling a budget variance, and both differ from anything that touches a contract or a personnel matter. Each class needs a stated rule about who reads the output before it leaves your hands, and how closely. Without those rules, review happens by mood, which means it fails on the days you are tired and busy, which are the days it matters most.
The fourth is judgment: the short list of work you do yourself because the doing is the point. Hiring decisions, the framing of a hard message to the board, how much risk to accept on a major commitment. You can take input from a machine on any of these. You do not hand them over, and writing that boundary down in advance keeps convenience from erasing it a little at a time.
What a Fire Support Plan Teaches About Stacks
In the Army, as a Fire Support Officer, I learned that a fire support plan is never a list of weapons. Nobody briefs a commander by reciting what is in the arsenal. The plan states the commander’s intent, ranks targets by what matters to the mission, defines the triggers that authorize fire, and names who has the authority to clear it. The weapons are interchangeable inside that structure, and the structure is what the commander is accountable for.
An executive’s AI stack works the same way. Intent is the outcome you are protecting, whether that is decision speed, board credibility, or time reserved for people. Target priority is where you point automation first, which should be the work that consumes the most hours and builds the least judgment. Clearance authority is the review rule from the delegation decision: who clears what before it goes out the door.
The analogy breaks in one place, and the break matters. A weapon does what it is aimed at, and a language model improvises. It produces fluent, confident, plausible output whether or not the content is right, so the failure looks like success on the page. That makes review the central design problem in an AI stack, ahead of capability, ahead of cost, and well ahead of which logo is on the product.
Accountability Does Not Delegate
When a chief of staff drafts a memo and you send it, the memo is yours. When a model drafts it and you send it, the memo is yours by exactly the same rule. No board accepts “the assistant wrote that” as an explanation for an incorrect figure, and no regulator or counterparty will either. The more fluent the tools become, the more the executive’s own review standard determines whether that fluency produces leverage or exposure.
This is why the stack belongs on the executive’s desk and not only in the IT backlog. Three questions I raise in the vendor conversation apply to personal tools as well: where your data goes, who owns the risk once something goes wrong, and what happens to your workflow when the vendor changes terms. I covered the organizational version of those questions in an earlier post on AI vendor decisions for tribal leaders. The personal version is smaller in scale and identical in structure, and executives tend to skip it because the tool feels like a private convenience. A tool that holds your calendar, your inbox, and your board materials is not private. It is a system of record you chose without a procurement review.
Protect the Work That Builds You
There is a trap specific to leaders, and it is the same one I wrote about for junior staff in AI is absorbing the work that used to build judgment. Some of the work an executive does is overhead, and some of it is how the executive stays sharp. Reading the raw numbers before the summary, drafting your own first paragraph of a hard memo, sitting through the unfiltered version of a problem. Automate those and you gain an hour today and lose some of your judgment over a few years, without any alert telling you it is happening.
My own rule is to automate preparation and keep interpretation. Let the system gather, sort, reconcile, and draft. Then read the source on anything that will move money, people, or the organization’s reputation, and form your own view before you look at the machine’s. If the machine and your view disagree, you have found the most useful five minutes of your week.
A One-Page Test for Your Own Stack
Before you buy or approve anything new, write the stack on a single page, in sentences. State what reaches you and what is filtered out. State what the system knows about the organization and who approved that. State which classes of work are delegated, with the review rule for each. State what stays with you and why. If a sentence cannot be written, you have found a decision you have been making by default.
Then test each tool against the page. A tool earns its place by satisfying one of those sentences better than what you have now, and it leaves when something else does it better. This is also the cleanest way to evaluate what your team brings you. A request to approve a new AI product should arrive with a statement of which decision it improves and what review rule comes with it. If it arrives with a feature list, send it back.
I would rather see an executive with two tools and four written decisions than one with twelve tools and none. The first has a stack. The second has a drawer of subscriptions, and the board will eventually ask which of them anyone is accountable for.