A support macro goes stale because it is a snapshot: it describes the product as it was the day someone wrote it, and no release warns it. Nothing in the support tool connects the sentence "go to Settings > Export" to the commit that moved the button.
This isn't the subject of the articles on the bot answering from frozen knowledge. Here nobody indexed anything: these are texts written by hand, sent by humans, that no reindexing will refresh.
What a macro is, and why it doesn't age like docs
A macro (or canned response) is a prewritten text a support agent drops into a conversation with one click. It exists to answer fast and in a consistent voice. It is a good format, and it isn't the one to blame.
The problem lies elsewhere: a macro holds facts (a menu path, a limit, a delay, a field name) glued into a voice. The voice doesn't age. The facts do. And because the text reads as the company's own answer, nobody rereads it the way they would read a documentation page. For the general case, see how every knowledge base drifts.
Post-mortem of a macro (illustrative example)
Take a fictional macro, written by a fictional team in spring, and read it sentence by sentence. The product, the dates and the releases below are illustrative.
"Hi, to export your data, open Settings > Export, choose CSV, then click Download. Files are limited to 10,000 rows. You'll receive the link by email within 5 minutes."
Four months and three releases later, here is what each piece has become:
- "Settings > Export": a commit in release 2 moved the export under the Data menu. The path is wrong; the sentence is still polite.
- "CSV": still true. Half of a macro surviving is exactly what makes it dangerous.
- "10,000 rows": a release raised the limit. The customer gives up on an export they could have run.
- "within 5 minutes, by email": the email delivery was replaced by a direct download. The sentence promises an email that never arrives.
Nobody made a mistake. Every release was correct, every change was intended. The macro is the only thing that never found out.
Why the macro is the last link to update
When a release ships, three things update themselves, or nearly: the code, the tests, sometimes the changelog. Macros aren't among them, for a simple reason: nobody owns them at release time. The developer doesn't know they exist; the support agent doesn't read diffs.
The result shows up three weeks later in a ticket where the customer writes "your answer doesn't work". A developer is then interrupted to confirm what the commits already said: the mechanism described in cutting developer interruptions from support.
Finding the macros that lie: start from the changes
Rereading a hundred macros one by one doesn't last. The reverse path is shorter: start from what changed, then look for who talks about it.
- List the changes in the window (since the last review): renamed fields, moved screens, modified limits, replaced behaviors. Git history provides it; the question "what changed since the 1st of the month?" answers it directly.
- For each change, note the words customers use ("export", "invoice", "invite"), not the internal names in the code.
- Search those words in the support tool. The macros that contain them are the suspects.
- Reread only those, against the diff.
Half an hour per release is enough for a modest product, provided the starting point is the changes and not the macros. It is the same principle as keeping a help center in sync with releases.
Move where the facts come from, keep the voice
The real fix isn't rereading more often: it's no longer copying the facts. A macro can keep the tone, the greeting, the structure, and fetch the menu path or the limit from a source that moves with the code.
DeployIt reads the real code, resynchronized on every push, and its help center generated from the code is one application: the page describing the export follows the export. A macro that points to that page, instead of copying its content, goes stale much more slowly. For AI agents, the MCP server plays the same role on the question side: it checks the code before asserting.
What our public pages don't establish is that DeployIt rewrites or flags your macros inside your support tool: it doesn't, and we don't present it as if it did. The MCP server is in early access, through a design partner program. If you want to see how to point your answers at this source, the door is the design partner program.
"We already review macros every quarter"
It is good practice and it reduces the damage. But the review cadence isn't the release cadence: with a weekly release, a macro can lie for twelve weeks before it is reread. Keep the review, and give it a trigger: the list of changes for the period, not the list of macros.
"Our support tool has a stale-content alert"
It measures the age of the text, not its truth. A macro written yesterday can be wrong if the release shipped this morning; a two-year-old macro can be right. Age is a hint, the diff is proof.
Mini-FAQ
Who should own the macros? Someone on the support side, with read access to the changes. Without that access, ownership stays nominal.
How many macros should you keep? Fewer than you think. Those with no verifiable fact (greeting, apology, follow-up) never go stale; put the effort into the others.
What if the customer already got the wrong macro? A short second reply beats silence: correct the fact, cite the source, apologize in one sentence.
In short
A macro isn't wrong through negligence: it is wrong by construction, as soon as the release that contradicts it ships. Start from the changes, not the macros; keep the voice, move the facts. DeployIt's help center generated from the code and its MCP server (early access, design partner program) are free during early access, with paid plans arriving in January 2027.
Frequently asked questions
Why do support macros become wrong?
Because a macro is a snapshot: it describes the product on the day someone wrote it. Any release can change a sentence of it, and nothing in the support tool tells the author.
How do you find stale macros without rereading all of them?
Start from the changes, not from the macros: list what moved in the product over the window, then search the macros for the ones that name those objects (a field, a screen, a limit).
Should you delete macros?
No. A macro is still the right format for voice and tone. What has to change is where its facts come from: a source that moves with the code instead of copied text.
Is a stale macro worse than no macro?
Often, yes: it goes out fast, with the confidence of a vetted text, and the customer has no way to know it is old.
Continue reading
What happens in the first week an AI agent is connected to your product?
The first seven days of an agent connected to your product: the questions that land, the ones that miss, the ones left unanswered, and what you adjust on your side. An illustrative scenario with no usage figures.
Why does an AI agent answer differently on staging than on production?
Same agent, same question, two answers: staging and production are not the same product, and the agent answers from whichever state its source reflects. Four sources, four ages, and the question to ask before you connect one.
What security questions should you ask an MCP server vendor?
Twelve questions, in four blocks, that a security team can put to any MCP server vendor: who can call it, what it can read, what it can do, and what you can prove afterwards. For each, the answer that closes the point and the one that leaves it open.