Enterprise RAG is learning to plan its own searches. Progress puts that agent inside Microsoft Teams

The first generation of enterprise RAG worked like a reference desk with a single question allowed. The user asked, the system ran one search, pulled the top passages and wrote an answer. When the right answer needed two documents from two systems, or a fact that only made sense after reading something else first, it guessed.

Progress Software’s October 1 release is a clean example of where that is heading. Its Agentic RAG platform gained three things: a native Microsoft Teams app, a Smart Agent that plans multistep retrieval, and a WordPress plugin for better ingestion. Each one points at a different production problem.

What Progress released

Per Progress, the release is available now:

• Teams app. Delivered through the Microsoft Teams store, it brings source-cited answers into Teams chats and channels. Progress says it maintains existing permissions and governance controls.
• Smart Agent. Instead of one search, it plans the query, breaks it into sub-questions, retrieves from the indexed Knowledge Box, from applications connected through the Model Context Protocol (MCP) and from web sources, then evaluates what it found and keeps going until it judges the information sufficient. Progress positions this as removing the need for custom orchestration code.
• WordPress plugin. It gives administrators control over what gets indexed and when it refreshes, and preserves page structure, metadata and taxonomy instead of flattening everything into plain text.

Progress calls the shared layer underneath an “Agentic Knowledge Layer.” Pricing was not part of the announcement.

1. Question
2. Plan sub-questions
3. Search the index
4. Query live systems via MCP
5. Judge: enough?
6. Cited answer in Teams

• Loop until sufficient: Plan sub-questions · Search the index · Query live systems via MCP · Judge: enough?

Steps classic RAG did not have

Multistep retrieval moves decisions into the retriever

The Smart Agent is the substantive change. A planner that decides what to search next is no longer just retrieval; it is an agent whose tools are search indexes and business systems. That brings three consequences.

Evaluation gets harder. With one search, you can measure whether the right passages came back. With a plan, you also need to measure whether the plan was sensible, whether it stopped at the right time and whether it chose the right sources. As we argued in our piece on measuring retrieval as its own system, retrieval quality has to be scored separately from the final answer. Multistep retrieval adds a third layer: the plan itself.

Cost and latency become variable. A question that triggers six sub-searches and two live system calls costs more and takes longer than one that triggers one. Budget per question, not per user, and watch the distribution, not the average.

Live queries carry identity questions. Pre-indexed content can be filtered by the permissions recorded at indexing time. A live MCP call to a business system runs with some identity. Is it the user’s, delegated, or a service account that sees everything? The answer decides whether “maintains existing permissions” holds for live sources as well as indexed ones. Ask for it per connector.

Why Teams, and what it brings with it

The second pattern is distribution. Employees already spend the workday in Teams, and a governed answer inside a channel gets used more than a separate portal people forget to open. We made a related point about collaboration suites in our analysis of Gemini acting inside Microsoft 365: the surface people work in shapes which AI they adopt.

Teams also brings obligations. An answer posted in a channel is a message, and messages fall under the retention policies, legal holds and eDiscovery searches your legal team already runs. If an AI-generated answer with citations becomes part of a decision thread, it is part of the record. Confirm with legal and records management that bot messages are captured by the same policies as human ones before you roll out widely.

For Microsoft 365 customers there is also a build-versus-buy question. Microsoft 365 Copilot already grounds answers in SharePoint and other sources through Copilot connectors. A third-party knowledge layer makes most sense when much of the knowledge lives outside Microsoft 365, in places like WordPress, product documentation or other line-of-business systems, or when you want one retrieval layer that serves Teams, websites and other agents alike. If nearly all of your knowledge sits in SharePoint, start by asking what the native path already covers.

Ingestion quality is the unglamorous win

The WordPress plugin is the least exciting item and possibly the most useful. Many intranets, policy portals and help centers run on WordPress. When structure, metadata and taxonomy survive ingestion, retrieval can filter by department, date or document type instead of guessing from raw text. Many RAG quality problems start here, long before the model.

What to do with this

1. Map your knowledge. List where the answers your people need actually live, and how much sits outside SharePoint.
2. Test identity per source. For each indexed source and each live MCP connection, confirm whose permissions apply.
3. Evaluate the plan. Build a test set of multi-hop questions and score sub-question quality, stopping behavior and source choice, not only the final answer.
4. Set a cost ceiling per question and alert on outliers.
5. Bring records management in early for anything that posts into Teams.

The bottom line

RAG is turning into an agent that plans its own research, and it is moving into the collaboration tools people already use. Both moves make answers better and both add new places to be wrong: plans that wander, live calls with the wrong identity, AI messages that become records. Treat multistep retrieval as an agent from the first day, with the evaluation and permissions that come with it. If you are still deciding whether to run retrieval yourself, our build-or-buy view on managed retrieval covers that choice.