Why Copilot for M365 No Longer Works for Me — And How Codex + Computer Use Replaced My Workflow
An Honest Opening
I can’t remember the last time I actively opened Excel, Word, or PowerPoint.
Not an exaggeration. Not “I try to use Office less.” I mean zero — in the past several months, I haven’t double-clicked a single Office icon. Files are still being created, reports are still being generated, but the muscle memory of “New → Blank Workbook” has completely disappeared from my daily routine.
And here’s the second confession: I stopped renewing my Copilot for M365 subscription too.
This isn’t a hit piece against Copilot — Microsoft has invested a staggering amount into this product, and it genuinely improves productivity for many people. What I want to say is this: for someone who has rebuilt their workflow around Codex + Computer Use, Copilot fell into a position where it no longer makes sense. And that position might arrive sooner than many people expect.
The Core Challenge
Let me explain my current workflow first:
- Codex CLI — an autonomous coding agent that works in the terminal. I tell it what I need, it writes code, debugs itself, and runs it — all without my intervention.
- Computer Use — lets AI operate any software on my Mac. Browsers, IDEs, productivity tools, even system settings. It sees the screen, moves the mouse, and types.
Together, these form a superset: anything that can be done through “read → think → act” can be handed off. Office files are just one category.
Point-by-Point Comparison
What Copilot Promises
Copilot for M365 (the $30/user/month add-on) sells on several key capabilities:
- In-app content generation — write in Word, analyze in Excel, build slides in PowerPoint
- SharePoint/OneDrive integration — search and reference your enterprise document libraries
- Teams meeting summaries — auto-generated minutes and action items
- Natural-language enterprise data queries — “Find last quarter’s sales for the East region”
- Copilot Studio agents — low-code conversational bots for business processes
- Business Chat (BizChat) — cross-app task completion in a single conversation
What Codex + Computer Use Does Instead
Office Content Generation
Copilot: Opens a sidebar inside your Office app. You describe what you want, it generates inline.
My approach: “Codex, generate a Q3 project status report with the following data… output as .docx.” Codex calls python-docx, writes the script, populates the data, produces the file. Excel? Same pattern with openpyxl or pandas.
The difference: Copilot’s output is bounded by its built-in prompts and model limits. Codex has no such boundary — it can pipe data through arbitrary transformations, pull from multiple APIs, apply complex conditional formatting, and upload the result somewhere else. It’s not an “assist with writing” tool — it’s a worker that completes the entire production pipeline.
SharePoint/OneDrive Access
Copilot: Connects via Graph API to let you search and reference documents through conversation.
My approach: Codex calls the SharePoint REST API or Microsoft Graph directly — the same underlying interfaces. Or simpler: use curl, rclone, or the OneDrive SDK. And Computer Use can open the browser or Finder and navigate to the SharePoint page directly.
The reality: SharePoint’s built-in search is already excellent — metadata filtering, content type filtering, precise keyword and property search. The real problem isn’t “search isn’t powerful enough,” it’s “users don’t know how to search effectively.” Someone who struggles with keyword search will struggle just as much with natural language search — their ability to describe what they need determines the accuracy of results. Training every employee to become an advanced search user is cost-prohibitive and impractical. Power users who already know how to navigate SharePoint efficiently don’t need AI-assisted search — they already have their methods.
And when your workflow shifts from “browsing documents” to “having an AI agent run tasks for you,” the value of conversational search shrinks further. I don’t need to “find the document and show it to me” — I need to “find the specific data inside the document and feed it into the next process.” Codex searches natively, results go directly into variables, not into human eyes.
Teams Meeting Summaries
Copilot does this well. But alternatively: Teams exports meeting transcripts (.vtt or .docx). Feed the transcript to Codex, it generates summaries, categorizes action items, or merges points across multiple meetings. A cron job connected to the Teams Graph API can do this automatically.
Enterprise Data Queries
Copilot: “Find all customers from last quarter with over $500K in East region sales.” Copilot connects to Dynamics 365 or configured data sources.
My approach: “Codex, query the PostgreSQL database for last quarter’s East region sales, aggregate by customer, give me a table.” Codex writes the SQL, executes it, returns results. Or if the data is in Excel files, read them directly.
The difference: Copilot’s queries are limited to Microsoft ecosystem data sources. Codex connects to anything — SQL databases, REST APIs, CSV files, web scrapers, Odoo, WordPress databases — and can join across data sources. Codex not only reads but also writes — completing the query, updating systems, sending emails, generating reports in one flow.
The Fundamental Difference: AI Assistant vs. AI Worker
Copilot paradigm: AI Assistant
- You work, it helps
- You’re in the app, it’s in the sidebar
- It generates content, you judge and operate
- Its answer: “What do you need?”
Codex + Computer Use: AI Worker
- You tell it what result you want, it does everything
- It operates applications, you do other things
- It handles the entire pipeline from data acquisition to file generation to deployment
- Its answer: “I’ll handle it”
Copilot augments your capabilities as an information worker. Codex + Computer Use performs the information work for you.
One is an accelerator. The other is autopilot.
Evaluating Copilot’s Latest Evolution
(I should note: I haven’t trained or seriously tested Copilot in a while. The following is based on what I could research.)
What Microsoft Has Been Shipping
SharePoint Copilot Apps (July 9, 2026 — public preview) This goes beyond conversational search. It lets developers build interactive applications within the Copilot canvas — approval forms, data grids, multi-step tickets — running directly inside Copilot chat. Built on SharePoint Framework (SPFx) 1.24. Microsoft calls it “from intent to outcome.”
Building Agents for Teams (July 14, 2026) Embedding agents directly into Teams conversations.
Work IQ Developer Tools (preview) Tools for building more complex workplace scenarios.
Practical Assessment
These directions sound promising on paper, but the real-world usability raises several questions:
The barrier to entry. SharePoint Copilot Apps requires proficiency in SharePoint Framework (SPFx), Web Components, and TypeScript — a complete modern front-end development stack. For the average knowledge worker — Copilot’s primary target audience — this is an insurmountable barrier. Microsoft’s response has been “use AI coding tools to generate these components” — which essentially punts the problem back to a more powerful AI agent than Copilot itself. There’s a clear paradox here: to use Copilot’s new features, you may need a more capable AI tool than Copilot.
Value density. Does an interactive approval form really need to run inside Copilot? The typical workflow is: receive a Teams notification → click a link → approve in a web page. Porting this into an SPFx component inside the Copilot canvas adds development and maintenance overhead without shortening the user’s actual journey. I understand Microsoft’s strategic goal of making Copilot the “work center,” but from a practical standpoint, the marginal benefit for many scenarios is very thin.
Tenant-level deployment complexity. SPFx components must be packaged, deployed to the SharePoint App Catalog, and assigned permissions — this is enterprise IT governance, not something an individual user can accomplish. Microsoft says “any developer can do it,” but there’s an entire IT department between “developer” and “Copilot user.”
Teams Agent reality. Embedding an agent in a Teams conversation looks natural, but if it can only answer from a predefined knowledge base, it’s essentially a search function with natural language wrapping. Real value comes when agents can take action — write to databases, initiate approval workflows, operate external systems. Copilot Studio’s custom connectors partially enable this, but the configuration complexity and maintenance cost far exceed simply asking Codex to write an integration script.
Can These Updates Challenge My Conclusion?
Honestly, yes and no.
Where they could: Copilot is genuinely addressing the “chat cannot do structured operations” problem. If the SPFx ecosystem takes off, Copilot would evolve from a “smart sidebar” into a “workbench.” That’s a meaningful direction.
Where they fall short: These new capabilities essentially shift development complexity into the Copilot experience — you need SPFx, you need Web Components, you need Microsoft Graph knowledge. This isn’t “product feature enhancement”; it’s offloading platform development onto the user. Meanwhile, Codex can generate these same components and isn’t limited to SharePoint — it operates everything.
A Deeper Contradiction: Agents Should Get Simpler, Not More Complex
If you look at where AI agents are trending, several consensus directions emerge:
- Unified entry point: Users shouldn’t need to know how many agents are behind the scenes, or which agent handles what. They should express their need in one conversation window, and the system routes and coordinates everything.
- Natural language as the interface: AI interaction converges on “just speak or type” — not learning new UIs, new configuration panels, new development tools.
- Autonomous adaptation: A good agent system should figure out what tools to use, what data to access, which APIs to call, without the user manually telling it “first connect to SharePoint, then find this, then configure that.”
But Copilot for M365’s latest trajectory runs in the opposite direction:
- SharePoint Copilot Apps → you need to learn SPFx development
- Copilot Studio → you need to learn Topic/Entity/Trigger configuration models
- BizChat → simple, but limited in capability
- Teams Agent → yet another configuration surface
Every new capability increases the product’s surface area — new terminology, new configuration panels, new development flows. Users aren’t using a conversational assistant; they’re managing a “Copilot application ecosystem.”
This reminds me of early Salesforce — evolving from a CRM into a platform ecosystem requiring administrators and developers. Great for enterprise extensibility, but for individual users, the learning curve keeps getting steeper.
I lean in the opposite direction: a true AI agent should have a single entry point — you tell it what you want, and it figures out how to do it. I don’t need to know whether it uses the SharePoint API or reads the filesystem directly, whether it calls SPFx components or opens a browser — just like I don’t need to know how elevator cables work.
In this logic, every “major update” to Copilot pushes it further away from what I need. Codex + Computer Use does the opposite — the entry point is trivially simple (a terminal, one sentence), and the capability boundary is expanded by the agent itself.
Copilot makes you stronger. Codex makes it so you don’t need to be.
An Uneven Comparison
I should be honest: this comparison is unfair in some ways.
- Copilot for M365 is a product for knowledge workers. Its target users are people who work in Outlook, Teams, and Word every day — sales, HR, project managers. For them, “generating text in a sidebar while writing a document” is a genuine productivity leap.
- Codex + Computer Use is a paradigm for developers (or those willing to let AI replace the developer role). The barrier is higher — you need to describe requirements clearly, be comfortable with code as an intermediate artifact, and tolerate occasional failures.
I happen to sit in a specific position: I have a technical background, but most of my time isn’t spent on traditional “development” — I work on technical marketing, content strategy, and project management. This puts me in a sweet spot where I both understand Codex’s capabilities and have enough “non-development” work for it to handle.
Once you cross this line, going back to Copilot feels like comparing a Swiss Army knife to a CNC machine — fine for small repairs, but for real production work, you don’t reach for the pocket knife.
Conclusion
Copilot for M365 is no longer useful for me, not because it’s a bad product, but because I changed my tool paradigm entirely.
It’s like someone who switched from a bicycle to a car, then said “walking doesn’t work for me anymore.” To someone who still walks, this sounds ridiculous. But once you’re behind the wheel, it’s simply the truth.
If one day Copilot becomes a truly unified entry point — giving you natural language to accomplish anything without configuration panels and development frameworks — it might find its way back into my toolbox. But right now, it’s on a trajectory of increasing complexity and platform sprawl.
And I’ve already taken a different road.
P.S. This is entirely based on my personal workflow and experience. If Copilot for M365 works well for you — that’s because it was designed for you. It just stopped being designed for me.
P.P.S. You may have noticed that this article itself was written with the help of a Hermes AI assistant, trained on Codex and accessible via WeCom — I described my thoughts in a chat window, and it helped organize, research, and format everything. Not in a Word document with Copilot’s sidebar. That’s probably the best footnote of all.
