The Changelog

Overview

This release introduces significant improvements with the addition of Deep Search mode to Search functionality, enhanced result relevance, and faster performance. We've also addressed numerous bugs across the platform to improve stability and user experience.

🔍 New Features

Deep Research Workflows: Deep Search Mode for Comprehensive Results

We’ve introduced a brand new Deep Search mode into the platform’s core search experience, available through a dedicated button on the search page. This new mode gives users the flexibility to toggle between two distinct search types:

• Default Search: Fast, everyday search for common queries
• Deep Search: Designed for in-depth, layered analysis of complex information

Deep Search performs a more thorough sweep of indexed data and uses enhanced context recognition to bring forward nuanced results. Whether you’re compiling research, auditing systems, or navigating dense documentation, Deep Search helps uncover connections that traditional search might miss.

Enhanced User Analytics Integration

To better understand how teams engage with Ayraa, we’ve expanded our internal analytics capabilities to include user identification and behavioral insights. These upgrades give us a clearer picture of how features are used and help inform smarter, faster iterations of the product. These analytics are used strictly for internal improvements and are not visible to end-users.

🛠️Major Improvements

More Relevant Search Results

Our search engine’s ranking algorithm has been completely redesigned to bring the most contextually relevant information to the forefront. Whether you’re typing a general question or a complex technical phrase, Ayraa now does a better job of understanding intent and surfacing what matters most—eliminating noise while preserving depth.

Recency Bias for Default Search

Default Search now benefits from a built-in recency bias that allows newer content to rise in priority—without sacrificing relevance. This means that when your query touches on recent discussions, updates, or documents, those fresh entries are now more likely to appear at the top of your results.

ClickUp Integration Now Available

Our ClickUp integration is now fully live and operational. Users can:

• Connect ClickUp accounts directly to Ayraa
• Search across tasks, project descriptions, assignees, tags, and timelines
• Surface even nested conversations and comments within tasks

This brings ClickUp content into the same window as your documents, Slack messages, and CRM data—centralizing context and boosting cross-functional awareness.

Refreshed UI with Updated Background Colors

As part of our ongoing effort to improve visual ergonomics, we’ve updated the background color scheme across all major product views. The refreshed design enhances contrast for better readability while maintaining aesthetic consistency across modules. This also helps reduce eye strain during long sessions, making the overall user experience feel lighter and more cohesive.

🐞 Bug Fixes

Meetings & Calendar

• Fixed an issue where users on displays larger than 13 inches were unable to scroll through meetings or access older transcripts.
• Resolved a bug preventing recurring Outlook meetings from being properly indexed—now all instances show up in both search and Deep Research Workflows.
• Corrected inconsistencies in time display between Outlook calendar events and the Meetings app interface.

Search & Assist

• Removed irregular character strings from search result cards.
• Fixed an issue where confidence scores were duplicated when toggling between Assist views.
• Collections now properly handles and returns responses to queries about Ayraa’s own product features.
• Resolved an issue where follow-up queries using the "Anytime" filter returned blank or incomplete responses.
• Fixed a UI overlap where the "Most Relevant" button interfered with surrounding elements on smaller screens.

Integrations

• Fixed inconsistencies where Outlook emails were not appearing in search results despite being indexed.
• Eliminated duplicate Outlook email references in result cards.
• Fixed a bug in MS Teams integration where DMs were only accessible in "Anytime" but not in "Recent" mode.
• Addressed a rare issue where workspace transitions caused loss of access or unexpected logout behavior.

User Management

• Improved the flow for deactivating users and upgrading workspace tiers, ensuring a clean state between active and deactivated accounts.

⚡Performance Enhancements

Faster Search Experience

Recent optimizations in query handling and result indexing have led to significantly faster performance across the board. Search results in Default Mode are now returned nearly instantaneously, allowing for quicker workflows. Meanwhile, Deep Search maintains its depth and richness without compromising the rest of the platform’s responsiveness.

Improved MS Teams Query Performance

We've improved query speeds for Microsoft Teams, especially for more complex requests that previously resulted in delays. This ensures smoother usage and less friction for teams relying on MS Teams as a core part of their communication stack.

Overview

This week’s release brings new ways to streamline your workflows, stay informed, and move faster across the platform. Highlights include the launch of Deep Research Workflows, new built-in collections, upgraded admin permissions, and speed improvements across the board.

🔍 New Features

Deep Research Workflows — Major Enhancements

DRW just leveled up. You can now build more powerful, customizable research automations across your workspace—faster and more flexibly than before.

What’s new:

• Scheduled Workflows: Set workflows to auto-run at specific times or intervals.
• Connector Control: Choose which apps (Slack, Jira, Notion, etc.) each workflow pulls from.
• Team Visibility Settings: Make workflows private or share them across your workspace.
• More Structured Outputs: Automatically generate release notes, project summaries, sales recaps, and more—with just one click.

DRW is built for deep work. These updates make it even easier to automate the research you do most often—no manual follow-up required.

Ayraa Assistant Collection

