Every software company is racing to put an AI assistant into everything you use — and treating it as new ground. It isn’t. Nearly thirty years ago the industry shipped proactive, “helpful” software to millions of desktops, and the backlash was so complete it became a punchline. Krishna C. Mukherjee helped build that first wave. In The Microsoft AI Insider’s Playbook: Your Guide to Cloud Strategy and Digital Transformation (Apress, 2026), he traces the line from the earliest intelligent features in Microsoft Office to today’s Copilots — and the design lessons the industry keeps relearning.
1. You joined Microsoft in 1988 and spent years building some of the first “intelligent” features millions of people ever used — the proofing tools, AutoCorrect, AutoFormat, and the Office Assistant. What made you want to write this book now, at this particular moment in AI?
I joined Microsoft in 1988, and the pattern I saw then is repeating at a vastly larger scale. Over the following years, as we shipped spelling and grammar checking, AutoCorrect, and AutoFormat, the challenges extended beyond the algorithms to earning users’ trust, deciding when to interrupt, and knowing when to stay silent. The proofing tools succeeded because they flagged likely errors and fixed the common ones without getting in the way of the writing.
Every system I have built since has turned on the same question: how to make intelligent software useful enough that people keep using it. These include the Intelligent Filing Manager, an AI expert system for multijurisdictional compliance filings at Wolters Kluwer; the BVAL evaluated pricing service at Bloomberg; the migration of Icon Parking Systems off a VAX minicomputer onto the cloud; and, most recently at FIS, the integration of Microsoft Nuance conversational AI on Azure with the call center systems serving banking clients.
Today’s AI can take actions across business systems, which makes those lessons more consequential, and most organizations are learning them from scratch. I wrote The Microsoft AI Insider’s Playbook to shorten that education: nearly four decades of building intelligent systems on Microsoft platforms, distilled into the difference between a product demo and an enterprise system that organizations deploy and keep.
2. The Office Assistant — which many readers will remember as “Clippy” — became one of software’s most famous cautionary tales. Having worked on it, you argue its failure wasn’t really about the technology. What actually went wrong, and why do you think today’s AI assistants are at risk of repeating it?
I was on the Office team while the Assistant was built, working on the proofing tools, AutoCorrect, AutoFormat, and the automation layer, and I watched it take shape. Its failure is instructive because the underlying research was sophisticated; the Bayesian user modeling from Microsoft Research’s Lumière project was ahead of its time.
What went wrong was the decision about when to speak. The Assistant appeared unsolicited, usually when the user was focused on something else, and assumed a knowledge of intent it did not reliably have. Worse, dismissing it took effort, and unnecessary effort breeds resentment. The proofing tools in the same release did the opposite: wavy underlines the user could review or ignore, and AutoCorrect fixes with a one-keystroke undo. Same company, same release; the difference was the cost of being wrong and the respect for the user’s attention. Office XP’s smart tags are the example people forget. Unlike the underlines, which flagged problems in the writing itself, they offered actions on names, dates, and stock symbols the writer had not marked as actionable. Accuracy did not save them; the absence of consent sank them.
I carried that lesson into the Intelligent Filing Manager. I considered having it observe users so it could volunteer recommendations, and decided against it; the users were compliance professionals who knew their work. The system engaged only when a user started a transaction, asked only the questions required by that transaction and the selected jurisdictions, and generated a filing for each jurisdiction from the answers. Users stayed in control, which is a large part of why the architecture is still in service a quarter of a century later.
Today’s always-on assistants that volunteer summaries, rewrites, and follow-up actions without clear user preferences or easy controls risk repeating the same mistake. Repeated interruptions can undermine trust. GitHub Copilot’s ghost text, inline code suggestions that yield without friction if ignored, shows the lesson learned. Software earns the right to speak by being right and easy to ignore.
3. In the late 1990s you designed something you called the Intelligent Filing Manager, a rule-based system for automating document workflows. You argue its design anticipated ideas we now take for granted in cloud computing. What did that early project get right, and what does it tell us about where AI is heading?
It got three things right, and each has come back around.
First, it separated knowledge from machinery. The jurisdictional rules (which form, which fields, which deadline, which exceptions) lived in a rule base that domain experts could read and that changed as the states changed their requirements, while the engine that applied them stayed the same. The first product, CTInsuranceAdvantage, handled insurance filings across all 50 states and the District of Columbia, covering about 700 form types. CTAdvantage.com followed for corporate compliance on the same engine. Today’s AI deployments are converging on that shape: a model that proposes, and a governed layer of rules and data that decides what is allowed.
Second, its web-based implementation delivered the AI expert system as a service. We maintained a single version centrally, updated it whenever a state changed a requirement, and let customers use it without installing or maintaining anything. We did not call it cloud computing, but the customer bought a current, correct capability rather than software to keep current.
Third, it structured the interaction. The system first established the type of transaction the user needed, and then asked exactly the questions that transaction and those jurisdictions required, assembled from the rules. Well-designed conversational applications now build in the same pattern under names like intent routing and slot filling: identifying the requested task, then collecting the information needed to complete it. The models are new; the discipline is not.
What it tells me is that durable AI systems will be hybrids. Large language models are extraordinary at understanding what someone wants. They are not reliable at applying a rule the same way every time, and in compliance, payments, or health care, reliability is the product. The systems that last will pair a model’s understanding with a rule engine’s consistency, validate what the model extracts before acting on it, and keep the rules where experts can inspect and correct them.
4. One of the more practical arguments in the book is that most teams try to automate before they’ve learned to measure. Why is establishing a baseline first so important, and how should a leader tell whether an AI investment is genuinely paying off?
Reconstructing a process after you have automated it is difficult and usually incomplete. Most automation programs I have seen cannot say, a year after launch, what they saved, not because the improvement was not real but because no one measured the manual process first. The baseline should record elapsed time, staff effort, volume, error rates, and rework before deployment so that you can compare equivalent workloads afterward.
This is one reason so many organizations are stuck in pilot purgatory. Pilots are judged on the numbers easiest to capture, such as time saved, but those numbers do not tell you whether the organization will keep the system. That depends on whether users act on its output without redoing the work, once you count review, corrections, and operating costs. Companies that reach scale define what “working” means before the pilot begins, with an owner, a baseline, and evidence that would justify expanding or stopping.
A leader should ask three things: What was the baseline? How does current performance compare with it? And who owns measurement now that the project team has moved on? Without a credible answer to the first, the return becomes an article of faith; without one to the third, erosion goes unnoticed until a budget review. Time saved is a starting point, not a return. It has to become lower cost, capacity that is actually used, better service, or fewer errors, weighed against the full cost of implementation, operation, human review, maintenance, and rework.
5. You describe modern AI as a kind of “quiet force” and make the case that keeping humans in the loop is now an operational necessity, not a nicety. What new failure modes make governance so urgent, and what does responsible AI actually look like for a company deploying these tools today?
By “quiet force,” I mean that intelligence is becoming embedded infrastructure rather than a standalone feature. The technology becomes less visible as its benefits accumulate, and invisible systems need visible controls.
The new failure modes come from agents that act. When AI only advises, a person can catch an error before acting. An agent that issues the refund or closes the account can commit the error at machine speed across every matching case, thousands of times before a customer complains. Two mechanisms make this worse: unchecked action chaining, where an agent sequences actions across systems without effective permission checks, validation, or required approvals, and prompt injection, where instructions embedded in documents try to redirect it. An unmeasured process used to mean you could not prove the gain. With an agent, you may not detect the loss because the human checkpoint is gone.
Responsible AI, in operational terms, means limits on what an agent may do, enforced through system permissions and validation, rather than relying solely on the agent’s instructions; a named owner accountable for its operation; tamper-evident audit logs; continuous monitoring against a baseline; a tested way to stop an agent and, where possible, reverse what it has done; qualified human approval for high-risk actions regardless of the model’s stated confidence; and escalation with context when validation fails or a request falls outside approved boundaries. Autonomy expands in stages, as evidence and the task’s risk allow, never all at once.
6. You’re optimistic about “citizen developers” — non-engineers building real tools with AI and low-code platforms. Big picture: as AI puts software creation in more hands, how should leaders balance empowering people with keeping quality and trust intact?
The idea is older than the low-code platforms. In fact, it was the vision behind the Intelligent Filing Manager. I wanted the compliance teams, who understood the jurisdictional rules, to write the rules themselves rather than hand requirements to engineers and wait. The engineers built the application and the compiler for the experts’ rules; the experts wrote the rules in a form they could review and correct. Each group worked in its own language, and the system was better for it. Citizen development is the same division of labor at a much larger scale, and the way to keep quality and trust intact is the one engineering organizations learned long ago: separate the freedom to build from the freedom to deploy.
One model that works is hub-and-spoke. Professional developers form the hub and maintain the foundation: secure connectors, shared libraries, approved templates. Citizen developers are the spokes, assembling solutions for their own departments on that foundation without building connectors or security infrastructure themselves. It resembles urban planning: IT provides the utilities and the zoning, and the business builds within them.
Before an app touches live data or is shared, it should face checks proportionate to its risk: lightweight for a low-risk app on nonsensitive data, rigorous for a workflow that drives consequential decisions. Leaders who manage this well provide a clear path from experimentation to approved deployment, with defined ownership, and measure success by sustained adoption and reliable operation.
Krishna C. Mukherjee’s The Microsoft AI Insider’s Playbook (Apress) is available now.
