How to write better instructions for Excel agents

Earlier on this blog, I’ve written quite a bit about prompt patterns for Copilot in Excel and why they matter.

That work came out of a simple observation: some Copilot prompts work well, while others miss the point, even when they seem reasonable. Over time, a few patterns start to show up. Examples help. Step-by-step framing helps. Clear boundaries help.

None of this is magic, and most of the time you don’t think in terms of “patterns” while you’re working. You’re just giving Copilot enough structure to be useful. Once you start noticing that, prompting feels less like a special skill and more like everyday Excel judgment.

This post continues that line of thinking, but with a slightly different focus. To demonstrate, I’ll use a simple sales dataset. You can follow along by downloading the exercise file below:

&nbsp

Start with a normal Copilot prompt

Let’s ground this in the same way most people first experience Copilot in Excel: a single question against a simple table.

Here’s a prompt I’d actually use against the sales dataset in the demo workbook. It’s basically a “reasoning + boundary” pattern: ask for the logic, then compress the output, and keep it neutral.

“Using the sales table in this workbook, explain why revenue increased in April. First, briefly show how you’re separating price vs volume vs mix effects (no more than 5 bullets). Then give me a short, neutral summary I could paste into an email. Avoid implying causality or intent.”

That prompt will usually do something decent, because it tells Copilot what “good” looks like in that moment: decompose drivers, be cautious, and compress the result.

The trap: turning a good prompt into weak agent instructions

The most common failure mode in Agent Mode is also the most natural one. You take a prompt that worked well in Copilot, loosen it up a bit, and paste it into the agent instructions box.

It might look something like this:

“This agent helps analyze the sales table in this workbook. Explain changes in revenue over time and summarize key trends. Be clear and concise. Avoid implying causality.”

On the surface, that doesn’t look terrible. But it’s missing something essential.

That prompt works in Copilot because you are standing there steering it. Each time you ask a question, you implicitly provide structure. If the answer is vague, you reframe. If it overreaches, you narrow the scope. The discipline lives in the interaction.

Agent Mode doesn’t work that way. The instructions have to stand on their own across lots of questions, lots of users, and very different levels of care in how those questions are asked. When they don’t, you end up with results that sound thoughtful but don’t really show judgment. That’s exactly what’s happening here.

When we follow up with a question like “Why did revenue increase in April?”, the agent does what the instructions allow. It summarizes. It stays cautious. It avoids causal language. But it doesn’t know how to reason, what comparisons matter, or which dimensions are in scope. So it defaults to surface-level explanation.

This isn’t an Agent Mode problem. It’s an instruction problem. You never told the agent how to break a change apart, how to reconcile totals, how to sanity-check the math, or how to decide whether the data can actually support the question being asked. You gave it an objective, but not a way to get there.

With prompts, a human quietly fills in that gap. With agents, no one does. And that gap between something that sounds reasonable and something that behaves reliably is where most Agent Mode setups quietly start to wobble.

Why you should not turn a Copilot prompt into agent instructions

The most common mistake in Agent Mode is taking a prompt that worked well in Copilot and pasting a longer version of it into the agent instructions box. It looks reasonable, but what you’ve written still isn’t really instructions. It’s a prompt without a user.

Copilot prompts work because Copilot is reactive. Each interaction stands on its own, and you’re there to correct course when the output is off. The structure lives in the prompt.

Agent Mode shifts that structure into the background. The text you write no longer shapes a single response. It defines how the agent should behave across many interactions, users, and questions.

When you stretch a prompt into instructions, the agent behaves just like Copilot did before: sometimes helpful, sometimes vague, sometimes confidently fuzzy. That’s not an Agent Mode failure. It’s a mental model problem.

Prompts and instructions are related ideas, but they are not interchangeable, as summarized in the following table:

Rebuilding the instructions using Microsoft’s components

So what do we do instead?

Rather than improvising our own mental model, we can lean on the guidance Microsoft has already laid out for declarative agents. Their documentation makes a quiet but important distinction: agent instructions aren’t prompts, they’re a specification.

The following image from that guide captures that structure clearly:

prompt” and start writing an instruction set that actually defines a role.

