For most of my career I've worked on IoT across very different industries: smart home, automotive, energy, manufacturing. The pattern I kept running into had almost nothing to do with technology. The projects that held up were set up properly at the start by people who thought in ecosystems instead of single products. The rest were pilots that photographed well.
I'm convinced agentic AI works the same way. It has to be approached properly from the start, and the ecosystem question matters as much as the technology one. That is why I took the MIT Sloan Executive Education programme "Implementing Agentic AI: Building Your Organizational Playbook", run with the MIT Schwarzman College of Computing. Executive education, not a degree.
The playbook does the teaching
The programme's central document is a playbook, and its design carries more of the argument than any single lecture.
You fill it in across three modules, along three questions. What is agentic AI? How will you implement it? How will you scale it responsibly? Each module closes with a running recommendation: a paragraph arguing your decision for your own organisation. At the end, those paragraphs are the body of a board recommendation.
So you're not studying agentic AI. You're deciding something about your own company and then defending it. That the deliverable is a board paper and not an architecture document is the argument of the whole programme, made in the shape of the assignment.
It keeps sending you back to your own recommendation to read it the way a board member would: if they read that paragraph and nothing else, what would they conclude you were asking for?
I wrote mine for Ergon (working title), a pilot I'm running for small business owners in Greece. They answer a handful of questions and agents build their new website: content, layout, translation into several languages, mobile payments, and the tax reporting that has to go with them. A taverna can put its menu online, take an order and a payment from a phone, and have the transaction reach the tax authority, with nobody touching a spreadsheet. These are businesses that were never going to hire an agency.
Writing a board recommendation for something you own yourself sounds easier than writing one for a board. It isn't. There is nobody to be vague at.
What has to land at board level
The biggest barriers are organisational, not technical. This is the second of Kanchana Patlolla's three adoption realities, and it matched everything I saw in IoT. The models are usually good enough. The organisation usually isn't ready. Signing off the technology budget while postponing the organisational question means buying the expensive end first.
Your existing metrics won't capture the value. That's her third, and it's the one that kills good initiatives quietly. Your KPIs were built for a different unit of work. Measure agentic AI on cycle time or cost saved and you're measuring the wrong thing. Before the first budget goes out, decide what you'll accept as evidence that it worked. And what number, by when, means you stop.
Every agent needs a manager. Patlolla again, and not as a figure of speech. With a good employee you get three things that simply aren't on offer here: she's accountable for her work, she uses judgement in the grey areas, and she tells you when she's stuck. An agent gives you none of the three, and it fails quietly and confidently while carrying on as though nothing happened. So there's a real job here, and it sits closer to operations than to engineering. The question a board can actually settle is narrower than the job description: can this person switch an agent off, alone, at three in the morning? If not, you've appointed a coordinator.
In the pilot I manage the Ergon agents myself, and the assignment made me write down the part I would have preferred to leave implicit: one founder as the only manager is a single point of failure. For now the answer is a hard guardrail instead of an org chart; nothing goes live on a business owner's site without that owner's approval.
Autonomy is a dial, not a switch. The programme's term: a five-level dial from constrained to autonomous, set per agent and per task, with four safeguard layers alongside it: hard constraints, output verification, reversibility by design, and an escalation path.
Filling in the threshold map for Ergon, one criterion ended up governing every row, and it is the thing I'd keep if I had to throw the rest away. Put the human gate exactly where reversibility ends. Not where the risk feels highest, and not where the model looks weakest; both of those move with the news cycle.
So the agent drafts copy, assembles a layout, rewrites an unpublished page. All reversible, all autonomous, no permission needed. It never makes a site public on its own. It prepares a tax submission and never files one, regardless of how confident it is, because that action is irreversible and legally binding. Confidence is the wrong input at that gate. Consequence is the right one.
One thing to settle before you hand that rule to engineers, because they'll read it in the technical sense. Reversible has to mean the consequence can be undone, not the transaction. A field update to a connected machine is rollback-able. After a shift of out-of-tolerance parts has reached a customer site, nothing has been reversed. And the classification errs in one direction on purpose: wrongly gating something reversible costs you speed, wrongly leaving something irreversible ungated can cost you the company.
Compare the agent against the process you actually run. Tim Kraska's framing, and the most useful single idea on the programme. Not the agent against perfection: the agent plus its safeguards against what you do today. It cuts both ways, which is why I trust it. Your current process is rarely as good as your memory of it, it leaves no audit trail, and it depends on who was on shift. It also makes you say out loud where the agent is genuinely worse. Without that yardstick the status quo wins by default, because it's the only option nobody ever evaluates.
Governance is a position, not a cost. The programme treats transparent, auditable governance as something you can compete on, not something you pay for. In European industry, where your customer carries the liability if you can't show how a decision was made, that lands harder than it does elsewhere.
Why I'd do it again
None of the six is a technology insight. Every one is a decision somebody has to take, own, and be able to defend. Which is exactly why the programme ends in a board paper instead of a reference architecture.
That is also why I took it. The argument I make to a company, that this has to be approached properly from the start, does not hold if I skip my own version of it.