In December 2025 Anaplan announced a suite of role-based AI agents as part of Anaplan Intelligence. Within weeks, every planning team we work with had been asked by someone senior, "what are we doing about AI agents?" This post is our attempt at a straight answer: what the agents actually do, what has to be true before they are useful, and how to run a pilot that produces a real decision in 90 days.
What an Anaplan agent is, and is not
An agent in Anaplan's framing is an AI capability scoped to a role (a demand planner, an FP&A analyst, a sales operations lead) that can read the planning model, surface insights and anomalies, draft scenarios, and recommend actions within the planning process, working through the model's existing structure and security. It is not an autonomous system that changes your forecast while you sleep, and it is not a general-purpose chatbot bolted to the side of the platform.
Three practical consequences follow:
- An agent sees what the role sees. Anaplan's roles and selective access still govern visibility, so an agent scoped to a cost center manager's role cannot reason about data that manager cannot open.
- An agent is only as good as the model. If the model's variance logic is wrong, the agent will explain the wrong variance fluently.
- Recommendations need a path to action. An agent that recommends a reforecast is useful only if your process has a place for that recommendation to be reviewed and either accepted or declined.
Signal: what agents are good at today
From what we have seen in early use, agents earn their keep on tasks that are tedious for people and well defined for software:
- Exception surfacing. "Which 20 of these 4,000 SKUs have a forecast that moved more than 25% since last cycle, and why?" A planner can do this with filters; an agent does it unprompted and writes the narrative.
- Variance explanation. Decomposing a budget-to-actual variance across drivers and presenting it in plain language for the management pack.
- Scenario drafting. "Show me the plan if we delay the product launch by a quarter." The agent drafts the scenario inputs; a human approves them.
- Process nudging. Identifying instances in a Workflow that are stuck and who is holding them.
Noise: what to ignore
- "Autonomous planning." Nobody running a real supply chain or a real budget should let software commit a plan without a human decision. The agents are not designed for it and your auditors would not accept it.
- Agents as a substitute for data quality. If your history is dirty and your hierarchies disagree, an agent amplifies the problem.
- Agents as a reason to skip Forecaster. The forecasting engine and the agents are complementary. Get the Forecaster baseline right first; agents are more valuable when the numbers they explain are trustworthy.
Governance prerequisites
Before a pilot, write down and agree the following. It takes a week and it prevents a year of argument.
- Scope. Which model, which role, which processes. Start with one.
- Visibility. Which users can see agent output. Map it to existing roles; do not create new access paths for the agent.
- Authority. Can the agent only recommend, or can it write a draft scenario? Our default is recommend-only for the first cycle, draft-writing to a sandbox version in the second.
- Review. Who reviews recommendations, on which page, with what SLA. Workflow is the natural place for this.
- Logging. Every recommendation and every acceptance or rejection is recorded, with the user, in a module you own. Anaplan's audit log covers platform events; your own acceptance log covers the business decision.
- Kill switch. Who can turn it off, and how fast.
- Success measure. Defined before you start (see below).
A 90-day pilot plan
Days 1 to 15: baseline. Choose one process (monthly demand review is a good first choice). Measure the current state: hours spent per cycle on exception review and variance commentary, forecast accuracy, number of late submissions. Confirm data quality on the series in scope. Write the governance document above.
Days 16 to 30: configure. Enable the agent for the chosen role in a copy of the production model or a development model with current data. Build a review page with the agent's recommendations, an accept/reject input, and a comments grid. Brief the five to eight planners in the pilot.
Days 31 to 75: run two cycles. Planners work normally, with the agent's output available. Every recommendation gets an accept or reject with a reason. Do not change the process mid-pilot.
Days 76 to 90: decide. Compare against the baseline on three numbers: planner hours per cycle, acceptance rate of recommendations (with reasons for rejections categorized), and forecast accuracy where recommendations were accepted versus where they were not. Then decide one of three things: expand to a second process, keep in place and improve data, or stop.
What a good result looks like
A pilot has succeeded if planners say the agent found things they would have missed, if the acceptance rate is meaningful (20% to 60% is a healthy range; 95% suggests the planners stopped reading), and if the hours saved are real enough to show up in the cycle calendar. A pilot has failed usefully if it reveals data or process problems you now have a business case to fix.
Our position
We are optimistic about agents in planning and skeptical of the marketing around them. Run a governed pilot, measure it, and let the numbers decide. If you want help with the governance design or the pilot itself, see AI-Powered Planning with Anaplan Intelligence or contact us.