Microsoft breaks agent instructions into a few core pieces: Purpose, Guidelines, Skills, and, when useful, step-by-step workflows, error handling, and examples. These aren’t extra documentation. They’re how you prevent the agent from guessing.

Purpose: what is this agent actually for?

“Analyze sales data” isn’t a purpose. It’s a topic.

With this workbook, what you usually want is narrower and more disciplined: explain revenue movement in a way that’s defensible and doesn’t drift into storytelling. A purpose that reflects that reality might be:

Help users explain month-over-month revenue changes in this workbook by separating price, volume, and mix effects, prioritizing transparency over certainty.

That single sentence already constrains behavior. It implies what counts as a good answer and, just as importantly, what doesn’t.

Guidelines: the rules you normally carry in your head

This is the section most people skip because it feels obvious. But it’s also the section that makes Agent Mode behave differently from Copilot.

For this dataset, the guidelines are really just analytical hygiene:

• Don’t infer intent or causality from observed changes
• Don’t collapse multiple drivers into one confident sentence
• Surface assumptions, especially with short time windows
• Tie claims back to specific columns and periods
• Ask a clarifying question when the request is underspecified

This isn’t about tone. It’s about not misleading someone.

Skills: what should it actually do in Excel?

Agents tend to misbehave when they have broad capability but no tool discipline.

With this file, the skills can be simple and restrained:

• Use PivotTables to validate aggregates before explaining drivers
• Recompute revenue (Units_Sold × Unit_Price) when validation is needed
• Use charts only when they clarify a comparison, not as decoration
• Use Python in Excel only if decomposition becomes cumbersome

This aligns directly with Microsoft’s guidance to explicitly reference tools and actions, rather than assuming the agent will “figure it out.”

Step-by-step workflow: prevent jumping to the answer

This is where Microsoft’s goal–action–transition guidance actually earns its keep. You don’t need a huge process, just a predictable path. For this workbook, one workflow does most of the work:

1. Identify the period-over-period revenue change
2. Decompose it into price, volume, and mix effects
3. Validate totals against reported revenue
4. Summarize dominant drivers and note limitations
5. If assumptions materially affect the conclusion, ask before proceeding

That sequence alone eliminates most confident-but-sloppy answers.

Error handling and limitations: tell it when to stop

This is the “permission to be careful” section.

• If required inputs are missing (which month, which product, which region), ask
• If the user asks for a strong causal claim, state the limitation
• If the history is too short for trend or forecasting claims, say so

This is how you reduce confident nonsense without turning the agent into a scold.

Examples: show what “good” looks like

You don’t need many examples, but one or two help anchor behavior and avoid repetitive phrasing.

A simple pair is usually enough:

• A clean “Why did revenue change in April?” request with a measured decomposition
• An edge case where the user asks for intent or causality and the agent pushes back

At that point, you’re no longer hoping the agent picks up your analytical judgment by osmosis. You’ve encoded it.

And that’s the real shift Agent Mode requires.

The improved Agent Mode instruction set

Here’s a cleaned-up instruction block that follows Microsoft’s declarative agent guidance and stays anchored to the demo workbook. Notice that I’m using Markdown to encode structure and ordering. This is something Microsoft explicitly recommends: Markdown helps clarify intent and sequence, especially when instructions need to hold up across many interactions.

# PURPOSE
Help users explain month-over-month revenue changes in this workbook’s sales table by separating price, volume, and mix effects. Prioritize transparency and defensibility over certainty.

# GENERAL GUIDELINES
- Use clear, neutral business language suitable for stakeholder updates.
- Avoid single-cause explanations when multiple drivers are present.
- Do not infer intent or causality from observed changes (e.g., “they raised prices to…”).
- Surface assumptions explicitly, especially when the time window is short.
- Tie explanations back to specific columns and periods (Date, Product, Region, Units_Sold, Unit_Price, Revenue).
- Ask one clarifying question when needed; do not proceed with missing inputs.

# SKILLS
- Use PivotTables to validate aggregates and isolate drivers.
- Validate Revenue when needed by recomputing Units_Sold * Unit_Price.
- Use charts only when they clarify a comparison (not decorative).
- Use Python in Excel only if decomposition becomes cumbersome.

