GitHub Copilot is a coding agent. That’s what it’s built for, and it’s great at it. But at some point I started wondering — if it can reason about code, parse structured data, and call APIs, why am I only using it inside a repo?
The answer was: I shouldn’t be.
This is the story of how I took Copilot beyond development and wired it into the rest of my workflow — notes, calendar, meetings, internal tools — using MCPs and Obsidian as the connective tissue.
The Tools
GitHub Copilot CLI — my coding agent, now extended into a general-purpose reasoning layer. It already understands context, calls tools, and runs skills. The leap was giving it access to things that aren’t code.
Obsidian — where I think. Notes, daily logs, project plans, meeting prep, architecture decisions. Everything lives in Markdown, structured with PARA. And with the new Obsidian CLI, agents can read, write, and search the vault programmatically — turning it from a note-taking app into an agent-accessible knowledge base.
WorkIQ (MCP) — Microsoft’s MCP server that connects AI agents to Microsoft 365 Copilot. It exposes your Microsoft Graph data — calendar, emails, Teams messages, files, people — through the Model Context Protocol. Instead of alt-tabbing between Outlook, Teams, and Calendar to piece together what’s happening, I ask Copilot and it reasons over all of it at once.
MSX (MCP) — an internal tool for tracking customer engagements, technical activities, and project status. The kind of data you normally dig through a web UI to find.
The Real Tax
So why wire all of this together? Because my day doesn’t live in one place. Meeting context is in Teams. Follow-ups end up in Outlook. Project data sits in internal tools. Architecture decisions and notes live in Obsidian. The code is in VS Code.
The tax isn’t switching tabs. It’s rebuilding context every time you switch. You come out of a design review, need to update your notes, reference what was decided in last week’s thread, and check if the deployment timeline changed. Three tools, five minutes, and half your focus — gone.
What if the agent already had all of this?
That’s the question that led me down the rabbit hole.
Wiring It Together
Turns out, the setup is simpler than you’d expect. Copilot CLI supports MCP servers natively — you can install them as plugins or configure them manually. For WorkIQ, it’s three commands:
copilot
/plugin marketplace add github/copilot-plugins
/plugin install workiq@copilot-pluginsRestart the CLI, and Copilot can query your Microsoft 365 data. Emails, calendar, Teams messages, documents, people — all accessible through natural language. Under the hood, WorkIQ runs as an MCP server that translates your questions into Microsoft Graph queries, respecting your existing permissions. It doesn’t store anything — retrieves on demand.
You can also run it standalone or in VS Code — npx -y @microsoft/workiq mcp starts the server, and you can wire it into any MCP-compatible tool. See the WorkIQ GitHub repo for the full setup.
For MSX, the pattern is the same: an MCP server that exposes customer engagement and project data to the agent. Install it, and Copilot gains new capabilities it can call when relevant.
Obsidian plugs in through its CLI. With the CLI enabled, Copilot can create notes, search the vault, read existing content, and update files — all programmatically. The vault becomes part of the agent’s tool set, not just a place I go to manually.
The pattern is the same every time — MCP is a protocol, not a product. Knowledge base, project tracker, your own internal API — if it speaks MCP, Copilot can reason over it.
But having access to data isn’t the same as knowing what to do with it. That’s where Skills come in.
Teaching Copilot Your Workflows
Skills are markdown-based instruction files that teach Copilot specific workflows. Not one-off prompts — persistent, reusable, version-controlled definitions that load automatically when relevant. They work across Copilot CLI, VS Code, and the coding agent.
Think of a skill as a playbook. It tells the agent: when this type of task comes up, here’s what tools to call, in what order, and what to do with the results. Write it once, and the agent knows the routine.
Three skills changed how I work.
The Daily Standup
Every morning, I need to know: what meetings do I have today, which ones am I leading, and what do I need to prepare?
Before this setup, I’d open Outlook, scan my calendar, mentally flag the important ones, then manually create notes in Obsidian. New file, pick a template, fill in participants, structure the note. Ten to fifteen minutes of pure admin.
Now I have a skill that does this:
- Queries WorkIQ for today’s calendar
- Filters for meetings I’m organizing or have a key role in
- Creates an Obsidian note for each one — via the CLI — with attendees, agenda, and space for my notes
- Links them to my daily note
One command. The meetings I care about are scaffolded and ready.
This doesn’t replace Teams transcription. Transcripts capture everything that was said — they’re a record. My meeting notes capture what I need to act on — decisions, follow-ups, open questions. That’s a personal layer no automated tool builds for you. But the scaffolding? The agent handles that.
That covers the start of the day. But what about the meetings themselves?
Pre-Meeting Context Pull
This one applies to any meeting — customer calls, architecture reviews, design discussions, planning sessions. Before any meeting where I need context, I used to spend time across multiple tools: check the internal tracker for engagement status, scan Outlook for the last thread, skim my Obsidian notes for anything I’d previously written.
Now I ask Copilot. It pulls context from the relevant MCP — engagement history and project status from MSX for customer calls, Teams threads and shared documents via WorkIQ for design reviews. It cross-references with my vault for previous notes. Drops everything into a single Obsidian meeting note.
For a customer call, that means recent engagement activity, the last email thread, and my own technical notes on their architecture — all in one place. For a design review, it’s the relevant Teams discussion, shared docs, and what I captured last sprint. Same skill, different context sources.
The difference isn’t speed — it’s completeness. I was always prepping, but when context lives in three systems, you end up with whatever you had time to pull. Remove the friction, and every meeting gets the full picture.
80 to 100 meetings. That’s how many I’ve prepped this way so far — each with full context linked to previous notes, cross-referenced with engagement data or Graph data, connected to relevant conversations. Not theoretical. Real meetings I walked into actually knowing what was going on.
So the mornings are handled. Prep is handled. What falls through the cracks is the end of the day.
The Daily Wrap-Up
End of day: what do I need to update?
Meetings happen. Decisions get made. Things move. But internal systems don’t know that until someone logs it. If you don’t do it the same day, it doesn’t get done — or it gets done wrong, three days later, from memory.
I have a wrap-up skill that reviews my day: what meetings I had, what notes I captured, and what the current state looks like in the relevant systems. It surfaces the gaps — items that need status updates, follow-ups that need scheduling, decisions that should be documented. It doesn’t write updates for me (I want that control), but it tells me exactly what needs attention.
Same pattern works weekly. A Friday wrap-up scans the whole week: here’s what moved, here’s what’s stale, here’s what you said you’d do but didn’t.
At this point you might be thinking — this is just productivity automation. And sure, the time savings are real. But that’s not why I did it.
What I Actually Learned
I did it because the future of work looks fundamentally different, and the only way to understand how is to live it. Not read about it. Not watch demos. Embed AI into your actual daily workflow and see what changes — what gets easier, what breaks, what new possibilities appear that you couldn’t have predicted.
Most people use AI tools in isolation. A chat window here, an autocomplete there. Useful, but contained. The shift happens when you stop using AI as a feature and start using it as infrastructure — a layer that sits between you and all your tools, reasoning across them on your behalf.
That’s what this experiment taught me. Not just how to prep for meetings faster, but what work looks like when the agent has full context. When it knows your calendar, your notes, your internal systems, your code — and can connect dots you’d never have time to connect manually.
We’re early. The tools are rough. But the shape of what’s coming is clear enough to bet on.
The Rough Edges
Setting this up takes time. Real time.
The MCPs install quickly. The technical wiring isn’t the hard part. The hard part is figuring out your workflow. If you go looking for how other people do it, you’ll find over-engineered setups that don’t match how you actually work. Templates that look great in a demo and fall apart in practice. Automations that solve problems you don’t have.
You have to sit with the tools, try things, break them, rebuild. What does your morning actually look like? What do you always forget to update? Where do you lose time without even noticing? Those answers are personal. No tutorial gives them to you.
The first few weeks were slow. Learning the skill format, figuring out what WorkIQ could and couldn’t do, tuning prompts, adjusting note structures. It felt like overhead, not improvement. But each iteration got closer to something that genuinely fit, and once it clicked, the payoff compounded.
The other honest truth: this only works if you’re willing to own the system. Skills need occasional tuning. Workflows change. New tools get added. It’s not set-and-forget — it’s more like a system you maintain. If you already tinker with your toolchain (and if you’re reading this, you probably do), that maintenance is part of the appeal.
Start small. Pick one workflow that bugs you — the one where you’re always switching between three tools to do something that should be simple. Wire up one MCP, write one skill, see what happens. You can always add more later.
Links: