The one real retrieval development in the last 48 hours: Progress Software announced an expansion of its agentic RAG platform, adding a Microsoft Teams app, a component it calls Smart Agent, and a WordPress plugin, positioned as connecting enterprise knowledge across business systems. That's the verifiable shape of it — surfaces and connectors, not a new retrieval algorithm. Worth reading the release notes yourself before drawing conclusions about depth.
The announcement matters less for what Progress shipped than for what it confirms about where the work has moved. Nobody is winning on chunking strategy anymore. The hard parts have migrated to the edges of the pipeline: getting content in, and getting answers out where people already are.
The surface problem is a permissions problem
A Teams app sounds like packaging. It isn't. The moment retrieval answers inside a chat client, you inherit that client's identity model, and every answer has to be filtered by what the asking user is actually allowed to see — at query time, per document, with permissions that changed since you indexed. Most teams building internal knowledge bases discover this late and solve it badly: a single service account indexes everything, ACLs get flattened into metadata, and the index slowly becomes a leak surface. The correct pattern is impersonated retrieval with permission checks evaluated against the source system's current state, or at minimum an ACL cache with aggressive invalidation. Both are expensive. Neither is optional.
A WordPress plugin points the other direction — public or semi-public content, where the risk isn't leakage but staleness and hallucinated citation. Different failure mode, different eval set. If you're building one system to serve both, you need two sets of guardrails, not one.
"Agentic" buys you recall and costs you determinism
The useful reading of agentic RAG is a planner that decomposes a question, issues several retrievals across different connectors, and decides when it has enough. That genuinely helps on multi-hop questions a single top-k vector lookup fails. It also multiplies latency and token spend per query, makes caching hard, and turns debugging into trace archaeology. Before adopting it, instrument the thing you already have: measure how many of your failures are retrieval misses versus synthesis errors. If it's synthesis, more retrieval loops won't help.
The connector layer is the real durable asset here, and it's the part that rots — auth flows break, APIs version, sync jobs silently fall behind. That's also why the move toward a stateless MCP core, finalized in the July spec work, matters more to this architecture than any model release: it's the difference between connectors you can horizontally scale and connectors that pin sessions to boxes.
Who should care: anyone running internal search on SharePoint-plus-Confluence-plus-ticketing. The lesson isn't to buy this. It's that distribution and permissions, not embeddings, are now your roadmap.