I use Excel a lot.
And like many Excel users, I eventually wanted something more powerful than formulas, VBA, and endless clicking.
I wanted to be able to say:
«"Clean this data."»
«"Find the duplicate customers."»
«"Create a chart from this table."»
«"Format this report professionally."»
«"Add formulas to calculate the margin."»
«"Find the errors in this workbook."»
…and have AI actually do it inside Excel.
Microsoft already has a solution for this: Copilot for Excel.
So naturally, I tried it.
And after using it, I had a question:
What if I could build my own version?
Not another chatbot that tells me which Excel formula to type.
I mean an actual AI assistant sitting inside native Excel Desktop, capable of turning natural-language instructions into real Excel operations.
So I started building one.
And this is what came out of it:
🚀 Excel AI Assistant
GitHub repository:
https://github.com/akshayai1996/excel-addin-ai
The project is an Excel Desktop add-in that provides a Copilot-style AI sidebar, but instead of being tied to Microsoft's Copilot experience, it uses OpenCode as the AI interface.
The basic idea is:
┌─────────────────────┐
│ Excel Desktop │
│ │
│ ┌───────────────┐ │
│ │ AI Sidebar │ │
│ │ │ │
│ │ "Clean this │ │
│ │ spreadsheet" │ │
│ └───────┬───────┘ │
└──────────┼───────────┘
│
Office.js
│
▼
┌─────────────────────┐
│ Python Bridge │
│ bridge_server.py │
└──────────┬──────────┘
│
OpenCode
│
▼
┌─────────────────────┐
│ AI Model / Provider│
└─────────────────────┘
The important part is that the AI doesn't directly manipulate Excel.
It produces structured actions.
Those actions are then validated and executed by the Excel add-in.
That distinction ended up being one of the most important architectural decisions in the project.
Why I Started Building This
My original motivation wasn't:
«"I want to replace Microsoft."»
It was much simpler.
I wanted an AI assistant that I could actually use for long Excel sessions without constantly worrying about the Copilot usage allowance.
When I experimented with Microsoft Copilot for Excel, I found that after a relatively small number of interactions/edits, I could hit usage limitations.
For someone doing serious spreadsheet work, that changes the experience.
Imagine working on a complicated engineering workbook and telling the AI:
Fix the formulas.
Then:
Now format the headers.
Then:
Create a summary sheet.
Then:
Add a chart.
Then:
Find anything that looks wrong.
An AI assistant becomes much more useful when you can keep iterating.
So I started wondering:
Why should the Excel interface and the AI provider have to be the same product?
What if Excel was simply the interface...
…and I could choose the AI layer separately?
That became the idea behind this project.
The Core Idea
The project tries to separate three things:
- Excel
Excel remains the actual spreadsheet application.
- AI interface
The sidebar communicates with an AI system through OpenCode.
- Excel execution engine
JavaScript receives structured instructions and performs the actual Excel operations through Office.js.
So instead of:
User → AI → Random JavaScript → Excel
I designed it more like:
User
↓
Natural language
↓
AI
↓
Structured Excel actions
↓
Validation
↓
Office.js execution
↓
Excel
That architecture makes the AI layer much easier to control.
What Can I Ask It To Do?
This is where it becomes interesting.
The assistant isn't just answering questions about Excel.
It can perform actual workbook operations.
For example:
"Create a table from A1:F500."
or:
"Sort the sales data by revenue descending."
or:
"Find duplicate customer IDs and highlight them."
or:
"Add a formula for profit margin."
or:
"Create a column chart showing monthly revenue."
or:
"Freeze the top row."
or:
"Replace all occurrences of LTCS with CS."
It also supports more advanced workbook operations such as pivot tables, charts, conditional formatting, formatting, formula operations, structural changes, and other Excel actions.
The AI converts the request into a structured action.
For example, conceptually:
{
"type": "sort_range",
"sheet": "Sales",
"range": "A1:F500",
"column": 6,
"ascending": false
}
The Excel execution layer then interprets that instruction.
The model doesn't get unrestricted access to execute arbitrary JavaScript.
That's intentional.
Natural Language → Actions
This is probably my favourite part of the architecture.
Suppose I tell the assistant:
«"Format this report professionally."»
That's vague.
The AI might decide that this means:
- Identify the header row
- Make headers bold
- Apply suitable number formats
- Add borders
- Adjust column widths
- Freeze the header row
- Create a table
Those become structured Excel actions.
Something like:
format_range
set_number_format
borders
freeze_panes
create_table
The execution layer handles them.
This means the AI can reason about the workbook while the deterministic JavaScript layer remains responsible for actually changing it.
I Didn't Want Just Another Chatbot
There are already thousands of AI chat interfaces.
I wasn't interested in building another one.
The interesting question for me was:
«Can an AI assistant actually operate Excel?»
There's a huge difference between:
AI says:
«"You can use "=SUM(A1:A100)"."»
and:
AI actually inserts the formula into Excel.
The second one is much more useful.
That's the experience I was trying to build.
The Excel Add-in
The frontend is built using the Office.js ecosystem.
The main pieces are:
taskpane.html
taskpane.css
taskpane.js
excel_actions.js
The task pane provides the conversational interface.
"taskpane.js" handles the assistant interaction and communication with the bridge.
And "excel_actions.js" acts as the Excel execution layer.
The latter is intentionally substantial because Excel operations aren't always as simple as:
range.values = ...
Real spreadsheets have:
- formulas
- formatting
- tables
- charts
- merged cells
- hidden rows
- hidden columns
- filters
- conditional formatting
- freeze panes
- structural changes
- workbook state
- undo requirements
So the execution layer needs to be much more careful.
The Python Bridge
The second major component is:
server/bridge_server.py
This acts as the bridge between the Office.js frontend and OpenCode.
Conceptually:
Excel WebView
↓
HTTP request
↓
Python bridge
↓
OpenCode
↓
AI model
↓
Structured response
↓
Excel
The bridge also contains the system instructions that tell the AI what kinds of Excel actions it is allowed to generate.
This is important.
Instead of asking the model:
«"Give me some JavaScript to modify Excel."»
I ask it to produce a known action format.
That gives the application a much clearer contract between the AI and Excel.
Why OpenCode?
This project isn't based on a single hard-coded AI model.
That's deliberate.
OpenCode provides an interface through which different AI models/providers can be used.
That means the Excel interface doesn't have to care whether the underlying model changes.
The architecture becomes:
Excel AI Assistant
│
▼
OpenCode
│
├── Model A
├── Model B
├── Model C
└── Other supported providers
That separation is powerful.
The Excel add-in becomes the product.
The AI model becomes an interchangeable component.
And that's exactly what I wanted.
One Important Clarification: This Is Not a "Fully Local AI" Project
I want to be very clear about this because "local AI" can be misleading.
The Excel add-in and Python bridge run locally on the user's computer.
However, OpenCode can communicate with cloud-based AI providers depending on the configuration and model being used.
So I'm not claiming:
«"Your spreadsheet never leaves your computer."»
That's not the point of this project.
The point is different:
«You can build a Copilot-style Excel experience while choosing the AI layer independently of Microsoft 365 Copilot.»
If someone configures OpenCode with a local model, that's a different setup.
If they configure it with a cloud provider, the model provider's data handling and policies apply.
I think being explicit about this is important.
What About Cost?
This is another area where I don't want to make misleading claims.
The project itself doesn't require a Microsoft 365 Copilot subscription.
But that does not mean AI inference is universally free.
Depending on how OpenCode is configured, the underlying model/provider may have:
- free usage
- paid usage
- rate limits
- API limits
- account requirements
- subscription requirements
So I wouldn't describe this project as:
«"Unlimited free AI."»
Instead, I'd describe it as:
«"A Copilot-style Excel interface where the AI backend is decoupled from Microsoft 365 Copilot."»
That distinction matters.
Safety Was a Big Concern
Giving an AI access to a spreadsheet is different from asking it to write a poem.
A bad Excel action can potentially destroy data.
So I didn't want the architecture to simply be:
AI → execute whatever it says
The project includes several layers intended to make workbook modifications safer.
Structured actions
The AI generates known action types instead of arbitrary JavaScript.
Validation
The bridge validates the structured response before passing it to the execution layer.
Transaction-style execution
The Excel execution layer is designed around grouped operations and state management.
Undo / redo
The project includes transactional undo/redo functionality.
Workbook backups
Automatic ".xlsx" backups can be created before batches of modifications.
These aren't guarantees that an AI can never make a mistake.
They're safeguards around an inherently probabilistic system.
It Can Work With Charts, Pivot Tables and More
One thing I particularly wanted was for the assistant to go beyond simple cell edits.
For example:
«"Create a chart showing revenue by month."»
or:
«"Create a pivot table summarising sales by region."»
or:
«"Highlight negative margins with conditional formatting."»
The assistant can translate these requests into structured Excel actions rather than merely explaining how to perform them manually.
That turns the interaction from:
Chatbot + instructions
into:
AI + spreadsheet manipulation
which is a much more interesting application.
I Also Added Test Workbooks
The repository includes test data such as:
test-data/
├── messy_test.xlsx
├── sales_test.xlsx
└── make_test_workbooks.py
I think this is important for an AI-powered spreadsheet application.
You don't want to test everything against your only important workbook.
A deliberately messy workbook gives the assistant something realistic to work on.
For example:
Messy data
↓
AI analysis
↓
Cleaning actions
↓
Excel execution
↓
Verification
That's a much better development loop.
The Project Structure
At a high level:
excel-addin-ai/
│
├── manifest.xml
├── README.md
├── DESKTOP_SETUP.md
├── setup_desktop.ps1
├── start_server.bat
│
├── server/
│ └── bridge_server.py
│
├── src/
│ ├── taskpane.html
│ ├── taskpane.css
│ ├── taskpane.js
│ └── excel_actions.js
│
├── assets/
│ ├── screenshots
│ ├── demo media
│ └── icons
│
└── test-data/
├── messy_test.xlsx
├── sales_test.xlsx
└── make_test_workbooks.py
It's intentionally not a giant AI framework.
It's basically:
Office.js + JavaScript + Python + OpenCode + Excel.
Installing It
The project is primarily aimed at Excel Desktop on Windows.
The repository contains setup scripts and documentation for the desktop environment.
The rough flow is:
- Clone repository
- Install dependencies
- Start local bridge
- Sideload Excel manifest
- Open Excel Desktop
- Open the AI task pane
- Start talking to your workbook
The repository contains more detailed setup instructions here:
GitHub:
https://github.com/akshayai1996/excel-addin-ai
Now I Want Your Honest Feedback
This is where I need the DEV community.
I've built the thing.
I've tested it myself.
But I'm one person testing my own tool, and that's a terrible way to discover every weakness.
So if you're an Excel user, developer, automation engineer, data analyst, or just someone who spends too much time inside spreadsheets:
Try it. Break it. Be brutally honest.
Don't just tell me:
«"Nice project!"»
Tell me:
«"This doesn't work."»
«"Why does it do this?"»
«"This workflow is annoying."»
«"It should understand this automatically."»
«"This Excel operation needs to be supported differently."»
«"The AI generated the wrong action here."»
«"The UI needs to work like this instead."»
That's the feedback I'm actually looking for.
I'd especially love to hear what happens when you throw real-world Excel tasks at it rather than carefully prepared demo prompts.
Try messy workbooks.
Try large datasets.
Try formulas.
Try formatting.
Try charts.
Try pivot tables.
Try multi-step instructions.
Try deliberately ambiguous requests.
Try something that you think an Excel Copilot should be able to understand.
Then tell me what broke.
What Should I Improve?
I don't want to decide that for the community before hearing from people who actually use it.
Maybe the biggest problem is the UI.
Maybe it's workbook context.
Maybe it's the AI's reasoning.
Maybe it's execution reliability.
Maybe it's speed.
Maybe it's handling large workbooks.
Maybe it's something I haven't even considered.
Tell me.
The goal of this project isn't to claim that I've built the perfect Excel AI assistant.
The goal is to build something useful, test it with real users, and keep improving it.
The Bigger Idea
The interesting part of this project isn't really Excel.
It's the architecture.
We're entering a world where AI can understand natural language but traditional software still provides the deterministic execution layer.
That creates a useful pattern:
Human intent
↓
AI
↓
Structured commands
↓
Deterministic software
↓
Real-world result
Excel happens to be a particularly interesting environment for this because spreadsheets contain a huge amount of structured information but still require enormous amounts of manual interaction.
Imagine applying the same pattern to:
- CAD
- engineering software
- project management
- ERP systems
- data analysis
- reporting tools
- document management
- financial modelling
The AI doesn't need to replace the application.
It can become a natural-language control layer on top of the application.
That's what I'm experimenting with here.
So… Did I Build "Microsoft Copilot"?
No.
And I don't want to pretend I did.
Microsoft has a massive ecosystem behind Copilot, and this project is nowhere near that scale.
What I built is something more specific:
«A personal, extensible, Copilot-style AI interface for native Excel Desktop, where the AI backend can be changed independently through OpenCode.»
And honestly, that's what makes the project fun.
I don't need to wait for a vendor to decide what my spreadsheet assistant should be able to do.
I can build the workflow myself.
Try It
The project is open on GitHub:
https://github.com/akshayai1996/excel-addin-ai
If you're an Excel power user, Office.js developer, AI developer, or someone experimenting with AI agents controlling traditional desktop software, I'd genuinely like to know:
What would you ask an AI assistant to do inside Excel?
And more importantly:
What would you change after actually using it?
Try it.
Give me the good feedback.
Give me the bad feedback.
Give me the "why the hell did it do that?" feedback. 😄
That's probably where the next version will come from.
Final thought
The question that started this project was surprisingly simple:
«"Why should I have to use one specific AI assistant just because I'm using Excel?"»
So I built an alternative.
Not perfect.
Not finished.
But it works.
Now I want other Excel users and developers to tell me what I got wrong — and what I should build next. 🚀
Top comments (0)