The button that broke the agent
The silent danger of shadow dependencies and why autonomy needs architectural integrity
Two weeks ago, an agent I deployed quietly stopped working. It had been doing a small, useful job: reading meeting transcripts and turning them into tasks in Microsoft Planner, deciding to whom the task should be assigned and which bucket (strategy, presales etc.) it should be in. We relied on it without thinking about it, which is the highest compliment you can pay a piece of software.
Then someone upgraded the Planner plan to Premium by… clicking a button shown by Microsoft in the Planner web, stating innocently that this plan can be upgraded to premium. One button and a perfectly rational decision to access better features. The person who clicked it was acting in good faith and did nothing wrong.
And the agent… went silent.
The reason? A Copilot Studio agent can’t create tasks in Planner Premium the same way it can in standard Planner. I’m fortunate enough to know both sides of this, because this is the ecosystem I live in as a Microsoft MVP and a hands-on CEO. With Planner Premium, I need to bypass the standard out-of-the-box Planner actions and instead configure the agent to use Dataverse / Project schedule API actions directly, or build an Agent Flow in Power Automate that handles the proper Dataverse-backed task creation.
Fine - that’s a platform limitation, and platform limitations are not interesting. What’s interesting is the part I keep coming back to:
Shadow dependencies in production at their worst:
the person who clicked that button had no idea an agent was running on the other side of it
They didn’t break the agent out of carelessness. They broke it because, as far as the org was concerned, the thing the agent depended on wasn’t a foundation for an AI agent running somewhere else. It was just a setting - the plan still exists, it will now be a premium plan. Nobody had a picture of what was quietly using it and that it was my agent.
This is the reality of production AI.
The failure was ultimately harmless because the agent was narrowly scoped (but its goal is not achievable with “standard” automation) and highly supervised. It operated in a fail-stop paradigm with a human in the loop who noticed the missing outputs within 24 hours. The worst-case outcome was a few tasks that didn’t get created and my anger until I found out what caused the error.
When an agent is narrow and its dependencies are traceable, failures are cheap.
The danger of fail-continue
Now keep the exact same mechanism - a silent dependency on a layer nobody is monitoring, that anyone can change with one click - and apply it to an autonomous system.
Let’s consider agents everyone is now racing to build. Not a transcript-to-task helper, but autonomous agents working around the customer: reading the account, pulling context, deciding what to do next, and acting on it without a human watching each step.
If someone clicks a button like in our case, in a distant space, or if someone changes a single permission, migrates a list, or enriches a record, or even swaps a connector to a “premium” version, the autonomous agent does not go silent.
It experiences state drift and keeps running.
It keeps acting on the customer, except now it’s acting on a foundation that quietly shifted underneath it - a permission it shouldn’t have, a record that’s now incomplete, context that’s subtly wrong. It doesn’t stop. It makes decisions based on truncated data, elevated permissions it shouldn’t possess, or corrupted context.
There’s no “that’s weird” the next morning because nothing looks broken. The agent is functioning perfectly on top of a broken foundation. This is a fail-continue scenario, and it is the most dangerous state for an autonomous system.
Architecture over caution
The industry response to these risks is often a vague call to “be careful with AI.” This is a useless directive because caution is not an architecture.
The agent in my story did precisely what it was supposed to do. The autonomous one in the hypothetical does too. Neither of them is the problem.
The problem is that we are building autonomy on top of a layer we never decided to treat as a foundation.
We continuously expand agents’ capabilities by implementing deeper integrations, granting broader read / write access, and higher degrees of freedom. Yet, we implement zero architectural integrity in the ground it stands on.
An autonomous agent is exactly as smart, and exactly as safe, as the data layer beneath it. Giving AI agents more autonomy without giving them a grounded, governed, deliberately-owned foundation does not add features. It simply scales risk.
The foundation is inverted
The uncomfortable part is that the whole industry is now building top-down. Agent first because the CEO wants agents. Autonomy first because we have to have autonomous agents. Organizations prioritize the agent layer because autonomy is the strategic mandate, while treating the underlying data and integration layer as a secondary detail to be resolved later.
We are building the systems that act before securing and locking the environments they act upon.
Defining that foundation and engineering it so that no single user interaction can quietly shift the ground beneath an active agent is complex. It requires explicit data contracts, dependency mapping, and rigid state management. This is the actual engineering challenge of the AI era, and it is exactly what I will break down in the next article.