​
How is Asimov’s approach different from RAG? How does it work?

Why don’t we just use RAG like everyone else? It’s a fair question—RAG has become the go-to approach for most AI systems that need to work with large knowledge bases.

The fundamental issue is that RAG decouples relevance from reasoning—it forces you to decide what’s relevant before you start reasoning. It’s like being required to gather all your research materials before you’re allowed to think about a problem. In practice, this creates an awkward workflow: retrieve some snippets, reason with only those snippets, and if you realize you need different information… tough luck. You’re stuck with your initial retrieval choices.

Think about how you actually research complex questions. You start with some Google searches, read a bit, realize you need to look up something tangential, do more searches, connect some dots, then search again with better keywords. RAG systems cannot do this—they get one shot at retrieval and have to make it work.

Our approach flips this around entirely.

Instead of giving our agent a few carefully selected snippets, we give it everything from the start—your entire codebase, all your Teams history, every GitHub discussion, all your documentation. The agent is born knowing your whole system and can dynamically focus its attention on whatever becomes relevant as it reasons through a problem.

This means when someone asks “why does the authentication service sometimes fail during peak hours?”, our agent does not have to guess which specific files, conversations, or docs might be relevant. It can start with the auth service code, notice a reference to rate limiting, follow that thread to a Teams discussion from six months ago, connect it to a recent incident report, and tie it all together. This dynamic, iterative reasoning within the full context happens fluidly as the agent synthesizes insights across disparate pieces of information.

We make this work at scale through two key innovations our team helped pioneer:

  • Expanded context windows (so we can actually fit all this information)
  • Efficient context caching (so we’re not reprocessing everything from scratch each time)

The result? Instead of agents that can use more tools, we have agents with comprehensive knowledge that can synthesize insights across your entire engineering ecosystem.

​
Can’t I just use MCP + a code generation tool?

Most AI coding tools use tool-based architectures where agents make real-time API calls to access your systems. When you ask a question, the agent must decide upfront which specific tools to call—perhaps the GitHub API to search issues, the Teams API to find messages, or the codebase search API to find relevant files. Each data source requires separate API calls with specific query parameters, forcing the agent to predict what information will be relevant before it begins reasoning.

This approach works well for targeted actions like “create a pull request to fix issue #123” where the required information is clearly scoped. However, it fundamentally breaks down when comprehensive understanding is needed across your entire engineering ecosystem.

Consider this scenario: An authentication bug appears during peak traffic, but the root cause spans multiple contexts. The relevant information might include:

  • Code changes from a recent pull request
  • A performance discussion buried in a 6-month-old chat thread
  • A related incident report in your ticketing system
  • Architecture decisions documented in a Google Doc

With traditional tool-based approaches, the agent must guess which APIs to call and which search terms to use. It might find the code changes but miss the chat context entirely. Even worse, it cannot iteratively refine its understanding. If the agent’s initial API calls do not surface the right information, it’s stuck with incomplete context.

Asimov ingests everything upfront: code, docs, Teams chat history, GitHub threads, Jira tickets—into a unified knowledge base. The result: Instead of agents overburdened with ever more tools, Asimov has the comprehensive knowledge that can synthesize insights across your entire engineering ecosystem in real-time.

In other words, traditional integrations optimize for real-time data access. We optimize for deep synthesis across your entire engineering ecosystem.

​
Can I provide additional context to Asimov with third-party repos?

Yes! Asimov works best when you connect it with the code that matters most to your team, be it proprietary internal projects or public projects like PyTorch.

Navigate to Settings, scroll down to Data Sources and then add the repo link under Add public repository.

Add public repository link field in Settings screen

​
What do I do if Asimov answers incorrectly?

If the answer is wrong because the underlying source is incorrect, you can create a memory for Asimov to recall in future queries. Asimov will remember this piece of information and correct its understanding of your codebase accordingly.

You can also use citations to go directly to the incorrect source and change the information there.

If the answer is wrong because Asimov hallucinated, let us know by marking the response with a thumbs-down and explaining what was incorrect. This helps improve future responses and gives you a chance to provide helpful context.

​
How frequently does the agent index against knowledge sources? Is it up to date?

Asimov continuously monitors your connected data sources and updates its knowledge base as changes occur. The indexing frequency depends on the type of integration:

  • GitHub repositories: Updates are processed within minutes of commits and pull requests
  • Team chat conversations: New messages are indexed in near real-time
  • Documentation: Changes are reflected reactively within minutes, just like your code

You can check the last sync time for each data source in your Settings > Data Sources panel.