A new built-in collection has been added to your workspace—curated and maintained by Ayraa. It includes:

• Key product overviews
• Feature specs
• Platform documentation
  It lives at the end of your collection list, out of the way but always easy to find.

🛠️ Improvements

Admin Controls & Permissions

Admins now have stricter control over app integrations.
If a connector is disabled, it will now be completely hidden from non-admin users—reducing unnecessary requests and keeping things clean for everyone else.

🐞 Bug Fixes

Go Links

• Fixed the issue where Go Link cards showed “undefined” in search.
• Restored autosuggest for newly added links.

Built-in Collections

• Fixed Ayraa logo display in assist responses and folders.
• Visibility settings now correctly show “All” where applicable.
• Folder item counts are now accurate.
• Tooltips and creator names now show consistently.

⚡ Performance Enhancements

Collections

We added a warm caching system to the Collections page for faster load times and better responsiveness.

UI

Animated graphics are now 90% smaller in size—with no visual loss—resulting in smoother performance across the platform.

If you were to ask, “Why did we switch to Model X last quarter?”

A reasoning-based system wouldn’t return a static list of results. It would start in Slack, uncover the early conversations, extract the relevant Jira tickets, analyze the recorded outcomes, and review the supporting documents.

It doesn’t guess. It builds an answer — step by step — from every layer of your workspace.

Search is no longer just about finding information; it’s about understanding it. A new model is emerging, one that behaves less like a tool and more like a teammate.

Reasoning-based search goes beyond retrieval. It breaks down complex questions, creates a plan of action, and moves across systems like Slack, Jira, and Docs to assemble clear, grounded answers.

While modern AI has introduced semantic search — the ability to understand the meaning behind queries — even that remains limited in scope. What’s now taking shape is a multi-step, reasoning-driven approach capable of thinking through ambiguity, adapting to new information, and delivering synthesized insights built on real context.

From Keyword Search to Multi-Step Reasoning

Enterprise search was built for lookup, not logic.

For years, search engines worked by indexing content and matching keywords. A query meant scanning a static index and returning a list of links. Even with semantic upgrades, the process stayed the same: ask once, get back options, and sort through them yourself.

Reasoning-based search introduces a new behavior. Instead of surfacing matches, it starts with a question and charts a path. It breaks down the ask into parts, moves across tools in steps, and builds toward a conclusion. Less like a librarian. More like an analyst.

A Shift in How Search Behaves

This is a fundamental change. Traditional search engines serve static pages of results, while a reasoning-based engine iteratively seeks out the most relevant information. Instead of a single query-response, the AI dynamically plans a multi-step search strategy. It may search one repository, find a clue, then use that clue to query another source, and so on, much like how a human researcher would conduct a thorough investigation. The end result is not just documents but a synthesized answer drawn from multiple sources and reasoning steps.

Powered by LLMs Built for Reasoning

Crucially, this approach leverages the power of advanced large language models (LLMs) to perform active reasoning. New LLMs optimized for reasoning (for example, the DeepSeek-R1 model) demonstrate impressive capability to analyze problems in steps. They can plan and execute a series of searches and deductions, guided by an internal chain of thought.

Such models go beyond retrieving text – they interpret and infer from it. Industry observers note that these reasoning-optimized LLMs make multi-step search feasible in practice, whereas older "static" methods struggled with complex queries.

Privacy-First by Design

A core innovation in reasoning-based search isn't just how it retrieves — it's how it protects. Unlike traditional systems that centralize and duplicate enterprise data, this architecture is designed from the ground up to minimize exposure, honor access boundaries, and reduce long-term storage. The system doesn’t need to store everything to know everything.It doesn’t hoard your data — it uses what’s recent, fetches what’s relevant, and forgets the rest.

Here's how: 

Index Recent, Retrieve the Rest

Rather than indexing all enterprise content across all time, the system follows a hybrid strategy: it indexes only recent activity and retrieves older data on demand via secure API access. Most enterprise queries happen within the last several months, so we index and embed that recent data to enable fast, fuzzy, and semantic search. For everything beyond that window, the system doesn't rely on a stored copy. It queries source applications in real time using API-based lookups, scoped entirely to the requesting user.

This design accelerates onboarding, lowers storage requirements, and drastically reduces data exposure. In our architecture, raw documents are not stored long-term. We follow a just-in-time retrieval model that avoids unnecessary exposure. Only indexed and embedded vectors — machine-readable and not reversible — are kept. When raw content is needed to answer a query, it's pulled just-in-time and discarded immediately after.

User-Scoped Crawling

A second pillar of the system's security model is user-scoped crawling. Whether indexing recent content or retrieving historical data via APIs, the system always operates within the requesting user's permission boundaries. It only sees what the user could see manually — no admin access, no elevated visibility, no surprises.

This mirrors the way users already interact with tools like Slack, Drive, Notion, or Jira. The system simply automates that experience, securely and efficiently.

Temporary Cache, Not Permanent Storage

To improve performance during active sessions, a short-lived cache of recently accessed raw content may be held temporarily. This cache is limited in scope and cleared frequently. It exists purely to improve response speed, not for storage.

By avoiding permanent storage of raw data — and limiting even temporary access to the user's own scope — the system reduces the surface area for potential breaches. Only the indexed and embedded vectors persist, and they're not human-readable. The result is a more secure, privacy-aware foundation for enterprise search — designed for speed, built with boundaries, and respectful of the user's view of the world.

Designed for Speed, Privacy, and Trust

This design reduces risk surface, respects access boundaries, and accelerates onboarding without needing to maintain a long-term copy of an organization's full data history.

How the Reasoning-Powered Search Pipeline Works

How does multi-step, reasoning-driven search actually operate under the hood? It involves a pipeline of intelligent steps, orchestrated by both traditional retrieval techniques and modern LLM reasoning. At a high level, the process works as follows:

1. Query Planning

When a user submits a query, the reasoning model begins by analyzing the question to understand what's being asked and what kind of steps will be needed to answer it. It doesn't just rephrase the query—it devises a plan.

This might involve identifying key entities, concepts, or references that need further exploration. For example, if the user asks, "Why did we switch to Model X last quarter?", the system may start by searching Slack for early discussions about Model X, extract any referenced Jira tickets or team objections, and then run a follow-up query on Jira to see how the model performed in test environments. From there, depending on what it finds, it may branch into other tools like Notion or Google Drive.

The key distinction is that the system reasons about the query before taking action. It doesn't just search—it thinks about what to search, in what order, and why.

2. Recursive Search Execution

The system follows the plan step by step. After each search, it reads the results and decides what to do next — refine the query, shift to a new app, or dig deeper in the current source. This recursive loop allows the agent to evolve its understanding of the question over time. It doesn't rely on a single pass; it adapts as it learns more from the workspace.

3. Hybrid Retrieval (Index + API)

To search recent content, the system uses indexed and embedded data, typically covering just the past few months. This enables fast semantic and fuzzy keyword search. For historical or long-tail content, it uses secure, real-time API-based lookups directly in the apps (like Slack, Notion, Jira, Google Drive). No raw data is stored permanently, and all retrievals are performed using the user's own permissions.

4. Temporary Working Memory

As results are retrieved, the agent compiles them into a temporary memory — a scratchpad of facts, messages, or relevant excerpts. This memory is ephemeral: it only exists during the session, includes only permission-scoped content, and is not stored or reused across queries. It is not a persistent knowledge graph, but a short-lived context layer to support synthesis.

5. Answer Generation

Once the agent has gathered enough information, it generates a synthesized response. This isn't just a string of snippets — it's a grounded, coherent answer that reflects reasoning across steps, often with inline citations. Instead of pushing links or dumps of data, the system delivers a structured summary of what happened — and why — shaped by the user's own workspace.

Throughout this pipeline, the reasoning model plays a conductor role – controlling the flow of the search. It is not just answering questions from a given text; it's actively deciding how to find the answer. This approach has been described as an "agentic" form of RAG, where autonomous AI agents handle the retrieval and reasoning process dynamically. Such an agent uses reflection, planning, and tool use to hone in on the answer iteratively, a stark departure from old search setups that retrieved once and stopped.

Comparing Traditional vs. Reasoning-Based Search

To summarize the differences between legacy enterprise search and this new reasoning-based approach, the following table highlights key aspects:

As shown above, reasoning-based search solves many of the limitations that older enterprise systems have struggled with, including the complexity of queries, context, and data sensitivity. While some tools are beginning to layer in LLMs for query understanding or summarization, they still largely rely on pre-built indexes and single-pass retrieval.

The real shift happens when search becomes adaptive — when a system can decide what to fetch, how to refine, and when to stop. That means indexing what's needed (and only what's needed), retrieving everything else live, and reasoning through each step like a teammate would. It's not about removing the index — it's about using it surgically, and letting reasoning models do the rest.

Real-World Use Cases: From Search to Workflow

The true power of reasoning-based search appears when it goes beyond information retrieval and becomes part of your team's workflow. These systems don't just help you find things — they help you finish things. Below are examples rooted in actual needs we've seen across product, engineering, and operations teams:

Reconstructing Past Decisions

A product manager wants to understand why the team chose LLM Model X over Model Y last quarter. The reasoning agent starts by scanning Slack for early conversations around model evaluation. It identifies objections, testing criteria, and references to relevant Jira tickets. Then it searches those Jira tickets for outcomes, timelines, and final approvals. The result? A synthesized report summarizing who said what, when, and why — complete with citations. 

Generating Release Notes from Workspace Activity

An engineer is tasked with writing release notes. Instead of manually tracking updates across Jira and Slack, the agent is prompted to look for tickets labeled Q2-release, summarize the key features or fixes, and cross-reference related Slack discussions for implementation context. Once that context is compiled, the agent generates the release note in the correct format — and can even create a draft blog post or social caption from the same material.

Preparing a 9 a.m. Workspace Summary

Imagine starting the day with a summary of everything that changed while you were offline. The agent can compile updates from relevant Jira tickets, Slack threads you were tagged in, key doc edits, and unread emails, organizing them by urgency or topic. No more bouncing between apps to get caught up. Just a clean, contextual brief that shows what matters. 

End-of-Week Performance or Incident Reports

Need to recap this week's DevOps incidents? The agent can retrieve logs, ticket updates, and Slack reports related to incidents tagged in the last five business days, then build a timeline of what happened, what was resolved, and what still needs follow-up. It's not just a search—it's an automated report writer.

These aren't just searches. They're workflows. Each of the above scenarios involves multiple systems (Slack, Jira, Docs, Email), and multiple steps of reasoning — from identifying relevant content to synthesizing it for action. What once took an hour of digging now happens in seconds.

Conclusion: The Shift Is Already Here

Search is no longer a query box. It’s a thinking system. One that investigates, reflects, and resolves. The move from keyword matching to reasoning-based search isn't a future trend — it's already reshaping how teams work. This shift transforms how work gets done. Reasoning-based search promises a leap in how organizations harness their knowledge. 

And for teams that adopt it, the difference isn’t subtle.

It’s operational intelligence — on demand.

Overview

This release introduces a series of foundational upgrades designed to make your experience faster, smarter, and more intuitive. From smarter query understanding and end-to-end search across Google Drive and Box to major performance improvements and robust bug fixes—this update lays the groundwork for deep, reliable, and scalable knowledge work.

New Features

Deep Research for Google Drive in Workflows

You can now directly search and reference Google Drive content—docs, slides, spreadsheets—within workflows. Both semantic and keyword search are supported, so whether you remember the filename or just the topic, Ayraa will surface the right document. Use cases include generating reports, building sales summaries, or sourcing prior research—without toggling tools.

Deep Research support for Box.com in Workflows

Teams using Box can now pull relevant content into workflows without manual switching. This includes files, folders, and nested documents.
Box support unlocks unified workflows for teams collaborating across multiple storage systems, streamlining search and reducing redundancy.

Deep Research support in Jira History in Workflows

You can now access the entire change log of any Jira issue via Deep Research. From initial creation to final closure, this timeline tracks status updates, assignee handoffs, comments, and QA checkpoints. This is critical for retrospectives, compliance, and understanding dev team velocity over time.

Enhancements

Natural Language Time Understanding

Ayraa now understands time the way you speak it. Whether you're searching for “Slack discussion from Sunday” or “Meeting with John from last week,” the platform intelligently parses and scopes results across your workspace. No filters or rigid formats needed—just ask as you would in conversation.

Enhanced Jira Query Accuracy

Jira results are now smarter, faster, and more contextually accurate. We've improved how complex queries are parsed, scored, and ranked—so users working across multiple boards, projects, or teams get the right results every time.

Index Visibility Transparency

Search results now clearly show how far back your connected apps are indexed. This helps teams understand what data is searchable—and prevents confusion when older documents don’t appear in results.

Interface Refinements

• Alphabetical Connector Sorting: Easier navigation when managing many app integrations.
• Meetings App Visibility: Now more prominently displayed in app selector.
• Consistent Drive Naming: Google Drive is now labeled uniformly across all touchpoints.

Bug Fixes

Workflows & Reports

• Resolved inconsistent results in Box and Drive workflows
• Fixed broken links and formatting issues in Jira Deep Research reports
• Improved reliability of Jira history reports

User Interface

• Corrected broken icons and special character formatting in collections
• Fixed display glitches in Assist, especially with ClickUp references
• Addressed alignment and hover states for interactive tooltips and cards

Admin & Backend

• Resolved issues with app connectors remaining active after being disabled
• Fixed disappearing collection folders after creation
• Ensured stability of Google Drive tools when editing existing workflows

Performance Improvements

Warm Cache System

We’ve introduced a warm-cache model that keeps your workspace intelligently “pre-loaded.” This significantly reduces loading times for common tasks and ensures up-to-date results without stale data.

Slack Response Latency Fixes

We fixed a known delay in Slack assistant conversations, especially for direct messages and multi-turn interactions. Replies are now significantly faster and more stable.

Security Updates

Enhanced Permalink ID Security

Our updated link architecture now offers improved tenant isolation and data protection. Shared links are scoped accurately and protected with stronger permission boundaries—ensuring your data stays private, even when content is shared across teams.

Closing
The platform is becoming truly fun to build. We hope you are enjoying these updates as much as we are in working on them!

P.S. Most of this was written using a Deep Research Workflow template for Release Notes.

Why ultra-large context windows won’t replace retrieval (and how retrieval-augmented generation is evolving).

The “RAG is Dead” Argument

Every few months, a new leap in large language models triggers a wave of excitement – and the premature obituary of Retrieval-Augmented Generation (RAG). The latest example: models boasting multi-million-token context windows. Google’s Gemini model, for instance, now offers up to a 2 million token prompt, and Meta’s next LLM is rumored to hit 10 million. That’s enough to stuff entire libraries of text into a single query. Enthusiasts argue that if you can just load all your data into the prompt, who needs retrieval? Why bother with vector databases and search indices when the model can theoretically “see” everything at once?

It’s an appealing idea: give the AI all the information and let it figure it out. No more chunking documents, no more relevance ranking – just one giant context. This argument crops up regularly. RAG has been declared dead at every milestone: 100K-token models, 1M-token models, and so on. And indeed, with a 10M-token window able to hold over 13,000 pages of text in one, it feels as though we’re approaching a point where the model’s “immediate memory” could encompass an entire corporate knowledge base. Why not simply pour the whole knowledge base into the prompt and ask your question?

But as with many things in technology, the reality is more complicated. Like a lot of “this changes everything” moments, there are hidden trade-offs. Let’s examine why the reports of RAG’s death are – as Mark Twain might say – greatly exaggerated.

The Scale Problem: Context ≠ Knowledge Base

A key premise of the “just use a bigger context” argument is that all relevant knowledge can fit in the context window. In practice, even ultra-long contexts are a drop in the bucket compared to the scale of real-world data. Enterprise knowledge isn’t measured in tokens; it’s measured in gigabytes or terabytes. Even a 10M-token context (which, remember, is fantastically large by today’s standards) represents a tiny fraction of an average company’s documents and data. One analysis of real company knowledge bases found that most exceeded 10M tokens by an order of magnitude, and the largest were nearly 1000× larger. In other words, for a 10 million token window, some organizations would need a 10 billion token window to load everything – and tomorrow it will be even more.

It’s the age-old story: as memory grows, so does data. No matter how large context windows get, knowledge bases will likely grow faster (just as our storage drives always outpace our RAM). That means you’ll always face a filtering problem. Even if you could indiscriminately dump a huge trove of data into the model, you would be showing it only a slice of what you have. Unless that slice is intelligently chosen, you risk omitting what’s important.

Crucially, bigger context is not the same as better understanding. We humans don’t try to read an entire encyclopedia every time we answer a question – we narrow our focus. Likewise, an LLM with a massive buffer still benefits from guidance on where to look. Claiming large contexts make retrieval obsolete is like saying we don’t need hard drives because RAM is enough. A large memory alone doesn’t solve the problem of finding the right information at the right time.

Diminishing Returns of Long Contexts (The “Context Cliff”)

Another overlooked issue is what we might call the context cliff – the way model performance degrades as you approach those lofty context limits. Just because an LLM can take in millions of tokens format-wise doesn’t mean it can use all that information effectively. In fact, research shows that models struggle long before they hit the theoretical max. A recent benchmark by the NoLiMa Study by Cornell University (1) designed to truly test long-context reasoning (beyond trivial keyword matching) found that by the time you feed a model 32,000 tokens of text, its accuracy in pulling out the right details had plummeted – dropping below 50% for all tested models. Many models start losing the thread with even a few thousand tokens of distraction in the middle of the prompt.

This “lost in the middle” effect isn’t just a rumor; it’s been documented in multiple studies. Models tend to do best when relevant information is at the very beginning or end of their context, and they often miss details buried in the middle. So, if you cram 500 pages of data hoping the answer is somewhere in there, you might find the model conveniently answered using something from page 1 and ignore page 250 entirely. The upshot: ultra-long inputs yield diminishing returns. Beyond a certain point, adding more context can actually confuse the model or dilute its focus, rather than improve answers.

In real deployments, this means that giving an LLM everything plus the kitchen sink often works worse than giving it a well-chosen summary or snippet. Practitioners have noticed that for most tasks, a smaller context with highly relevant info beats a huge context of raw data. Retrieval isn’t just a clever trick to overcome old 4K token limits – it’s a way of avoiding overwhelming the model with irrelevant text. Even the latest long-context models “still fail to utilize information from the middle portions” of very long texts effectively. In plain terms: the larger the context, the fuzzier the model’s attention within it.

The Latency and Cost of a Token Avalanche

Let’s suppose, despite the above, that you do want to stuff a million tokens into your prompt. There’s another problem: someone has to pay the bill – and wait for the answer. Loading everything into context is brutally expensive and slow. Language models don’t magically absorb more text without a cost; processing scales roughly linearly with input length (if not worse). 

In practical terms, gigantic contexts can introduce latency measured in tens of seconds or more. Users have reported that using a few hundred thousand tokens in a prompt (well under the max) led to 30+ second response times, and up to a full minute at around 600K tokens. Pushing toward millions of tokens often isn’t even feasible on today’s GPUs without specialized infrastructure. On the flip side, a system using retrieval to grab a handful of relevant paragraphs can often respond in a second or two, since the model is only reasoning over, say, a few thousand tokens of actual prompt. That’s the difference between a snappy interactive AI and one that feels like it’s back on dial-up.

Then there’s cost. Running these monster prompts will burn a hole in your wallet. Even if costs fall over time, inefficiency is inefficiency. Why force the model to read the entire haystack when it just needs the needle? It’s like paying a team of researchers to read every book in a library when you have the call number of the one book you actually need. Sure, they might find the answer eventually – but you’ve wasted a lot of time and money along the way. As a contextual AI expert put it, do you read an entire textbook every time you need to answer a question? Of course not!

