Zurück

Astell Search

Understand how Astell provides actionable context through Astell Search

What Astell Search is

Astell Search is a permission-aware context layer, not "semantic search across tools." Instead of live-fetching across silos on every question, Astell ingests and indexes your workspace so it can retrieve sources quickly, rank them with context, and keep results consistent. When you ask a question, Astell returns the right sources with the right context, without you needing to remember where something lives, who wrote it, or what version is current.

What Astell Search is optimized for

Most teams don't struggle with "search". They struggle with fragmentation and context reconstruction. Answers are spread across chat threads, docs, tickets, and PR discussions; even when you find a match, you still need to know whether it's the latest version, who owns it, and what it relates to; and the same term can mean different things across systems. Astell Search treats your workspace like one system: it retrieves across tools, enforces permissions, and uses context signals to rank what's most likely the real answer.

How Astell Search works

Astell Search is a pipeline:

1. Ingest and normalize your workspace data
2. Index it for fast retrieval, using multiple retrieval methods
3. Route and rerank results using context
4. Return sources that are permission-valid and time-relevant

Because context is kept indexed and ready, search is fast and consistent. Astell isn't rebuilding context from scratch on every query.

The ingestion layer

Before search can work well, data is shaped into something searchable. Astell ingests content from connected tools and normalizes it:

• Content extraction: pulling text and metadata (author, timestamps, location, type) from each system
• Chunking and structuring: long documents and threads are split into chunks so retrieval is precise instead of all-or-nothing
• Entity recognition and normalization: mapping people, teams, projects, customers, tickets, repos, and docs into stable identities, so the same thing isn't missed under slightly different names
• Time-aware versioning signals: capturing update timestamps and change history so search can prioritize the most current or most relevant version

The retrieval layer

Astell uses hybrid retrieval because no single technique works for every query. Keyword/lexical retrieval is best when you know exact identifiers or phrases: ticket IDs, repo names, error codes, precise project or customer names. Semantic retrieval is best when you know the idea but not the exact wording: "the doc where we decided the migration approach." Astell combines both to build a candidate set broad enough to catch the right answer but still high-quality.

Ranking and relevance

Retrieval finds candidates; ranking decides what's most useful. Astell ranks using context signals: source system, author/ownership, recency and change history, relationships (linked threads, tickets, PRs, documents), content type, and query intent. The goal is to surface the source most likely to be the correct entry point for what you're asking.

Permission enforcement

Astell Search is permission-aware. It only returns results the user is allowed to access, based on the underlying system permissions. This is what makes cross-tool search usable in real organizations: you can search broadly without accidentally leaking restricted content.

Why this is more reliable than live-fetch search

In live-fetch systems, every query triggers an agent to crawl multiple apps in real time, which creates three problems: latency (round trips to many systems), variance (results shift depending on what the agent fetches or misses), and cost (repeated retrieval triggers repeated model calls). Astell avoids this by keeping workspace data indexed and context-ready, so search is retrieval-first, not crawling-first.