# WORKFLOW: REVENUE CHANGE EXPLANATION
## Step 1: Confirm the question
- **Goal:** Ensure the requested comparison is clear.
- **Action:** If the month(s), product(s), or region(s) are unclear, ask a single clarifying question.
- **Transition:** Once clear, proceed to Step 2.

## Step 2: Validate totals
- **Goal:** Confirm the numbers before explaining them.
- **Action:** Use PivotTables to summarize Revenue by Date (and Product/Region as needed). If results look inconsistent, validate Revenue = Units_Sold * Unit_Price.
- **Transition:** If totals check out, proceed to Step 3. If not, flag the discrepancy and ask how to proceed.

## Step 3: Decompose drivers
- **Goal:** Explain changes using price, volume, and mix.
- **Action:** Separate the change into:
  - volume effect (units)
  - price effect (unit price)
  - mix effects (product/region composition)
- **Transition:** Proceed to Step 4.

## Step 4: Communicate the result
- **Goal:** Provide a stakeholder-ready explanation.
- **Action:** Provide:
  1) a short “how I reasoned” section (max 5 bullets)
  2) a neutral summary suitable for an email (short paragraph or 3 bullets)
- **Transition:** End by asking if the user wants a deeper breakdown by product or region.

# LIMITATIONS
- If the user asks for causal explanations or intent, explain that the data supports description, not causality.
- If asked to forecast with limited history, state the limitation and ask whether to proceed with a simple scenario-based approach.

# EXAMPLES
**User:** “Why did revenue increase in April?”
**Assistant:** (Decomposes into price/volume/mix, then gives an email-ready summary.)

**User:** “Did we raise prices to offset lower demand?”
**Assistant:** “This table shows price and volume changes, but it doesn’t contain intent or decision context. I can describe what changed and estimate contributions, but I can’t confirm why without additional context.”

What’s different once the instructions are structured this way is not just the final answer. It’s the shape of the interaction.

In the first image, notice what the agent does before it does any analysis at all. Instead of guessing which comparison matters, it asks a clarifying question about the period to focus on. That’s the agent following the instructions you gave it to avoid making assumptions when a request is underspecified. This is the exact opposite of the “confident but fuzzy” behavior you get from a stretched Copilot prompt.

Once the period is clarified, the agent doesn’t just summarize the change. It decomposes it. You can see it explicitly separating price, volume, and mix, reconciling the bridge back to the reported totals, and calling out where effects are zero. This is where the earlier instruction work really pays off. The agent isn’t improvising an explanation. It’s executing a defined analytical workflow.

What’s important here is that the extra detail isn’t gratuitous. The structure keeps it controlled. Each section answers a specific question: what changed, how much it contributed, and how it ties back to the table. There’s no narrative drift and no implied causality, because the guidelines explicitly rule that out.

Next, when you push a bit further, for example by asking why revenue increased in April, the difference becomes clearer. The agent doesn’t jump to a new story or repeat itself loosely. It builds on what’s already been established. It restates the headline result, walks back through the variance components in an orderly way, and then produces a stakeholder-ready summary that’s explicitly descriptive rather than causal. It also makes its assumptions visible and suggests a clear next step if you want to break the mix effect down further.

Conclusion: making agents make sense

Microsoft has used the phrase “vibe working” to describe the use of Agent Mode in Excel, but when you look at what’s required to get consistent results from an agent, the day-to-day reality is more structured than that label suggests.

The instruction set that produced the behavior above is fairly specific. It spells out what the agent is responsible for, how it should reason through a change, and when it should pause rather than push forward. That level of detail isn’t accidental. It’s what allows the agent to behave sensibly when you’re no longer there to steer each question.

There’s still plenty of room for loose, exploratory prompting. In fact, that’s often the most natural way to work when you’re thinking through a problem for the first time. Asking a half-formed question and seeing what comes back is a perfectly reasonable way to use Copilot.

Agents start to make sense in a different situation. They’re useful when you want the same kind of reasoning applied repeatedly, across variations of a question, without having to restate your expectations each time. In those cases, the upfront effort of writing clearer instructions pays off by reducing guesswork later.

Agent Mode works best when you capture the parts of your thinking that shouldn’t change from question to question. Once those are set, the agent behaves more consistently, which makes the results easier to rely on.