In user-facing applications, these delays and costs aren’t just minor annoyances – they can be deal-breakers. No customer or employee wants to wait 30 seconds for an answer that might be right. And no business wants to foot a massive cloud bill for an AI that insists on reading everything every time. 

Adding only the information you need, when you need it, is simply more efficient.

Training vs. Context: The Limits of “Just Knowing It”

Some might argue: if long contexts are troublesome, why not just train the model on the entire knowledge base? After all, modern LLMs were trained on trillions of tokens of text – maybe the model already knows a lot of our data in its parameters. Indeed, part of the allure of very large models is their parametric memory: they’ve seen so much that perhaps the factoid or document you need is buried somewhere in those weights. Does that make retrieval redundant?

Not really. There’s a fundamental distinction between what an AI model has absorbed during training and what it can access during inference. Think of training as the model’s long-term reading phase – it’s seen a lot, but that knowledge is compressed and not readily searchable. At inference time (when you prompt it), the model has a limited “attention span” – even 10 million tokens, in the best case – and a mandate to produce an answer quickly. It can’t scroll through its training data on demand; it can only draw on what it implicitly remembers and what you explicitly provide in the prompt. And as we’ve seen, that implicit memory can be fuzzy or outdated. Yes, the model might have read a particular document during training, but will it recall the specific details you need without any cues? Often, no. It might instead hallucinate or generalize, especially if the info wasn’t prominent or has since changed.

This is why RAG was conceived in the first place – to bridge the gap between a model’s general training and the specific, current knowledge we need at query time. RAG extends a model’s effective knowledge by fetching relevant snippets from external sources and feeding them in when you ask a question. It’s a bit like giving an open-book exam to a student: the student might have studied everything, but having the textbook open to the right page makes it far more likely they’ll get the answer right (and show their work). With RAG, the language model doesn’t have to rely on the hazy depths of its memory; it can look at the exact data you care about, right now. This not only improves accuracy but also helps with issues like hallucination – the model is less tempted to make something up if the source material is right in front of it.

Moreover, enterprise data is often private, proprietary, and constantly changing. We can’t realistically pre-train or fine-tune a giant model from scratch every time our internal wiki updates or a new batch of customer emails comes in. Even if we could, we’d still face the inference-time limits on attention. The model might “know” the latest sales figures after fine-tuning, but unless those figures are somehow prompted, it might not regurgitate the exact number correctly. Retrieval lets us offload detailed or dynamic knowledge to an external store and selectively pull it in as needed. It’s the best of both worlds: the model handles the general language and reasoning, and the retrieval step handles the targeted facts and context.

Finally, there’s an important practical concern: permission and security. If you naively dump an entire company’s data into a prompt, you risk exposing information to the model (and thus to users) that they shouldn’t see. In a large organization, not everyone can access all documents. RAG systems, by design, can enforce access controls – retrieving only the content the user is allowed to know. In contrast, a monolithic prompt that contains “everything” can’t easily disentangle who should see what once it’s in the model’s context. This is especially vital in domains like finance or healthcare with strict data governance. In short, retrieval acts as a gatekeeper, ensuring the AI’s knowledge use is not just relevant, but also compliant with rules and roles.

RAG Is Evolving, Not Dying

All this isn’t to say long context windows are useless or that we shouldn’t celebrate larger memory in our models. They are a genuine breakthrough, and they will enable new capabilities – we can give our AIs more background and sustain longer dialogues now. But rather than eliminating the need for retrieval, these advances will augment and transform it. The smartest systems will use both a big context and retrieval, each for what it’s best at. It’s not a binary choice. As one AI leader put it, we don’t need to choose between RAG and long contexts any more than we must choose between having RAM and having a hard drive – any robust computer uses both.

In fact, RAG is likely to become more integrated and nuanced in the future, not less. The naive version of RAG – “search and stuff some text chunks blindly into the prompt” – may fade, but it will be replaced by smarter retrieval paradigms that work hand-in-hand with the model’s training and reasoning. Future retrieval-augmented systems will be:

• Task-aware and context-sensitive: Rather than retrieving text in a vacuum, they’ll understand what the user or application is trying to do. They might fetch different kinds of information if you’re writing an email vs. debugging code vs. analyzing a contract. They’ll also leverage the model’s improved ability to handle longer context by retrieving richer, more relevant packs of information (but still only what’s needed). In essence, retrieval will become more intelligent curation than brute-force search.
• Secure and personalized: As discussed, retrieval will respect user permissions and roles, acting as an intelligent filter. It might maintain a “five-year cache” of knowledge for an employee – the documents and data most relevant to their job from the past few years – so that common queries are answered from that cache almost instantly. Meanwhile, less frequently needed or older information can be fetched on demand from deeper storage. By tailoring what is readily accessible (and to whom), RAG can provide fast access to the right slice of knowledge for each scenario, without ever exposing things a user shouldn’t see.
• Cost-efficient and balanced: We’ll see systems strike a balance between brute-force ingestion and selective retrieval. If (or when) context windows expand even further, RAG techniques might shift to feeding the model a pre-organized dossier of relevant information, rather than a hodgepodge of raw text. That is, retrieval might pre-digest the data (through summarization or indexing) so that even a large context is used optimally. The endgame is that each token the model sees is likely to be useful. This keeps token costs down and latency low, even if the “raw” available data grows without bound. RAG will also work in tandem with model fine-tuning: if there are pieces of knowledge every user will need often, those can be baked into the model weights or prompt defaults, while the long tail of specific info remains handled by retrieval.

