Almanac's Company-Context Agent: How YC S26 Wires Internal Knowledge into Every LLM Call

Almanac (YC S26) launched with a promise to solve the context-persistence problem that breaks most multi-agent financial systems: agents that forget company policies between calls, hallucinate org structure, or ask the same questions twice. Their pitch is "Hermes with a brain," an agent that maintains a self-updating wiki of company knowledge and injects relevant context into every LLM call.

The infrastructure challenge is not retrieval-augmented generation (RAG) itself. It's building a system that decides which company documents to inject, enforces permission boundaries across departments, handles context drift when policies change, and manages token budgets when company context competes with user queries in the same prompt window.

The Context Injection Problem

Most agent systems treat company knowledge as static embeddings in a vector store. You chunk documents, embed them, retrieve top-k matches, and stuff them into the prompt. This breaks in production for three reasons:

1. Stale context: Company policies change daily. Embeddings lag behind reality unless you re-index continuously.
2. Permission leakage: Naive retrieval pulls documents the user shouldn't see. You need row-level security at query time.
3. Token budget collapse: Injecting five pages of company context leaves no room for the actual user query or agent reasoning.

Almanac's approach is to maintain a live wiki that compiles activity from connected tools (Slack, Gmail, Granola notes, GitHub issues) and updates pages in real time. The agent reads this wiki before every action. The wiki is not a cache. It's the source of truth.

Retrieval Pipeline Architecture

The system has three layers:

1. Tool connectors: OAuth integrations that stream events from Slack channels, email threads, calendar invites, and project management tools. Each event is tagged with metadata (author, timestamp, project, customer name).

2. Wiki compiler: A background process that groups related events into pages. A customer page aggregates all Slack threads, emails, and meeting notes about that customer. A project page compiles GitHub issues, pull requests, and design docs. The compiler runs continuously, not on a schedule.

3. Context selector: When the agent receives a task ("draft a renewal deck for Vercel"), the selector queries the wiki for relevant pages. It uses a combination of keyword matching (entity extraction from the task) and semantic search (embedding similarity). The selector returns a ranked list of pages, not raw documents.

The agent then reads the top three pages and decides whether it has enough context to proceed. If not, it asks clarifying questions or searches for additional pages.

Permission Boundaries

The hardest part is preventing agents from leaking sensitive data across department boundaries. Almanac's permission model has two enforcement points:

At ingestion: When the wiki compiler processes a Slack message or email, it inherits the access control list (ACL) from the source tool. A message in #finance-internal is tagged with the list of users who can see that Slack channel. The wiki page that includes that message inherits the same ACL.

At retrieval: When the context selector queries the wiki, it filters pages by the user who initiated the agent task. If the user can't see the source Slack channel or email thread, the page is excluded from results.

This is row-level security at the document level. It's not perfect. If a user forwards a sensitive email to a public Slack channel, the wiki page becomes visible to everyone in that channel. The system does not try to detect or prevent this. It trusts the source tool's permissions.

Token Budget Strategy

Company context competes with user queries and agent reasoning in the same prompt window. Almanac uses a tiered budget (values estimated based on typical LLM constraints and observed behavior from the product demo):

If the top three wiki pages exceed 3,000 tokens, the system summarizes them using a separate LLM call. The summary preserves key facts (customer name, renewal date, pricing terms) but drops conversational filler. This adds 200-400ms of latency but prevents context truncation.

The agent can request additional pages if it needs more context. This triggers a second retrieval pass and a new token budget calculation. Most tasks resolve in one or two passes.

Context Drift and Re-Indexing

When company policies change, stale context poisons future agent calls. Almanac handles this with event-driven updates:

• Slack message edited: The wiki compiler re-processes the thread and updates the relevant page.
• Email recalled: The page is marked as outdated and excluded from retrieval until the user confirms the change.
• GitHub issue closed: The project page is updated to reflect the new status.

There is no batch re-indexing. Every change propagates to the wiki in real time. This works because the wiki is small (hundreds of pages, not millions of documents). The entire wiki fits in memory on a single server.

The tradeoff is consistency. If two users edit the same Slack thread simultaneously, the wiki compiler processes events in the order they arrive. The last write wins. This is acceptable for most financial workflows, where conflicts are rare and users can manually reconcile discrepancies.

