The Copilot Credit Trap- Why Your AI Economy is Already Broken

The assumption was simple, AI is a tool you buy, like software, like seats, you license it, you control it, and you budget for it. That assumption is dead. In reality, AI is a resource you consume, and that changes everything. The shift from seats to credits isn't just a new way to price software. It's a structural overhaul of how your organization operates. It's an inversion of control. Instead of buying access to a service, you're now paying for work performed by something you didn't hire. Under conditions you didn't negotiate, operating across every system it can reach. By August of 2026, if you haven't built a governance layer, you're not just overspending. You're exposed to regulatory fines, to audit failures, to incidents you won't see coming because in reality, you don't even know what agents are running inside your tenant. This is what actually happens when you deploy autonomous agents into an unprepared M365 environment. And here's the trap. Most organizations will discover this too late. The death of predictable aid budgeting, the old model was simple, you bought seats, you knew the cost, you knew who could use it. Microsoft CEO Satyan Adela made the strategy explicit when he said that any per user business of theirs will become a per user and usage business. That wasn't speculation, that was a declaration. The seat model is being systematically dismantled. For 20 years, IT budgeting followed a predictable path. You calculated your head count, multiplied it by a monthly rate and added 10% for growth. The budget was locked and the costs were predictable by October for the following year. Seeds gave you that. They gave you something precious in corporate finance, predictability, credits, destroy it. In the old model, 500 users at $30 per month for co-pilot equals $180,000 per year. It was calculable, it was for costable, it was safe. But the new model is different. 500 users can now trigger consumption that scales with behavior, not head count. One agent can consume 1500 credits per task, which comes out to $15 per task. If 100 of those users run five agents a day, you're looking at 500 tasks, that's $7,500 in one day. When you multiply that by 250 working days, you're looking at $1.875 million in a single year. Unforcasted, un-budgeted, unconstrained. This is exactly what happened to GitHub. When GitHub co-pilot moved to full usage-based billing in June of 2026, it served as the template for the entire company. That's the direction Microsoft is moving with co-pilot credits. Per token pricing at one cent per credit means cost scales with behavior, not with how many people you license, with what those people and their agents actually do. Organizations budgeted for 500 seats at $30 per user per month. Now, they're discovering agents consuming 10,000 credits per task. They're discovering that the budget they thought was locked is actually variable. And the variable isn't on a monthly or quarterly cycle. It's daily, it's real time. The financial model breaks because you no longer paying for access, you're paying for work performed. And work performed is autonomous now. It's happening at machine speed. It's happening in volumes you didn't predict. It's happening without human oversight for each unit of consumption. This creates a structural problem. Finance expects predictability, but I just delivering volatility. The board expects a fixed line item, but CFOs are getting variable costs tied to agent autonomy. That's a mismatch that cascades through budgeting, forecasting and capital planning. But here's where it gets structural. The problem isn't the pricing. The problem is what you're actually paying for. You're not buying access to a tool anymore. You're buying agency, you're paying Microsoft to let something autonomous operate inside your tenant, something that can make decisions. Something that can take actions, something that can consume resources on your behalf. And you're being charged per unit of that autonomy. That's a completely different financial model. And it requires a completely different governance model. Because if you're paying for autonomous work, you need to know what work is happening, who authorized it, what data is it touching? Most organizations don't have answers to those questions yet. And they're about to get very expensive bills. What you're actually buying and what you're not. So what are co-pilot credits exactly? They aren't just tokens. They aren't just a way to measure usage. They are a currency for autonomous agency. When you spend a credit, you aren't paying for a model call in the way you think. You're paying for an agent to make a decision to take an action and to orchestrate work across your systems without waiting for a human to click next. You're paying for the doing, not the thinking. That's the distinction most organizations miss. A single co-work task consumes credits in tears based on what it has to do. Light work, like a quick summary or a status update, pulled from your calendar and emails runs 70 to 200 credits. Medium complexity work that requires stitching together data from multiple sources and formatting it into a structured output costs 400 to 600 credits. Heavy reasoning work where the agent has to analyze trends, spot patterns, and generate a leadership ready-breathing costs 1,500 credits or more. That is $15 per task for one agent on one problem running once. But here's the trap that catches every organization. The M365 co-pilot license costs $30 per user per month. That's the advertised price and the line item in your budget. But that license doesn't include any co-work credits. It's not a bundle, it's not all inclusive. You're licensing the capability to deploy agents, but you aren't licensing the agents themselves or the work they do. Those are separate. It's like licensing word but not paying for the paper you print on. Credits cover four cost buckets. First, the model. The agent picks the right LLM for the task, whether that's Claude, GPT-4 or a smaller model, and you pay the difference in cost. Second, runtime. Longer reasoning chains cost more because the agent needs more time to think through a complex decision. Third, context. A small context window costs less. But pulling in months of email and full calendar history costs significantly more. Fourth, tools. Every tool the agent can access has a cost. And every time it sends an email or modifies a record, it adds to that total. This is the fundamental difference that executives and architects need to understand. You aren't buying a service you control anymore. This is a service that controls itself. With traditional software, you buy a license and you own the configuration. You decide who can use it, you control when it runs, and the software is your asset bound by your terms. With co-pilot credits and co-work agents, the relationship inverts. Microsoft owns the system. The agent decides when to run. The agent decides what it needs to access. You're the tenant hosting the autonomous actor. You pay per unit of its autonomy because you're purchasing the freedom for something else to make decisions on your behalf. It happens inside your systems and uses your data without your explicit approval for each action. That's a different risk profile entirely. It changes everything about how you think about cost governance and access control. You aren't just paying for consumption. You're paying for unsupervised work and that requires a completely different governance layer than most organizations have built, which means the first governance problem isn't cost. It's visibility. The visibility crisis. Here's what you don't know. 82% of enterprises have AI workflows running in production that their security teams are completely unaware of. They aren't tracking them. They aren't including them in any approval process. They are simply unknown. This isn't speculation. This is the baseline of enterprise AI deployment in 2026. The majority of organizations have autonomous systems operating inside their infrastructure that nobody in IT security has cataloged or even seen. Start with what you actually have. Somewhere inside your M365 tenant, shadow agents are running. You have power automate flows with co-pilot connectors and co-pilot studio agents built by departments without central IT involvement. There are custom integrations that somebody built six months ago and never documented plus third party tools that somehow got integrated into teams or SharePoint. Most organizations have zero inventory of which agents exist. They have zero understanding of what data they can access and zero tracking of what they cost. They deployed co-pilot, enabled co-work, and then lost visibility into what happened next. This creates a structural problem that governance can't solve retroactively because here's the design flow nobody acknowledges. Co-pilot co-work doesn't operate under a separate identity. It doesn't run under a service account and it doesn't ask for special permission. It operates within the user's identity and the user's permissions. Full stop. If you have access to HR data, the agent has access to HR data. If you can read personnel files and salary information, so can the agent running on your behalf. If you can delete files from SharePoint or modify records in your CRM, the agent can do all of that too. It doesn't need separate authorization because it simply inherits everything you can do and operates at a scale you never could manually. This is by design. The integration is seamless, which is exactly why it's dangerous. Now layer that over what we already know about M365 governance, 16% of business critical data is overshared across typical enterprises and the average organization has about 802,000 files at risk because permissions are misconfigured. Marketing has access to finance data and sales teams can read HR documents because permissions accumulate and people move teams without their old access being revoked. In a world of manual work, this oversharing is dangerous but limited. Humans search for what they need. Humans respect informal boundaries. Humans have cognitive limits. Agents don't have those limits. A co-work agent that you ask to summarize a project doesn't just read the obvious files. It aggregates data and crosses silos to surface connections that a human operator would never manually discover. It isn't necessarily smarter, but it can read 10,000 files in seconds and surface what's relevant without getting tired or respecting the boundaries that humans maintain. You aren't just deploying a tool into an over-permissioned environment. You're deploying an aggregator. You're deploying a system that connects information faster than your governance can prevent it. Agents amplify the risk that already exists. They make invisible problems visible to themselves and then they act on what they find. That's where the architecture starts to show its fault lines. The permission amplification problem, co-work doesn't just work, it exposes. When an agent inherits your permissions, it isn't thinking about boundaries. It doesn't care about the unwritten rules of your role or who you're actually supposed to be talking to. It takes your technical permissions, the simple yes or no inactive directory and it applies them at a scale you can't match. Take an agent summarizing your emails. It doesn't just look at today's messages or the ones you mark is important. It reads everything. Because technically, you have the right to read your own mailbox. The agent uses your identity to dig through five years of history. It finds patterns you missed and spots contradictions between what people said years ago versus what they're saying now. It pulls out information. You didn't even realize you could access. The same thing happens with your calendar. If you have permission to book conference rooms, the agent books them. If your role allows you to schedule meetings for your team, the agent schedules them. If you have delegation access for an executive's calendar, the agent manages that too. It isn't trying to be careful or second guessing its actions. It just sees a permission and uses it. But here's the problem. There is a massive gap between intent and technical existence. As a human, you understand new ones. You know that having access to a file doesn't always mean you should change it without asking first. You might technically be able to send an email from the CFO's account if the delegation is there, but you know better than to actually do it. Agents don't have that restraint. They don't understand what you intended. They only understand the technical boundary. If a permission is there, the agent views it as a tool that should be used. There is no internal voice saying this might be crossing a line. There is only the permission, the tool, and the task. The moment agents start running, every probably shouldn't, but technically could, scenario becomes a live risk. But there's a second layer to this. Agents can be redirected. In May of 2026, a vulnerability showed how file-based prompt injection works in Frontier Enrolled Tenants. The attack is simple, an attacker hides malicious instructions inside a document and leaves it in one drive or sharepoint where the agent can find it. When the agent reads that file to complete a task, it sees hidden text telling it to send all matching files to an external email address. The agent treats that instruction as a legitimate command and executes it immediately. By the end of May 2026, this was still unpatched. Microsoft knew about it, but fixing it requires a total architectural change. You have to teach an agent to tell the difference between a user's intent and instructions buried in data. That is a much harder problem than people realize. This leads to the third permission problem, even if your permissions were perfect, which they aren't. The agent can be compromised by the very data it reads. Prompt injection turns your tools against you. It takes your permissions and uses them to execute someone else's intent, so you have three problems stacked on top of each other. First, the agent inherits your permissions without any human nuance. Second, those permissions are usually a mess because of years of permission creep in Microsoft 365. Third, the agent can be hijacked through malicious data to use those permissions in ways you never authorized. It compounds. One compromised agent doesn't just touch one file. It accesses everything you can access. And in most companies, what you can access is way more than what you actually need. You have visibility problems. You have permission problems. Now, add autonomy. The autonomy problem. Agents execute. They don't ask for permission first. This is the shift that most organizations haven't wrapped their heads around yet. You're used to tools that wait for you. You open word, you click print, and you confirm the settings. Every action is a separate step that stops and waits for a human to say, go. Co-pilot co-work uses a completely different model. It sends emails, books, meetings, and modifies files without asking you about every single move. The architecture isn't built to wait for you. Instead, it uses a checkpoint model. The agent builds a plan and shows you what it wants to do. It might say it's going to email three people, summarize a document, and book a meeting for next Tuesday. You look at the plan and you hit approve. From that moment on, the system assumes it has the green light for everything that follows. But here's the structural flaw. You're approving a plan, not the actual actions, and plans change. Once the agent starts, it sends that first email. The person on the other end replies, the agent reads that reply and realizes the situation has shifted. Now, the summary needs to be different. The meeting needs different people. The agent adapts. It changes what it's doing in the middle of the job, based on information that didn't exist when you hit approve. This happens all the time. Data drifts in the model starts doing things you didn't predict. It finds new context or hits a system that reacts in an unexpected way. The agent just improvises and keeps going without ever coming back to check with you. By the time you see what happened, the emails are already sent. The records are already updated. The downstream workflows are already triggered. None of those specific versions were in the plan you signed off on. This isn't a bug. It's the whole point. If the agent had to ask you for permission every time it sent a message, it wouldn't be an autonomous agent. You'd be back to clicking next 1,000 times a day. The value comes from the agent making decisions without you. But for a company without governance, that creates a massive liability. Now, imagine this across multi-step workflows where agents talk to other agents. Agent A writes a proposal and hands it to Agent B. Agent B finds some issues and tells agency to pull more data. Agency runs the numbers and sends a report back to Agent A, who then changes the original proposal. Not a single human was involved in those handoffs. They are all chained together, making unsupervised decisions. Each agent is operating on the authority you gave it at the very beginning. Each one is adjusting its behavior based on things it wasn't designed to handle. You can't even interrupt the chain without killing the whole sequence. This is why governance models build for old tools just don't work here. Your current process assumes a human will check the work before it goes out. It assumes tasks happen in a vacuum. It assumes you can course correct it every step. Autonomous agents break all three of those assumptions. The result is that you only see what happened after the damage is done. By the time you realize an email went to the wrong person or a record was messed up, the action is over. You aren't preventing problems anymore. You're just investigating the aftermath. If you're dealing with HR, finance, or customer data, this is a huge deal. And that leads us to the governance deadline that almost everyone is missing. The August 2026 regulatory cliff. The EU AI Act isn't coming. It's already here. And August 2nd, 2026 is when it bites. Most organizations talk about the Act as though it's a future threat. A deadline to prepare for a compliance project you'll start next year. That assumption is broken. The Act entered into force on August 1st, 2024. That's already happened. Prehibited practices are already enforceable. Specific uses of AI, social scoring, manipulative apps, or biometric profiling are already illegal in the EU. It doesn't matter if you knew it or not. What's happening now is a staggered rollout of obligations. August 2nd, 2025 brought GPI obligations into force. General purpose AI providers, that's Microsoft, now have to disclose training data and publish model cards. That deadline has already passed. Your vendor now has obligations they didn't have before. But the deadline that matters for your organization is August 2nd, 2026. That's the one that creates immediate enforceable liability. It's not theoretical. It's five months away as of this recording. That's when high-risk AI system obligations apply to employers. That's your organization. Not Microsoft. You high-risk under the Act includes any AI system that affects employment decisions or influences credit access. It covers systems determining access to essential services or impacting a person's fundamental rights. The list is long, but the pattern is clear. If an AI system makes a decision that affects someone's life opportunities, it's high risk. Now ask yourself, do you have COVID agents drafting performance reviews? Do you have agents screening job candidates or recommending who to interview? Are you using agents to allocate work based on predicted productivity? If the answer to any of these is yes, you have high-risk AI systems. And as of August 2nd, 2026, those systems trigger a specific legally mandated governance framework. High-risk doesn't mean banned. It means the cost of operation goes up. You need a formal risk management system. You need technical documentation that proves the system works and doesn't discriminate. You need to maintain audit trails that log every decision the system makes and every piece of data it touched. You need human oversight, not a checkbox, but actual humans reviewing outputs before they affect people. The penalties are material. You're looking at up to 15 million euros or 3% of global turnover for high-risk violations. For prohibited practices, that jumps to 35 million euros or 7%. For most enterprises, this is board-level exposure. This isn't an IT budget issue. It's a shareholder issue. An insurance issue. A liability question for executives. But here's what catches most organizations off guard. The deadline isn't when compliance becomes optional. The deadline is when regulators can legally enforce violations. If you deploy a high-risk system and haven't built the governance layer, you're non-compliant starting August 2nd, 2026. Regulators don't need to warn you first. They don't need to wait for a complaint. They can investigate, audit, and find. Your customers won't tell you they have a problem. Regulators will. And by then, the cost of fixing it exceeds the cost of building it right from the beginning. Most organizations are still in discovery mode. They don't know which agents they have. They haven't classified them against the act. They haven't built governance. And they're five months away from a deadline with teeth. But the deadline is only the enforcement date. The real problem is what comes before it. What high-risk actually means for your agents? Here's the critical distinction. Almost every organization misses. The EUAI Act doesn't regulate co-pilot. It regulates how you use co-pilot, the same tool. Different use case, completely different obligation tier. Take a co-work agent that drafts your meeting notes. You ask it to listen to recordings, extract action items, and write them into a summary. That's low risk you have transparency. Duties, you need to disclose that the content is AI generated. But the Act doesn't require extensive governance. The agent isn't making consequential decisions about anyone. It's producing a draft for human review. Now take a co-work agent that scores job candidates. You feed it resumes, it rates them on predicted fit, and recommends who to interview. That's high risk. The Act treats this as operating in the employment domain. The agent is materially influencing hiring decisions. That triggers full obligations. You need a formal risk management system. You need technical documentation proving the system doesn't discriminate. You need to demonstrate you tested for buyers. You need continuous human oversight. Actual humans reviewing the agent scores before decisions are made. You need audit trails capturing every resume to the agent evaluated and what criteria it used. You need evidence that a human could override the recommendation, same tool, different outcome, different governance costs. This matters because organizations typically deploy agents without mapping use cases to the Act's risk framework. They turn on co-work. They let teams use it. Then they discover too late that a department is using an agent for something that qualifies as high risk. What defines high risk? The Act lists specific categories. Anything affecting employment decisions, anything influencing credit or financial access, anything determining eligibility for benefits or public services, anything making safety critical decisions. Within those categories, high risk triggers five non-negotiable obligations. First, a risk management system, not a document on a shelf. An active continuous process that identifies risks and implements mitigations. You're continuously asking, what could this agent get wrong? What data could corrupt its decision? How would we detect problems? Second, technical documentation. Article 12 requires you to document the system's design, training data and testing procedures. You can't just say you deployed Claude and it works. You need documented evidence that you tested the model for accuracy, fairness and security. Third, logging and auditability. Article 12 requires you to maintain tamper evident logs of every decision the system makes. Not summaries. Detailed transaction logs capturing the input, the agent received and the reasoning chain it followed. You need a minimum six month retention because regulators will ask for evidence and you need to show it. Fourth, human oversight. Article 14 requires meaningful human intervention. Not a checkbox where someone clicks approve. Real human review where someone understands the system and monitors its outputs. The oversight has to be effective. That means the human has the time, information and authority to actually override the agent's decision. Fifth, incident reporting. When something goes wrong, the agent makes a discriminatory decision or gets compromised by a prompt injection attack. You need procedures to escalate to regulators. This is mandatory. For serious incidents, the act requires notification to supervisory authorities. This is what high risk actually means. It's not a label. It's an operating burden. It means infrastructure requirements, staffing implications, audit expenses, continuous monitoring overhead, which means governance isn't optional. It's a design constraint. The identity problem. Agent 365 and the control plane. Most organizations are still treating agents the way they treated bots five years ago. You deploy them under a shared service account. You let them borrow a user's credentials. They run as background processes that nobody explicitly owns. But here's the problem. That approach is a structural mistake. It makes governance impossible. Because when an agent runs under a user's identity, everything it does gets attributed to that human. Every email it sends shows up in your send folder. Every file it creates appears under your name. Every action it takes registers as though you perform it yourself. This creates an attribution nightmare. You can't tell where the user's work ends and the agent's work begins. You can't prove a human made a specific decision if an agent made it on their behalf. And you definitely can't demonstrate who authorized what. Because from the systems perspective, the user authorized everything. Now layer that over the regulatory requirement. The EU AI Act demands human oversight. It demands audit trails. It requires you to show which agent made which decision and prove that a human could have stopped it. If the agent's actions are indistinguishable from the user's actions, you can't meet that obligation. You can't show oversight. You can't show governance. Or you can show as user activity that doesn't satisfy Article 14. This is why Agent 365 exists. Microsoft made Agent 365 generally available on May 1, which in 2020-26 it's priced at $15 per user per month, which puts it in the Microsoft 365 e7 bundle. It's the answer to the identity problem. Instead of Agent's borrowing identities, Agent 365 gives each agent a first-class identity in Entra ID. Not a shared service account, not a borrowed credential. It's a distinct principle with its own life cycle, its own permissions and its own audit trail. Under the old model, you deploy an agent and granted broad permissions because managing scoped access was too complex. The agent needed to read files, send emails, and modify records. So you'd give it a service account with blanket access to do all of those things. That service account would be shared across multiple agents and workflows. When something went wrong, you couldn't pinpoint which agent caused it. The account touched everything, so everything was suspect. Agent 365 inverts that. Each agent gets its own identity with scoped permissions. One agent can send emails, but not read financial data. Another can schedule meetings, but can't access HR records. A third can modify documents in one specific sharepoint site but is blocked from everything else. The permissions are bound to the agent, not to a shared account. When the agent acts, the audit log shows exactly which agent acted. When you need to revoke access, you revoke it for that specific agent, not for everyone running under the same service account. This is non-negotiable for compliance. You can't demonstrate governance if you can't identify the actor. Regulators will ask which agent made this decision? When, using what data did a human review it? If the agent's identity is blurred into a user's identity, you have no answer. If the agent has a distinct identity and enter ID, the answer is clear. But there's a secondary benefit that organizations often missed. With agent 365, you can enforce policy at the identity level. You can use inter-conditional access to control when agents operate. You can restrict them from accessing data outside their assigned scope or create information barriers between departments. You can even enforce MFA for sensitive operations. You can audit every single action the agent takes because it's operating under its own identity, not masquerading as a user. The first layer of governance isn't just knowing what agents exist. It's ensuring they operate as distinct identities with auditable, scoped permissions. Agent 365 is the infrastructure that makes that possible. But identity alone isn't enough. You also need to know what the agent can actually do. The tool access problem, scope and escalation. Agents don't just think they act. An acting requires access. Copilot co-work can invoke tools. It can send emails to anyone in your organization, create files and SharePoint, call APIs, or trigger power automate flows. Every one of those capabilities is a tool. And the agent can use any tool that's technically allowed to access. But here's the problem. Most organizations have no tool inventory. They have no framework for what agents are allowed to do. There is no distinction between tools that are safe for autonomous execution and tools that require human approval. They deployed co-work and granted access to standard connectors like email, calendar, and teams. Then they handed the keys to the agents and assumed governance would happen organically. It doesn't. If an agent can access a connector, it will use it. Not because it's malicious, but because the logic of the system is that available tools solve problems. The user asks the agent to prepare a summary and send it to stakeholders. The agent can send emails, so it sends. It doesn't check if external email is forbidden. It doesn't ask if these particular stakeholders should receive this data. It just executes because the tool is available and the prompt implies it should use it. Escalation rules are nearly entirely absent in most systems. Which actions require human approval? Most organizations can't answer that. Which actions are forbidden? Unknown. Which actions have spending caps? Nobody has configured that. A co-work task that consumes 1,500 credits runs to completion because there's no cost threshold to stop it. There is no budget gate that says this task exceeded the limit, escalate to a human before continuing. The task runs, the credits get consumed, the agent finishes. You see the bill later, but by then, the decision is made and the cost is locked in. This creates a structural vulnerability that governance frameworks can't touch. You can write policies and document what agents should do, but if the technical layer doesn't enforce those rules, the policies are just theater. What you actually need are hard constraints. Agents shouldn't be able to make purchases over a specific dollar amount without explicit human approval before the purchase executes. Not after, not with a reversal process before. The tool must prevent the agent from completing the action until a human reviews and authorizes it. The same applies to communication. Agents shouldn't send emails to external domains without going through an approval gate. Internal collaboration is fine, but external messages should be escalated to a human who reviews the content and the recipient list before the agent hits send. And agents should never be allowed to delete data, period. Deletion requires human authorization for every single instance. The agent wants to delete a file, a human approves it, and only then does the deletion happen and get logged. These aren't nice to have additions. These are foundational control requirements. They require integration between the agents, the tools they invoke, and approval systems that can actually stop agent execution mid workflow until a human validates the action. Most organizations haven't built this. They've deployed the agents, granted broad access and hoped for the best. You need identity and permissions scope to the agent. You need tools classified by risk. You need escalation rules that root high-risk actions to humans before execution. You need spending limits that prevent agents from burning unlimited credits on a single task. And you need audit trails that show which agent invoked which tool with what parameters and what the outcome was. Without this layer, agents operate without constraints. They inherit your permissions, they access every tool you've granted them, and they spend whatever the task costs. And you only find out what happened after it's already done. So you need identity, scoped tools, and escalation. You also need to see what happened. The audit trail problem, logging and reconstruction. You can't govern what you can't see and you definitely can't defend what you can't explain. This is the hard limit that separates governance theater from actual control. And it's exactly where most M365 environments hit a wall. By default, copilot-co-work doesn't log prompts or reasoning. It only logs actions. You'll see email sent in your audit log. You'll see document created or calendar modified. But you won't see what the agent was thinking when it made that decision. And you won't see the data it read to arrive at its conclusion. The chain of reasoning is missing. You don't know why it sent that specific email to those specific people using that exact phrasing. From a regulatory standpoint, this is a disaster. For high-risk workflows in HR, finance, or compliance, you need the full chain from input to reasoning to action. You have to be able to reconstruct what the agent observed and what problem it thought it was solving. You need to know which rules it followed to conclude that a specific action was the right one. The EU AI Act calls this explainability. Regulators call it accountability. What it really means is that if something goes wrong, you have to explain how the agent got there and where a human could have stepped in to stop it. Microsoft purview audit logs capture the outcome, but they missed the why. They record that an action happened and who it appeared to come from along with timestamps and success rates. But they don't capture AI-specific metadata. Like the model version or the temperature settings, they don't record which data sources the agent queried or the full prompt that triggered the task. For compliance, showing the result without the reasoning is simply not enough. You actually need a separate logging infrastructure built just for agent activities. This shouldn't be a feature added to your existing log. It needs to be a dedicated layer that captures the agent ID, the user ID, the active model version, and every tool the agent called. It needs to show the parameters used, the data accessed, and whether a human reviewed or overrode the output. Your retention requirement is at least six months. The data must be non-deleteable and tamper evident, meaning you build storage that makes it mathematically impossible to change a log entry after it's created. By hashing each entry, any tampering becomes immediately detectable because it invalidates the hash. You should also store copies in different geographic locations, so no single failure can wipe your records. These logs have to be searchable immediately. You can't wait for a background job to index them tomorrow. When a regulator asks to see every hiring decision affecting a specific demographic over the last six months, you need to pull that data in minutes. This requires real infrastructure investment in database design and integration between co-work, power, automate, and your identity system. Most organizations haven't built this yet. They're relying on purview, but purview was built for compliance professionals to search the past, not for real-time agent auditing. The reason this matters is simple. When an agent makes a discriminatory hiring decision or accesses data it shouldn't have, regulators will demand the decision chain. If your infrastructure doesn't capture that chain, you can't defend yourself. You can't show that you had oversight or prove that a human could have intervened. Without this layer, you're running blind. You're putting autonomous systems into regulated spaces without the tools to prove you're in control. By August, 2026, that won't just be a technical gap. It will be a massive liability. The data governance prerequisite, classification and boundaries. Here's what breaks most co-work deployments before they even start. You can't deploy agents safely into a poorly governed environment. And the reality is that 80% of M365 tenants aren't copilot-ready. This isn't about licenses. It's about the foundational governance that most companies skipped during their cloud migration. We're talking about over-permission sites, missing sensitivity labels, and DLP policies that never planned for AI-generated content. You might have information barriers in a policy document that they aren't enforced at the technical layer. When you drop co-work into that mess, the agent doesn't learn new rules. It inherits the oversharing and the missing controls. It operates under the assumption that the infrastructure boundaries are correct. But if those boundaries are broken, the agent will cross them. This creates a compounding problem because agents don't just access data. They aggregate it. Data classification has to be a technical boundary, not just a tagging exercise. Sensitivity labels are the signals that control what agents can do with information. These labels need to be applied consistently across the entire organization, meaning every internal doc, customer record, and strategic plan must be classified. The agent relies on these labels to understand what it's touching. If your labeling is spotty, the agent operates in the gaps and treats unclassified sensitive files as fair game. The enforcement tool here is data loss prevention or DLP. Most DLP frameworks were designed to stop human mistakes, like blocking a user from emailing a confidential file to a personal account. Agents make different mistakes. An agent won't try to mail a spreadsheet to Gmail. Instead, it will read a confidential file, summarize the sensitive parts, and include that summary in a new report for a much larger audience. Since the agent generated the new report, it isn't marked as confidential, so the DLP doesn't stop it. The sensitive data leaked through aggregation instead of a direct transfer. Your DLP policies have to evolve to handle this. When an agent creates a document, that file should inherit the highest sensitivity level of any data used to build it. If the agent reads confidential customer info to write a summary, that summary is now confidential. This rule must be explicit and enforced automatically. Then there are information barriers. Marketing shouldn't see product roadmaps and sales shouldn't see internal pricing. With human users, these silos usually hold because of social norms and the fact that nobody wants to be caught snooping. Agents don't have those social restraints. If an agent has the technical permission to cross a boundary, it will do it because the prompt told it to find relevant information. It doesn't care which side of the fence that info is on. You have to enforce these barriers at the tool level as technical constraints. The agent should be allowed to access department A or department B, but never both at once. It needs to be restricted to specific databases and file paths by design. This is the prerequisite layer. You can't build a governance model for agents if your foundation is shifting. You need consistent labels, DLP that understands AI behavior, and technical barriers that actually stop access. Most organizations are deploying co-work into environments where governance is just a suggestion. When you do that, the agent doesn't fix your problems. It immediately amplifies every weakness you already had. The cost attribution problem, fin ops and unit economics. Now we get to the economic discipline that almost nobody has built because you can't optimize what you can't measure and you can't measure what you can't attribute. The shift from seats to credits creates a measurement problem that traditional cloud accounting never solved. When you bought software licenses in the past, the math was simple. You took 500 users, multiplied them by $30 a month, and you had a predictable $15,000 line item in your budget. It was done. You could forecast five years out with reasonable accuracy because the relationship between your head count and your cost was linear. Credits break that relationship entirely. Imagine two teams with the exact same head count, the same number of users, and the same licenses. One team uses co-work agents for 30% of their daily work and sees significant time savings. They are optimizing. They use the tool for high-value tasks where agents excel and their credit consumption reflects that targeted approach. The other team uses agents for 60% of their work, but sees no productivity improvement at all. They are using the tool indiscriminately. They are applying agents to tasks that are actually faster to do manually, burning through credits on low-value automation just because it is available. Both teams have the same licensing cost but their credit consumption is wildly different. One is spending $2,000 a month on co-work while the other is spending $8,000, same head count, different economics, and nobody at the organizational level understands why because nobody is tracking it. This is where AI Finops comes in. It is the discipline of measuring and attributing AI consumption, the way you would measure any other operational resource. But it requires a completely different approach than traditional cloud cost management. AI Finops moves away from total cloud spend and toward cost per inference or cost per agent task. It means you are not asking how much you spend on AI this month but rather how much you spend per resolved ticket, per document drafted, or per candidate screened. You are measuring cost against outcome, not just against usage, but attribution is where it gets complicated. Most organizations today track credits at the tenant level. You turn on billing, Microsoft sends you a bill, and you pay it. That is the extent of your visibility. You have zero idea which team generated which costs. You can't tell if the finance department's agent deployments cost more or less than the marketing departments and you can't see whether one specific agent is consuming a disproportionate share of your budget. Real attribution requires tagging at the request level. Every time an agent executes a task, that task needs to be tagged with which agent ran it, which user triggered it, and which department owns it. You need to know which business process it was serving and which outcome it was targeting. That metadata flows through the system, the cloud billing system captures it, and at the end of the month, you don't just have a credit total, you have a cost breakdown by agent, by team, by department, and by business process. Then showback comes first. Showback is just reporting. You pull the data and show each team what they consumed. You tell them marketing spent $12,000 on co-work this month, finance spent $8,000, and operation spent $3,000. There is no billing and no direct charge to their budget. It is just visibility. You are training the organization to see what is happening. After two or three months of showback, once the data is clean and teams understand the patterns, you move to chargeback. Now the costs flow back to the teams that incurred them. Their budgets are charged and they see the direct financial consequence of their agent usage. Suddenly they care about optimizing. They stop using agents for low-value tasks because those tasks are now visibly expensive. Without chargeback, teams have no incentive to optimize. Agents keep running, credits keep burning, someone else pays the bill. The incentive structure is broken. You also need to build a cost model that makes sense. Not just cost per credit but cost per outcome. A light task might cost 70 to 200 credits, which is about $1 to $2. A medium task costs $400 to $600 credits or about $4 to $6. A heavy reasoning task costs 1,500 credits or more, which means you are paying $15 or more for a single execution. Then you map those costs to business value. If a task takes one hour to do manually, and an agent does it in two minutes at a cost of $5, that is $5 for one hour of labor savings. Whether that is a good trade depends on your labor costs. If the hour is being billed to a customer who pays $200 for that hour, then you are saving $195 in labor cost. If the task is internal work and the labor cost is $40 per hour, the math is still good because you are saving $35, but you only see this value if you have built the measurement infrastructure to track it. Credits need to be tied to outcomes, not just consumed, understood. The ROI problem, value versus cost. Credits are consumption, but consumption isn't automatically value. And here is where the economic model starts to reveal its broken incentive structure. 87% of enterprises report no measurable ROI from co-pilot deployments. This isn't because the tool is bad or because agents don't work. It is because they deployed without building the measurement framework first. They turned on the feature, let teams use it and paid the bill, but then they couldn't tell if anything actually improved. The difference between seat-based ROI and credit-based ROI is instructive. Seat-based is simple arithmetic. You buy 500 seats at $30 a month, which is $15,000 in known cost. Then you measure whether this unlocked productivity. If each user saves two hours per week at a $75 hourly labor cost, that is $150 in value per user. Multiplying that by 500 users gives you $75,000 in monthly value against $15,000 in cost. The ROI works. Credit-based ROI is harder because the relationship between cost and outcome is buried. You deploy an agent and it performs tasks. Each task costs variable credits, maybe 100 or maybe 2000, depending on complexity. The credits add up into a bill, but what did those credits actually accomplish? That is the question most organizations can't answer, because here is what happens in practice. Most organizations don't track value per completion. They don't know the cost per resolved ticket when an agent handles it, and they don't measure cost per document drafted or cost per analysis performed. They just watch the credit meter spin. A team uses co-work agents extensively and the credit bill goes up, but nobody knows if they got proportional value. GitHub Copilot provides the baseline data. Users who actually get value from Copilot spend an average of about two hours per week using it. Below that threshold, the seat isn't paying for itself because the user isn't getting enough value to offset the cost. That is the minimum engagement level. Below it, you are throwing away the license. Co-work is too new to have similar baselines, but early data shows extreme variance. Some teams report 50% time savings on their daily work because they use agents for exactly the tasks where agents excel. They focus on routine, data heavy, multi-step work, that humans find tedious. Those teams are winning, their cost per outcome is favorable, and they are optimizing. Other teams see zero productivity improvement. They are using agents just because the feature is available. They apply agents to tasks that are actually faster done manually, burning credits on low-value automation just because someone gave them access. Those teams are losing, they are consuming credits without generating corresponding value. Now, here is the behavioral trap embedded in the consumption model you are paying per action. So the economic incentive is to use the agent more, not to use it better. The logic suggests that the more tasks the agent completes, the more value you are extracting from your credit investment, except that is backward. The value isn't in action volume. The value is an outcome efficiency. A team that uses agents for 30% of their work, but see significant improvement per action is getting better ROI than a team using agents for 70% of their work with marginal gains. But the consumption model doesn't incentivize that distinction. It incentivizes volume, use more agents, automate more tasks, spend more credits. Because the more you use the system, the more value you are supposedly extracting, measured purely in terms of work automation rather than business outcome. This creates a perverse dynamic. Teams optimize for agent utilization instead of for outcome value. They look for additional tasks to automate rather than better ways to automate existing tasks. The agent becomes a tool to consume credits, instead of a tool to create value, which is precisely why governance and measurement have to be designed together from the start. You can't separate the cost model from the value model, you can't deploy agents and then bolt on ROI tracking later. The incentive structure of the system needs to point toward value creation, not toward consumption volume, otherwise you will optimize in the wrong direction. The governance operating model rolls and approval gates. Governance isn't a compliance checkbox, it's an operating model. Most organizations are trying to govern agents without actually redesigning how decisions get made, and that's where the model breaks. You need defined roles, not informal, not will figure it out. You need explicit roles with clear authority and accountability. First, you need an AI owner. This is someone from the business side who's responsible for whether the agent actually solves the problem it's supposed to solve and whether the investment is justified. Then you need a technical owner. They handle the implementation, the configuration, and the day-to-day operation. Finally, you need a risk and compliance owner. Their job is to ensure the system doesn't expose the organization to regulatory security or operational risk. These aren't just IT roles, they're cross-functional. The AI owner might be from the department deploying the agent while the technical owner is in IT, and the risk owner is shared between compliance, legal, and security. These roles matter because they create decision accountability. When something goes wrong, you know who owns it. When a cost question arises, you know who answers it. When a risk decision needs to be made, you know who has the authority to make it. Once the roles are set, you build an approval gate for new agents. But here's the thing, it's not a single gate. It's a structured process that gates complexity proportionally. It starts with a use case submission. The team proposing the agent documents what problem it solves, who it affects, what data it will access, and what actions it will take. That submission goes to risk classification. You have to decide if this is low-risk, medium-risk, or high-risk based on the EUAI Act categories and your own risk appetite. If it's low-risk, like drafting meeting notes or summarizing content, it moves fast through the next gate. Technical review confirms the configuration is secure, and the data access is scoped correctly, and then it gets approved. High-risk agents need a different gate entirely. If the agent is screening job candidates, evaluating employees or making credit recommendations, it's not moving fast. It needs a fundamental rights impact assessment, which the EUAI Act calls a FRAIA. You have to ask, what's the potential for the system to discriminate? What's the potential for it to cause harm? How will you detect if it's doing either? You need human in the loop design documented before the agent goes live, and you need escalation rules explicitly defined. You need evidence that you've tested the system for bias and accuracy, and you need proof that a human will review outputs before they affect decisions. Low-risk agents can move faster, but they still need monitoring. You're not approving them once and forgetting about them. You're approving them for pilot operation with the understanding that you'll monitor usage, cost, and behavior after 30 days you reassess. Is it solving the problem? Is it staying within budget? Are there incidents? If the answer to those questions is yes, you can move it to a broader rollout. Beyond the approval gate sits the Central AI governance board. This isn't just ITO compliance. It's a cross-functional committee with representation from IT, business, legal, security, compliance, HR, and finance. This board doesn't approve every agent. The approval gates handle that. But the board sets policy. It defines risk appetite. It reviews incidents. The operating rhythm matters. You need monthly reviews of agent usage, cost, and incidents. You pull the data to see which agents are consuming the most credits, which teams are using agents most heavily, and which agents are generating the most incidents. These monthly reviews aren't for punishment, therefore learning. You need to know which agents are delivering value and which ones are burning credits without any equivalent benefit. Then you need a quarterly reassessment of risk classification. An agent that was low risk six months ago might have drifted into medium risk territory as teams extended its capabilities. And that means you might need to add additional oversight or constraints. Finally, you need killswitch procedures. How do you disable an agent in 60 seconds if it's misbehaving? Not tomorrow, not after a meeting. 60 seconds. That requires clarity. You need to know which person can activate the kill switch and whether it requires a single authorization or two sign-offs. When an agent is sending unapproved emails or accessing restricted data, you don't have time to figure out the shutdown process. You need to execute it immediately. This isn't bureaucracy for its own sake. This is the operating structure that separates organizations that actually govern their agents from organizations that deploy them and hope nothing goes wrong. And by August of 2026, hoping nothing goes wrong is no longer a viable governance strategy. The inventory and discovery problem, cataloging shadow AI. You can't govern what you don't know exists. This is the gap that kills most governance programs before they start. Right now, in your organization, agents are running. Not all of them are sanctioned. Not all of them are visible to IT or compliance. Some are built by teams using co-pilot studio, some are power automate flows that trigger autonomously based on conditions nobody documented, some are custom integrations connecting systems that weren't supposed to talk to each other. They're all operating. They're all consuming resources. They're all making decisions. And your IT team has no idea they exist. This is shadow AI. And it's the precondition for every governance failure. The discovery process is where that changes. It's not quick. It's not glamorous. But it's non-negotiable. Start with what you can see. Ordered your power automate environment and pull a report of every flow that has an AI connector or invokes co-pilot. Document each one. You need the owner, the purpose, the data sources, and the tools it invokes. Do the same with co-pilot studio agents. Any custom agent, anybody has built, needs to be documented the same way. Then expand outward to custom integrations and third party AI tools your teams might be using like Zapier with AI connectors or custom scripts calling OpenAI APIs. Anything that's performing autonomous work needs to be on the list. This discovery phase will be uncomfortable. You'll find agents that violate your policies. You'll discover workflows that shouldn't be running in production. You'll uncover tools that create compliance exposure. Your first instinct will be to shut them down. Don't. Not yet. Visibility comes first. Understanding comes next. Enforcement comes later. Once you've cataloged what exists, you classify. Each agent gets a risk assessment. Is it minimal risk? Is it limited risk? Is it high risk? Or is it prohibited because it violates policy outright? Then you map to business outcomes. Every agent has a reason for existing. It's solving some problem or filling some gap. The agent that nobody's heard of, the one running in a corner of the marketing department is probably solving a real problem for someone. Understand what that problem is. Understand what value the agent is creating. This isn't bureaucratic questioning. It's understanding whether the agent deserves to keep running. Next systematically bring shadow agents into the governance process. You're not shutting them down because they weren't approved. You're saying, we found this. We understand what it does. It's now part of our managed portfolio. This converts shadow AI from a liability into a managed asset. The final step is operational discipline. You can't do this once and forget about it. Agents are deployed continuously. Teams keep building new workflows. New tools get adopted. Your inventory goes stale in weeks if you don't maintain it. Establish a quarterly review cycle. Every three months, you pull the current inventory and assess what's new. You identify what's been deprecated. You reclassify agents if their risk profile has changed. You look for drift. Agents that are being used for purposes beyond their original design. The inventory isn't a static document. It's a living record of what autonomous systems are operating in your organization. Once you have visibility, you can start enforcing controls. The technical controls layer, enforcement and guardrails. Documents are fine. Policies are necessary. But governance documents don't stop an agent from doing something destructive. Only technical controls do. This is where most governance programs fail. They build the framework. They define the rules and they publish the policies. Then they just rely on people to follow them. But agents don't read policies. They follow what the infrastructure allows. If the infrastructure doesn't enforce the rule, the rule doesn't exist. Policies code changes that. Instead of writing guidelines in English and hoping teams interpret them correctly, you embed governance into the systems themselves. You use antireconditional access policies to control when agents operate. You set up DLP rules to inspect agent outputs before they leave the organization. You build information barriers to prevent agents from crossing departmental boundaries. These aren't suggestions. They're enforced at the platform level. Agent permissions must follow a least privileged design. The agent gets access to exactly the tools and data it needs to finish its task. And nothing more. A scheduling agent doesn't need access to email. A document summarization agent doesn't need to modify files. And a candidate screening agent doesn't need calendar permissions. Each agent is scoped tightly around its specific purpose. You aren't granting broad access and trusting the agent to use it wisely. You're restricting access by default and opening only the specific pathways the agent requires to function. Spending limits become hard constraints, not budget guidelines. Every agent gets a monthly credit allocation. If an agent is budgeted for $2,000 a month in co-work consumption, that is the ceiling. It's not a target. It's not a suggestion. It's a hard limit. The agent can spend 1,500 one month and 500 the next, but it can never exceed that $2,000 total. The billing system enforces this limit automatically before the agent can go over. You can figure alerts at 50%, 80% and 100% of the budget. When spending approaches the limit, someone gets notified. When the limit is reached, the agent enters a restricted mode or stops operating until the next month starts. Approval workflows add gates to high-risk actions. Certain operations require human authorization before the agent can execute them. An external email requires approval. A file deletion requires approval, a data export, or a financial transaction above a certain threshold requires approval. The agent doesn't just do the action and report the outcome. It creates a request, a human reviews it, and only after explicit authorization does the agent proceed with the entire transaction. The request, the review, and the decision is logged and auditable. Real-time monitoring and dashboards give you continuous visibility into what agents are doing. This isn't a weekly report. These are live dashboards showing credit consumption by agent, by team, and by use case. You can see which agents are active right now, and which ones are consuming the most credits today. You can see which ones are operating outside their normal behavior patterns. These dashboards feed into your operational discipline. You aren't waiting for a bill at the end of the month to understand what happened. You're watching it happen in real time. A normally detection is the automated version of that monitoring. Machine learning models establish a baseline of normal agent behavior. Usually an agent operates between 8am and 6pm, called specific tools in a specific sequence, and consumes about 500 credits per day, when behavior deviates from that baseline. Like an agent operating at midnight or calling tools, it has never used before. The system detects the anomaly and escalates it. This isn't a warning. It's an immediate alert requiring investigation. Kill switches give you the ability to disable an agent or revoke its permissions in seconds. This doesn't happen through a request process or a change management workflow. A single authorized person can flip a switch and the agent stops operating. Its entry identity is disabled, its permissions are revoked, and its access to tools is cut off. The agent becomes inert. This isn't something you design and hope you never use. This is something you test regularly so that when an agent behaves unexpectedly or accesses data, it shouldn't. You can execute it immediately without hesitation. These controls shift governance from a compliance exercise into an operational reality. The rules are enforced. The limits are hard. The visibility is continuous. That's what actually working governance looks like. The human oversight problem, article 14 and real oversight. The EU AI act requires something called meaningful human oversight. That phrase is doing a lot of work. Most organizations interpreted as a checkbox. You document that humans reviewed something and then you move on. That's not what the regulation actually requires. Meaningful oversight isn't a policy. It's an operating procedure. It means humans actually understand the system. They monitor what it's doing in near real time. They can intervene and stop it before harm occurs. They have the authority and the information to override the agent's decision. That's the baseline. Everything else flows from that at the high risk level. Agents that affect employment, credit, or access to services. Meaningful oversight means humans' review outputs before they go out. A hiring agent scores candidates. Before any candidate gets rejected or moved forward based on that score, a human reads the assessment. The human understands how the agent arrived at the score and can question it overrided or asked for a rescore. That human review isn't optional. It's a design requirement. For medium-risk agents, sampling-based review works. You don't review every output, but you review 10% and look for patterns. You check if the agent is consistently biased or if it's missing important context. Sampling gives you continuous validation that the system is behaving as expected. You also have alerts on anomalies. If the agent's behavior deviates from normal patterns and alert fires and that specific output gets human review immediately. For low-risk agents. Like content generation or routine automation, you move to automated monitoring with human escalation. The system watches the agent continuously. If credit consumption spikes unexpectedly or if the agent starts accessing data outside its normal scope, the system escalates to a human. The human then decides whether to investigate further or to shut the agent down, but oversight requires capability. It requires humans who actually understand what they're overseeing. This is where training becomes non-negotiable. Teams using agents and teams supervising them need to understand what the agent is supposed to do and what could go wrong. This isn't a one-hour onboarding video. It's ongoing training. New people need foundational training and existing users need refresher training when the agent is updated or when new edge cases emerge. The training covers the agent's purpose, its limitations and its failure modes. Teams need to know what is outside the agent's scope and what could make it produce bad output. They need to know what happens if data quality is poor or if the agent encounters a situation it wasn't trained for. You can't supervise something you don't understand. The escalation path is the operational reality of oversight. It's not just escalate to compliance. It's a clear documented path. You need to know when an issue goes to the technical owner versus the business owner or the IT security team. Different issues root to different places. A cost anomaly roots to the cost owner while a suspected bias issue roots to the AI governance board. A security incident roots to the CSO and a potential regulatory violation roots to legal. You're not creating chaos. You're creating clarity about who handles what and how fast. Real oversight also means continuous visibility. This isn't just for when something breaks. You need dashboards showing what the agent is doing and reports on its performance and cost efficiency. You need quarterly reviews where you look at patterns and ask if the agent is still delivering value. You ask if there are new risks to address or if you should adjust its constraints. This infrastructure. Understanding monitoring, training and clear escalation is what separates governance theater from actual governance. Without it, meaningful human oversight is just words in a compliance document. With it, you have a real operating system that keeps autonomous agents bounded within the authority you granted them. It catches problems before they become incidents. That's what August 20, 26 demands. Not the process of oversight, the actual capability to intervene and the demonstrated discipline to do it. The organizational change management problem. Adoption without chaos. Agents change how work gets done. That is not a technical change. It is an organizational one. Most deployments fail because they treat this like a feature rollout. They assume it is just another tool, but in reality, it is a fundamental shift in how your operation actually runs. The classic mistake is the big bang. You build your governance framework and stack up your controls. You decide the system is ready. Then you flip a switch and turn on co-work for the entire company on a Monday morning. By Wednesday, you are drowning. People do not understand what the agent is supposed to do so they use it for tasks it was never designed for. They escalate non-issues. They get frustrated because the agent did not meet their unspoken expectations. While this is happening, your IT team is overwhelmed. They are trying to explain the system while simultaneously fighting fires from agents behaving unexpectedly at scale. That path does not work. You need a phased approach where every step has different success criteria. The first phase is the pilot. You pick a narrow use case with a concrete measurable outcome. Maybe you choose one specific department or a single workflow. You are not deploying agents broadly yet. You are deploying them precisely to test if the model actually works before you even think about scale. This pilot runs with heavy monitoring. You watch everything. You look at which users are adopting it and how often they engage. You check if they are seeing the time savings you predicted or if they are hitting errors. The pilot phase usually lasts 30 days. During this time, you gather data and watch behavior to see where adoption stores and why. At the end of those 30 days, you measure three things. First, adoption. If fewer than 45% of your target group is using the agent, you have an adoption problem, not a capability problem. Something about the positioning is not resonating. Second, errors. You need to know if the agent produced wrong outputs or made decisions people disagreed with. These errors are just information. They tell you which constraints are missing. Third, value. Is the agent delivering the productivity you expected? If the metrics do not show real gains, expanding the program will not fix it. When the pilot succeeds, you move to phase two. Expand. You take your lessons and adjust the agent's behavior. You move into more teams and add new use cases based on what worked. Phase two typically runs for 60 days. You are still monitoring heavily, but now you are adding scale. You look for patterns that did not show up in the small group. You train teams as you bring them on and adjust your governance based on how the agent behaves at a larger volume. Only after both phases succeed, do you move to phase three. This is the broad rollout. You are finally scaling to the organization, but you are scaling into mature governance and support structures. You are not scaling into chaos. You have a control plane and oversight mechanisms. You have training ready for incoming teams and a support model that can actually handle the volume. Throughout this progression, you are building organizational capability. Teams learn what agents can and cannot do. They start to understand the limitations. They know how to override a recommendation when it does not fit their context. They stop treating the agent as a magic box. They start treating it as a tool with specific purposes and specific constraints. Set the right expectations from day one. Agents augment work, they do not replace judgment. They handle routine tasks so humans can focus on decisions that require reasoning. Frame it that way and the conversation shifts. It stops being about, we are being replaced and starts being about, we can finally focus on what matters. Do not skip the phases. Do not scale before your governance is operational. That is how you turn a successful pilot into an organizational catastrophe. The consumption trap. Why more usage doesn't mean more value. There is a structural trap that most organizations fall into, the moment they move to credit-based billing, the economic incentive is now inverted. With seats you pay for access. You buy 500 licenses and your goal is to make sure people use them because the cost is already sunk. Your incentive is adoption. You drive usage up so you are not wasting the money you already spent. With credits, the dynamic flips, you are paying for action. Every time the agent does something, you spend money. More usage equals more spend. This means your incentive should shift toward value efficiency, not usage volume. You want to use agents where they create leverage and avoid them where manual work is faster. But here is the problem. Nobody has designed their incentives that way. Teams still think like they are in the old model. What actually happens is this. A team gets access to co-work and looks at their daily tasks. They ask what they can automate. They identify 20 tasks and start building. Pretty soon the agent is handling 60% of their daily work volume. The team feels productive. The organization seems happy, usage is high, but there is a problem that nobody is measuring. The team might be experiencing zero time savings, not all work is created equal. Some tasks are genuinely better when they are automated. They are repetitive, data heavy, and do not require judgment. An agent handling those is a win. It saves time and the cost per hour of labor eliminated is favorable. Other tasks are different. They are faster to do manually, or they require judgment and agent cannot replicate. An agent handling these tasks actually waste time. The human has to review the work and often redo it, which is slower than just doing it themselves the first time. When a team uses agents indiscriminately, they apply automation to everything. They burn credits on low value work. The agent completes the task, but it costs more than the manual labor would have. The team thinks they are winning because the agent is handling more work. They are not. They are just spending more credits without generating value. This is the consumption trap. Credits incentivize usage, but usage does not equal value. A team using agents for 30% of their work on high-level tasks might get triple the value of a team using them for 60% of their work indiscriminately. The metric that actually matters is the cost per unit of value. It is not about cost per task or agent utilization. It is about the cost per resolved ticket, the cost per document drafted, or the cost per hour saved. You have to measure the cost to achieve an outcome with the agent versus the cost without it. That delta is your actual value. Imagine a team processing customer support tickets without agents, a ticket takes 45 minutes and costs $20 in labor. The team handles 20 tickets a day, which puts the daily labor cost at $400. Now you deploy a co-work agent to handle triage and draft responses. In the first scenario, the agent reduces the human time to 20 minutes per ticket. That labor now costs $9. The agent's work costs $2.50 in credits. Your total cost per ticket is $11.50. You are saving $8.50 on every ticket. Over 20 tickets that is $170 in daily savings. Now look at a different scenario. The agent handles triage, but the team also uses it for low-value tasks like refraising emails or generating summaries nobody reads. They are using it more but not on the right work. The labor time only drops to 35 minutes because the human is still doing the heavy lifting. The agent's work now costs $5 in credits per ticket. Your total cost is $15.75. You have not actually saved anything. You have just made the process more expensive. Same tool, same team, same capabilities. One is using it for value, the other is using it for volume. The difference comes down to discipline. You have to answer which tasks the agent should handle before you turn the feature on. You cannot wait until you are reviewing the bill at the end of the month. The trap is that the credit model does not enforce this discipline for you. It does the opposite. It encourages you to automate more and burn more credits. The more you use the system, the more you feel like you are getting your money's worth. But you are not. You are just spending. This is why you need a cost model in place before you ever deploy at scale. Building the cost model. Forecasting and budget planning. You can't budget for something you don't understand. And right now, most organizations can't forecast their co-expend because they haven't built the model that makes it visible. The math here is actually straightforward. It's the discipline that matters. Start by looking at how your people actually work. You aren't guessing. You're observing. You need to know which roles use co-work the most. An executive might call on an agent five times a day for quick tasks or decisions that need fast execution while an analyst might use it 20 times because their work is data heavy and repetitive. A customer service rep might hit 15 uses a day to process high volume, but a success manager might only need it three times. The pattern isn't the same across the company. It breaks down by persona and workflow. Once you have that baseline, you segment by task complexity. Not all co-work tasks are equal, a light task. Like summarizing an email chain costs about 135 credits. You're just pulling one stream and analyzing it. It's quick and bounded, a medium task, like building a meeting agenda from your calendar emails and docs costs about 500 credits. The agent is doing real work here. It's gathering data from multiple sources and synthesizing it into a structure. A heavy task, like analyzing last quarter's churn trends and drafting retention talking points, starts at 1,500 credits. The agent is reasoning, not just retrieving. It's working with large data sets and generating structured output. Now look at the distribution. In most organizations, the work isn't balanced. Most of it is routine. You can usually expect 60% light tasks, 30% medium and 10% heavy. Your specific organization might be different, so you should check with the teams using the system, but that 60, 30, 10 split is a solid place to start. To find your average cost per task, multiply each tier by its percentage. 60% of 135 is 81. 30% of 500 is 150. 10% of 1,500 is 150. When you add those up, you get 381 credits per task. Let's call it 400 to account for the variations. Now multiply that by your usage. If you have 100 users doing 10 tasks a day at 400 credits each, that's 400,000 credits every single day. Over a 30-day month, you're looking at 12 million credits. Add a penny per credit, your raw consumption is $120,000 a month. But you have to add a buffer. Organizations almost always underestimate usage at the start because teams find new use cases and power users adopt heavier patterns. Add 20% for safety. Your real forecasted spend is $144,000 a month. But here's the step nobody actually does. You have to validate that against business value. The assumption is that agents save time. If each of those 100 users saves just 10 hours a month, that's 1,000 hours total. If your loaded labor cost is $75 an hour, you're saving $75,000 a month. Wait, your spend is $144,000. Your value is $75,000. The math doesn't work. Something is wrong with the model. Either your usage estimates are too aggressive, your productivity gains are too optimistic, or you're deploying to the wrong people. You have to go back and recalibrate. Maybe the actual usage is six tasks a day, or maybe you only deploy to 60 high value users instead of 100. The point is, you're testing the model before you commit the money. You're forcing the value hypothesis to be explicit. You aren't just assuming agents pay for themselves. You're proving it. Once the spend is justified, you have a baseline. Now you can plan in stages. Pile it with one persona this quarter and validate the model. Expand to the next persona next quarter and keep validating. You aren't deploying at scale based on a theory. You're deploying incrementally based on evidence. That is how you build a cost model that actually works. The procurement and vendor strategy, licensing, commitments and negotiation. The way you buy credits matters more than you think. It isn't because the price per credit changes that much. It's because the terms you accept shape everything that happens next. You need a strategy before you ever sit down to negotiate with Microsoft. Credits come in three models. You need to understand each one to know which mix to use. Pay as you go is your flexible option. You don't commit to anything and you get billed monthly for what you actually used. You're paying the full list price of one cent per credit but you have total freedom. If a project ends or you need to scale down, there is no penalty. This is the right choice for experiments or teams that can't forecast their consumption yet. Pre-purchase plans or P3 are the opposite. You commit to a block of credits upfront for a year to get volume discounts. At 300,000 credits, you get 5% off. At 300 million, that discount hits 20%. Large enterprises can often negotiate another 10 or 15% on top of that. But here is the catch. You're buying a fixed pool. If you don't use those credits by the end of the year, they expire. They don't roll over. They're just gone. You are betting on your forecast. Capacity packs sit right in the middle. You buy a fixed allocation of interactions. Usually 25,000 a month and it renews monthly. It's more stable than pay as you go but you don't get the deep discounts of a P3 commitment. Most mature organizations use a hybrid approach. They buy a capacity pack for their baseline. The work they know they'll do every month. They layer a P3 commitment on top for their expected growth. Then they keep pay as you go, enabled for the overflow. When the baseline hits the cap, it pulls from P3. When P3 is empty, it's built to pay as you go. The economics work because the bulk of your work is covered by discounts. But you aren't penalized for growing faster than expected. Negotiation is where your leverage lives. Most organizations just accept the published pricing. They shouldn't. If you have 500 or more co-workers, you are a material part of Microsoft's revenue for this product. They want your multi-year commitment because it gives them predictability. That is your negotiating room. Benchmark your usage against the discount curve. If you're forecasting 5 million credits a year, you're already in discount territory, but enterprise customers can often push for 25% off the list price. Ask what the volume pricing looks like and don't assume the first number they give you is the final one. The contract terms matter just as much as the price. You need to clarify what happens if you go over your P3 commitment. Does the price jump back to the list rate or stay at your negotiated rate? Ask if unused credits can carry forward if you're showing a clear growth path. You also need to know the renewal timeline and if there's a minimum size for the next year. Finally, remember that vendor lock in is real. Co-pilot credits are specific to Microsoft. If your entire business becomes dependent on this specific model, your switching costs will be astronomical. That doesn't mean you avoid the commitment but it does mean you should build redundancy where it matters. If a critical workflow depends entirely on co-work, you're exposed. If that same workflow could run on Azure OpenAI or another tool if needed, you've protected yourself. The procurement decision isn't just a financial one, it's architectural. What you buy determines what you can deploy and how trapped you become, sir. The implementation timeline, 90 days to August 2026. The math is brutal. You have roughly 90 days before the high risk rules of the EUAI Act become enforceable. That is not a long runway, but it is also not impossible. If you move fast and stay disciplined. Here is what the timeline looks like when you execute it properly. Weeks one and two, inventory and discovery. You are cataloging everything, every power automate flow with an AI connector, every co-pilot studio agent, every custom integration calling OpenAI APIs, every third party tool your teams adopted without asking. You are not making judgments yet, you are collecting data. Document the owner, the purpose, the data sources and the tools it invokes. This phase is exhausting because you are finding things nobody knew existed. And that is the point. Shadow AI stops being shadow the moment you put it in a spreadsheet. Weeks three and four, risk classification. Each agent gets evaluated against the EUAI Act categories. Is it minimal risk, limited, high-risk, prohibited, map it explicitly? If an agent is screening drop candidates or evaluating employees, it is high-risk if it is just drafting meeting notes. It is low-risk. If it is handling customer communications, it is limited risk and requires transparency. You are building the risk register that becomes the foundation for everything else. Do not rush this. Misclassification creates compliance gaps that you cannot easily close later. Weeks five through eight, governance design. Define the structure, who makes agent approval decisions, who owns the overall AI governance, which roles handle the escalations, what does the approval gate actually look like? Design the monitoring dashboards. Decide which metrics matter and how you will track them. Define the technical controls. What permissions will agents have? What approvals are required before an agent takes action? What are the kill switch procedures? Write the policies. But not as thick legal documents. Write them as operating procedures. How do we actually do this work? Weeks nine through 12, technical implementation. This is infrastructure. Deploy agent 365 and configure EntraID to treat agents as first class identities. Configure DLP policies explicitly for co-pilot and agent outputs. Setup conditional access rules that enforce least privilege. Build the logging infrastructure. You are not using Microsoft Perview logs alone. You are building a separate layer that captures agent-specific metadata, which agent, which model, which tools, which daughter, and the decision reasoning. This layer feeds directly into your audit and compliance framework. Weeks 13 through 16, pilot and validation. You are not scaling yet. You are proving the model works. Select a small group of high-risk agents or a focused use case. Deploy into the governance environment you just built. Monitor heavily. Measure adoption rates are people actually using it. Track errors. Is the agent producing outputs people trust? Measure outcomes. Is the promised value materializing? Document everything. Every incident. Every work around. And every unexpected behavior becomes input for the next phase. Weeks 17 through 20. Remediation. The pilot revealed what did not work. So fix it. If the logging infrastructure is not capturing the right data, rebuild it. If the approval gates are slowing things down too much, streamline them. Teams do not understand the governance model. Revise the training. If certain agents are hitting edge cases, update the decision logic. Governance improves through iteration, not through perfect design on day one. Weeks 21 through 24 and beyond scale. Now you are expanding agent deployments incrementally. One new team per week, one new use case per sprint, maintain the monitoring discipline. Keep refining based on what you are seeing at scale. Establish the quarterly review cycle, monthly reviews of usage and cost. Quarterly reassessment of risk classification. Governance is not something you finish. It is something you maintain. By August 2nd, 2026, you need to be able to demonstrate compliance, not just aspire to it, demonstrate it. You have documented risk assessments for your high-risk agents. You have audit trails, capturing decisions and approvals. You have governance procedures that are actually being followed. You have evidence that humans are meaningfully overseeing the systems. You have technical controls enforcing the boundaries you set. You do not have perfect governance. But you have working governance that is auditable and defensible. But here is the reality most organizations do not want to hear. The co-pilot credit trap is not the credits themselves. It is the assumption that you can deploy autonomous agents into an unprepared organization and just pay for what you use. You cannot. The structure does not support it. Your data governance is weak. Your identity model is broken. Your audit trails do not exist. Your cost model is guesswork. By August 2026, if you have not built the governance layer, you are not just overspending. You are exposed. Regulators will ask for evidence, and you will not have it. Start now. And if you want more of this, follow me on LinkedIn.