In short, RAG isn’t dying – it’s maturing. We’ll probably stop thinking of “RAG” as a separate module and see it become a seamless part of how AI systems operate, much like caching and indexing are just a normal part of database systems. The next time someone confidently pronounces “RAG is dead,” remember that we’ve heard that before. Each time, we later discover that retrieval remains essential – it just adapts to the new landscape. As long as we have more data than we can cram into a model’s head at once (which will be true for the foreseeable future), we’ll need mechanisms to choose what to focus on.

The future will belong to those who master both aspects: building models that leverage large contexts and designing retrieval that makes those contexts count. The tools and terminology may evolve (maybe we’ll call it “context orchestration” or something else), but the underlying principle – that targeted information access matters – will hold. Far from being a relic of the past, RAG may be the key to making these ever-more-powerful models actually useful in the real world.

After all, it’s not about how much information you can shove into a prompt – it’s about giving the right information to the model at the right time.

And that is a problem we’ll be solving for a long time to come.

(1) https://arxiv.org/abs/2502.05167

Overview

This release period introduces several exciting new features and improvements, including our groundbreaking Deep Research Workflows feature, a new ClickUp integration, enhanced support for Salesforce Cases, and significant improvements to search, assist, and follow-up query functionality. We've also made numerous bug fixes and performance enhancements to provide a smoother, more reliable experience throughout the platform.

New Features

Deep Research Workflows

Deep Research Workflows revolutionizes how you extract insights from your workplace data. This powerful new feature allows you to create, schedule, and run sophisticated research workflows that automatically generate comprehensive reports from your integrated apps. With DRW, you can:

• Set specific instructions and let AI handle complex multi-step research tasks
• Schedule workflows to run automatically at your preferred times
• Customize visibility settings for seamless team collaboration
• Select specific app connectors to include in your research

From automated release notes and JIRA activity reports to sales analytics and workspace recaps, DRW enables workflows you never thought possible. This feature represents a significant advancement in research capabilities, allowing you to focus on deep work while automating routine information gathering.

ClickUp Integration

Our new ClickUp integration enables seamless search across all your ClickUp tasks, docs, and projects. This connector covers task names, descriptions, assignees, reporters, statuses, tags, comments, due dates, and associated documents. Designed for product management, operations, project management, engineering, and marketing teams, this integration brings clarity and speed to your workflows by unifying ClickUp data within your enterprise search experience.

Salesforce Cases Support

You can now query Salesforce Cases related to opportunities, accounts, and contacts. This enhancement is particularly valuable for customer service and sales teams who need to quickly find information across their Salesforce Cases ecosystem. The integration allows for natural language queries and delivers comprehensive results with proper formatting and context.

Multi-message Responses in Slack

The Ayraa Slack bot now supports multi-message responses, breaking longer responses into multiple messages when necessary. This ensures that all information—including references—is properly displayed, even for detailed queries that exceed Slack's character limits. No more truncated responses or missing references!

Major Improvements

Search and Assist Enhancements

• More Concise Search Responses: Search responses are now more concise and to the point, with a clear indication to use Assist for more interactive experiences
• Better AI Model: Upgraded to the latest GPT-4.1 model for improved response quality and accuracy
• Automatic Recovery from AI Glitches: Added automatic retry mechanism to handle occasional blank responses from AI
• Custom Slack Messaging: Slack at-ayraa messaging is now tailored based on which apps you have connected
• Improved JIRA Query Accuracy: Complex JIRA queries now return more accurate and helpful results

Follow-up Query Improvements

• Context Preservation: Fixed issues where follow-ups incorrectly included data from old sessions
• Better Context Understanding: Follow-up queries now better understand the context from earlier related queries
• Extended Related Information: Improved ability to find related information across sessions
• Enhanced External Knowledge Integration: Fixed confusion between external and workspace knowledge in follow-ups

Meeting Features

• Email Sharing for Meeting Summaries: You can now share meeting summaries via email, making it easier to distribute important information to participants
• Team Sharing Improvements: Enhanced ability to share meeting transcripts with teams including the "All" team
• Ad-hoc Meeting Transcripts: Hosts now properly receive transcripts for ad-hoc meetings

Stalled Thread and Discover Improvements

• Weekend-Aware Stalled Detection: Stalled thread detection now intelligently skips weekend hours
• Cross-Timezone Support: Improved timing calibration for stalled detection across different time zones
• More Reliable Discover Scribes: Fixed discover automation for consistent scribe creation
• Smarter Thread Detection: Improved accuracy of thread status detection to reduce false-positive stalled notifications