Deployment Shape

Almanac runs as a stateful service with three components:

1. Event ingest workers: One worker per connected tool. Each worker polls the tool's API for new events and writes them to a Postgres queue.
2. Wiki compiler: A single-threaded process that reads from the queue, groups events into pages, and writes to the wiki store (also Postgres).
3. Agent runtime: A pool of workers that handle user tasks. Each worker queries the wiki, calls the LLM, executes tool actions, and streams results back to the user.

The agent runtime is stateless. Each task is independent. The wiki compiler is stateful and runs on a single server to avoid consistency issues. If the compiler crashes, it resumes from the last processed event in the queue.

The system does not use a vector database. All retrieval happens in Postgres with full-text search (tsvector) and pg_embedding for semantic similarity. This keeps the stack simple and avoids the operational complexity of managing a separate vector store.

Failure Modes

1. Permission drift: If a user's access to a Slack channel is revoked, the wiki compiler does not retroactively remove pages that include messages from that channel. The user can still see historical context until the page is updated with new events.

2. Token budget overflow: If a user asks a complex question that requires five wiki pages, the system summarizes all five. The summary may drop critical details. The agent does not warn the user about this.

3. Tool API rate limits: If the event ingest worker hits a rate limit, it backs off exponentially. During the backoff period, new events are not processed. The wiki becomes stale. The agent does not know this and may return outdated context.

4. Context injection latency: Retrieving and summarizing wiki pages adds 200-800ms to every agent call. For high-frequency tasks (monitoring alerts, real-time trading signals), this latency is unacceptable.

Code Snippet: Context Selector Query

def select_context(task: str, user_id: str, max_tokens: int = 3000) -> list[WikiPage]:
    # Extract entities from task (customer names, project names)
    entities = extract_entities(task)

    # Keyword search for exact matches
    keyword_results = db.execute(
        """
        SELECT id, title, content, ts_rank(search_vector, query) as rank
        FROM wiki_pages
        WHERE search_vector @@ plainto_tsquery('english', :entities)
          AND :user_id = ANY(acl)
        ORDER BY rank DESC
        LIMIT 10
        """,
        entities=" ".join(entities),
        user_id=user_id
    )

    # Semantic search for related pages
    task_embedding = embed(task)
    semantic_results = db.execute(
        """
        SELECT id, title, content, 1 - (embedding <=> :task_embedding) as similarity
        FROM wiki_pages
        WHERE :user_id = ANY(acl)
        ORDER BY similarity DESC
        LIMIT 10
        """,
        task_embedding=task_embedding,
        user_id=user_id
    )

    # Merge and deduplicate results (combines keyword + semantic scores)
    pages = merge_results(keyword_results, semantic_results, top_k=3)

    # Summarize if total tokens exceed budget
    total_tokens = sum(count_tokens(p.content) for p in pages)
    if total_tokens > max_tokens:
        pages = [summarize_page(p, max_tokens // len(pages)) for p in pages]

    return pages

The query combines full-text search (keyword matching) and vector similarity (semantic search). Both queries filter by the user's ACL. The results are merged, deduplicated, and summarized if they exceed the token budget.

Technical Verdict

Core tradeoff: Almanac chooses context freshness and operational simplicity over scale and sub-second response times.

Use Almanac's architecture when:

• Your company has 10-500 employees and a manageable number of tools (Slack, email, GitHub, a CRM).
• Context freshness matters more than retrieval latency. You can tolerate 200-800ms per agent call.
• You need permission boundaries but can accept eventual consistency (permission changes take seconds to propagate).
• Your agents handle tasks that require cross-tool context (customer renewals, project status, compliance checks).

Avoid this approach when:

• You have millions of documents or thousands of users. The single-threaded wiki compiler will not scale.
• You need sub-100ms agent response times. The context injection latency is too high.
• Your permission model requires strict consistency. The last-write-wins strategy will cause data races.
• Your agents operate in regulated environments where stale context or permission drift is unacceptable.

The system works because it trades off scale for simplicity. A single Postgres instance, a single compiler thread, and no vector database. This is the right tradeoff for most early-stage companies. It breaks when you hit 1,000 employees or 10 million documents.

Source Links

• Almanac homepage
• Launch HN discussion