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.

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:

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.

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.

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.

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.

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

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.

Almanac runs as a stateful service with three components:

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.

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.

def select_context(task: str, user_id: str, max_tokens: int = 3000) -> list[WikiPage]:
    entities = extract_entities(task)

    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
    )

    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
    )

    pages = merge_results(keyword_results, semantic_results, top_k=3)

    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.

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

Use Almanac's architecture when:

Avoid this approach when:

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.