User Experience Improvements

• Streamlined Signup Flow: Simplified email field during signup
• Gmail Sign-up Support: Enabled Gmail sign-up to improve accessibility
• Profile Picture Integration: Improved auto-fetching of profile pictures from Google/Microsoft accounts
• Enhanced Integration Pages: Improved responsiveness and clarity of integration success, failure, and cancel pages
• Go Links Improvements: Enhanced Go Links search text and functionality
• Dialog Improvements: Fixed visual issues with dialog pop-ups

Bug Fixes

Search and Assist Fixes

• Fixed opportunity card and hover references display in the Anytime filter
• Resolved collections search issues with the Anytime filter
• Fixed missing AI summaries for certain Jira status-based searches
• Improved Anytime search response time
• Fixed HTML tags appearing in reports
• Resolved 'exception occurred' error for specific Slack results
• Fixed double confidence scores for collection follow-ups
• Fixed empty reference sections in At-Ayraa queries

Collections and Documents Fixes

• Fixed "exception occurred" error for existing cards/files in folders
• Resolved issues when adding subject matter experts to team-shared collection folders
• Fixed team selection in sharing options during new collection creation
• Improved scrolling functionality for the collections page
• Fixed search functionality for collection cards by username

Meetings and Collaboration Fixes

• Fixed mixed-up icons on the meetings page
• Fixed meeting retention setting changes from months to days
• Resolved user email persistence issues in the "share with" field across meeting summaries
• Fixed issues with icons not loading correctly

User Interface Fixes

• Fixed User Pilot flow issues during Go link creation
• Fixed app connectors incorrectly showing as disabled in individual mode
• Fixed the flow after creating a collection folder
• Improved admin visibility of users in new workspaces
• Fixed missing invitation emails when adding users
• Fixed Go Links alignment issues

Performance Enhancements

• Faster Queries: Removed unnecessary processing for multi-keyword queries, saving 1000-1500ms per query
• Smarter UI Loading: Implemented optimized loading of UI components for faster page rendering
• Enhanced Semantic Search: Improved accuracy and performance of semantic search functionality
• Streamlined Response Generation: Optimized the response pipeline for follow-up queries

Cached Content Utilization: Improved performance by using cached content for discovery and stalled thread detection

New Features
• Add Confluence Search Tool: – Introduces an integrated Confluence search capability that uses a hybrid approach (native API plus RM semantic search) to deliver more comprehensive content retrieval.
• Add Meetings Tool (searching over meeting transcripts) – Adds a new capability for searching through meeting transcripts so that users can quickly retrieve discussion details; note that this feature remains blocked by a pending dependency in the backend integration but has been flagged as a new feature.

Enhancements

• Deep Research Workflow
  • Remove "work" from email prompts – The UI text ("Enter your work email") has been updated by removing the term "work" to ensure clarity and consistency during signup and across related screens.
  • Decouple Workflow Save from Execution – Workflow creation now allows users to save without triggering immediate execution, thereby aligning with user expectations and design guidelines.
  • Personalize Workflow Reports – Workflow report visibility has been revised so that reports are always tied to the user who triggered the workflow rather than being shared broadly.

• Revise Critical Scan Query – The critical pricing scan query has been updated to use a non-collection approach, improving automation reliability when handling pricing structure queries.
• Integrate LLM-Based Filtering – Enhanced connector search functionality now uses LLM-based filtering (especially for Slack), which reduces irrelevant noise and improves overall result quality.

+4 other minor enhancements

Bug Fixes
A broad range of bug fixes has been implemented to address issues across workflows, reporting, and integrations:

• Address Pagination Issue in Workflow Tiles – Increased the data limit (from 10 to 100) so that users can scroll to view additional workflow tiles without a design rework.
• Resolve Multiple UI/UX Issues in Workflow Pop-Up – Improvements include matching button sizes, proper spacing (10px gaps), and reduced font size in certain areas for better consistency.
• Fix Mobile and Web Email Formatting for Workflow Reports – Email presentation has been refined to align with Figma designs across devices.
• Ensure Correct data Appears in Workflow Reports – Adjustments to the JQL query have resolved issues where workflows were previously returning no data or references.
• Address Ad Hoc Meeting Summary Delivery – Corrected an issue where only the host was receiving meeting summaries, ensuring that all qualified participants receive notifications.
• Address Missing Jira References in Salesforce Responses – Resolved a token-related issue that was causing only a partial set of Jira references to appear.
• Reinforce Personalization of Workflow Reports – Adjustments have been made to ensure that reports appear only for the creator even for shared workflows.
• Restore Salesforce Query Functionality for Assist – Updated query logic now prevents errors and ensures Salesforce data is returned correctly.
• Automate Sanity Checks Post Deployment – Automated critical scans now follow commit deployments, ensuring that new changes are promptly verified.
• Fix Google Calendar Search Chat Issue – The search+chat feature now reliably returns responses for calendar-related queries.

+41 other bug fixes