From Conversations to Agents: Work Context Meets Code

I asked Copilot what Ben, Darrel, and I had been discussing this week. It pulled up our Teams thread about a claims management agent for our adjusters, the MCP server Ben found, the SharePoint sites with policy documentation. Then I typed: “Implement what we discussed.” Copilot inferred the agent’s purpose, identified the capabilities, and started scaffolding a declarative agent from my actual work conversations.

That’s the shift. Your work context (the meetings, the chats, the emails you’re already producing every day) can now feed directly into agent generation. No translation step. No copy-pasting from meeting notes into a manifest. Just context in, agent out.

What Is Work Context, and Why Does It Matter?

Work context is the knowledge that lives inside your Microsoft 365 tenant: Teams messages, Outlook emails, calendar events, OneDrive documents, SharePoint sites. It’s the conversations you have with colleagues, the decisions captured in email threads, the specs sitting in shared folders. Until now, that context lived in one world, and your development tooling lived in another.

The Work IQ plugin bridges that gap. When installed in your coding agent (GitHub Copilot CLI, Copilot in VS Code, or Claude Code), it gives the agent read access to your Microsoft 365 data, scoped to your permissions. The coding agent can query your recent emails, pull up conversation threads, read shared documents, and surface meeting notes, all within the same session where you’re building code.

This matters because the hardest part of building an agent is often defining what it should do. The requirements live in scattered conversations, half-written docs, and “remember what we said in that meeting?” moments. Work context collapses that gap: the coding agent reads the same conversations you had, extracts the intent, and translates it into working configuration.

The Walkthrough: Conversations to a Deployed Agent

Here’s what the session actually looked like. Real prompts, real flow, real output.

Step 1: Retrieve the Work Context

I started by asking Copilot about my recent conversations with Ben and Darrel. No agent scaffolding yet, just a question about my own work.

That’s the work context in action. Copilot retrieved and summarized three days of conversations across Teams and Outlook, giving me a clear picture of what we’d been discussing.

Step 2: Let Copilot Infer the Requirements

Instead of manually translating those conversation notes into a spec, I asked Copilot to summarize what it would build.

This is the critical step. Copilot didn’t just start generating files blindly. It summarized what it inferred from my work context and asked for confirmation. I reviewed the list, agreed with the capabilities, and gave the green light.

Step 3: Generate the Agent

One word: go.

The Agents Toolkit Skills handled the heavy lifting: correct schema version, proper folder structure, validated capability names, and an MCP plugin configuration generated from the server details Ben shared in that email thread. Here’s what the generated declarativeAgent.json looked like:

{
  "$schema": "https://developer.microsoft.com/json-schemas/copilot/declarative-agent/v1.6/schema.json",
  "version": "v1.6",
  "name": "Claims Management Agent",
  "description": "Helps adjusters sort, triage, and work through current claims with policy documentation, status tracking, and communication tools.",
  "instructions": "$[file('instructions.txt')]",
  "capabilities": [
    { "name": "WebSearch" },
    {
      "name": "OneDriveAndSharePoint",
      "items_by_url": [
        { "url": "https://contoso.sharepoint.com/sites/Claims" }
      ]
    },
    { "name": "Email" }
  ],
  "actions": [
    {
      "id": "claimsManagement",
      "file": "claimsManagementMcp.json"
    }
  ]
}

Every capability traced back to something we discussed in those conversations. The SharePoint site came from Darrel’s suggestion about policy documentation, the email capability from his note about claimant and broker communications, and the MCP plugin from Ben’s discovery of the new Claims Management MCP server.

Step 4: Deploy and Test

From “what did we talk about?” to a deployed agent, all in one session. No context switching. No document translation. No starting from a blank declarativeAgent.json.

How to Enable the Work IQ Plugin

Setting up the Work IQ plugin takes about two minutes.

Prerequisites: Node.js 18+ and a coding agent (GitHub Copilot CLI, Copilot in VS Code, or Claude Code).

# Add the Work IQ marketplace
/plugin marketplace add microsoft/work-iq

# Install the Work IQ plugin (for work context)
/plugin install workiq@work-iq

# Install the Agents Toolkit plugin (for agent generation)
/plugin install microsoft-365-agents-toolkit@work-iq

Restart your coding agent session, and both plugins are active. The Work IQ plugin handles work context retrieval; the Agents Toolkit plugin handles agent scaffolding, configuration, and deployment. Together, they create the full “context to agent” pipeline.

Where This Helps (and Where It Doesn’t)

The “work context as specification” pattern shines in specific scenarios.

It works best when:

• You’ve already discussed the agent’s purpose with colleagues and the decisions exist in your M365 data
• The requirements are spread across multiple conversations and you need them consolidated
• You want to prototype quickly based on real team input, not hypothetical scenarios
• A non-technical stakeholder described what they need in an email or Teams message, and you want to turn that into a working agent

It breaks down when:

• Conversations were vague or contradictory (Copilot will surface contradictions, but can’t resolve them for you)
• Non-functional requirements like compliance rules or SLA targets weren’t discussed explicitly
• The context involves sensitive data that shouldn’t appear in agent instructions
• You need a production-ready agent without human review of the inferred spec

The key insight: work context gives you a powerful first draft, not a finished product. You still review, refine, and validate before deploying to production. But starting from a grounded first draft is dramatically faster than starting from nothing.

Fitting Into Developer and Information Worker Workflows

This pattern isn’t limited to one “conversations to agent” demo. It opens up several workflows.

For developers:

• Meeting-driven specs: After a design review, ask Copilot to summarize decisions and scaffold the agent immediately
• Email-to-agent pipelines: When a stakeholder emails you requirements, point Copilot at the thread and generate
• Document-grounded instructions: Reference a SharePoint requirements doc and ask Copilot to derive the agent’s instructions from it
• Cross-team context: Pull conversations from multiple colleagues to build an agent that reflects input from product, engineering, and support

For information workers:

• Describe what you need in natural language grounded in your own work context
• A developer (or the coding agent itself) translates that into a working declarative agent
• The barrier between “I wish I had an agent that…” and “here’s your agent” shrinks to minutes

The Value You Just Unlocked

• Work context as specification: Your existing M365 conversations become the starting point for agent design, eliminating the translation step between discussion and implementation
• Faster time to prototype: Go from “we talked about this” to “here’s a working agent” in a single session, grounded in real decisions your team already made
• Grounded accuracy: Capabilities and instructions are inferred from actual conversations, not guessed from vague prompts. Every feature traces back to a real discussion
• Permission-scoped safety: The Work IQ plugin respects your Microsoft 365 permissions. Your coding agent only accesses data you can already see
• Seamless developer workflow: No context switching between communication tools and development tools. Conversations, requirements, and code generation happen in one terminal session

Work context turns your daily work into fuel for agent creation. The conversations you’re already having, the emails you’re already writing, the documents you’re already sharing: they all become inputs to a system that can generate, configure, and deploy declarative agents. That’s not just a productivity boost. It’s a fundamentally different way to think about where agent requirements come from.

Resources

• Microsoft 365 Copilot Extensibility Overview
• Declarative Agents Overview
• Declarative Agent Manifest Schema
• Writing Effective Agent Instructions
• Microsoft 365 Agents Toolkit Fundamentals
• MCP Plugins for Microsoft 365 Copilot