{"slug": "almanac-s-company-context-agent-how-yc-s26-wires-internal-knowledge-into-every", "title": "Almanac's Company-Context Agent: How YC S26 Wires Internal Knowledge into Every LLM Call", "summary": "Almanac, a Y Combinator S26 startup, has launched an agent system that maintains a self-updating wiki of company knowledge and injects relevant context into every LLM call to solve context-persistence problems in multi-agent financial systems. The system uses tool connectors, a continuous wiki compiler, and a context selector with permission enforcement to manage company context and prevent data leaks.", "body_md": "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.\n\nThe 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.\n\nMost 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:\n\nAlmanac'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.\n\nThe system has three layers:\n\n**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).\n\n**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.\n\n**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.\n\nThe 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.\n\nThe hardest part is preventing agents from leaking sensitive data across department boundaries. Almanac's permission model has two enforcement points:\n\n**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.\n\n**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.\n\nThis 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.\n\nCompany 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):\n\n| Budget Tier | Tokens | Content |\n|---|---|---|\n| System prompt | 500 | Agent instructions, tool schemas, output format |\n| Company context | 3,000 | Top 3 wiki pages, summarized if needed |\n| User query | 500 | Task description, clarifying questions |\n| Agent reasoning | 2,000 | Chain-of-thought, tool calls, intermediate results |\n| Reserved buffer | 1,000 | Overflow for long tool outputs or multi-turn conversations |\n\nIf 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.\n\nThe 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.\n\nWhen company policies change, stale context poisons future agent calls. Almanac handles this with event-driven updates:\n\nThere 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.\n\nThe 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.\n\nAlmanac runs as a stateful service with three components:\n\nThe 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.\n\nThe 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.\n\n**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.\n\n**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.\n\n**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.\n\n**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.\n\n``` php\ndef select_context(task: str, user_id: str, max_tokens: int = 3000) -> list[WikiPage]:\n    # Extract entities from task (customer names, project names)\n    entities = extract_entities(task)\n\n    # Keyword search for exact matches\n    keyword_results = db.execute(\n        \"\"\"\n        SELECT id, title, content, ts_rank(search_vector, query) as rank\n        FROM wiki_pages\n        WHERE search_vector @@ plainto_tsquery('english', :entities)\n          AND :user_id = ANY(acl)\n        ORDER BY rank DESC\n        LIMIT 10\n        \"\"\",\n        entities=\" \".join(entities),\n        user_id=user_id\n    )\n\n    # Semantic search for related pages\n    task_embedding = embed(task)\n    semantic_results = db.execute(\n        \"\"\"\n        SELECT id, title, content, 1 - (embedding <=> :task_embedding) as similarity\n        FROM wiki_pages\n        WHERE :user_id = ANY(acl)\n        ORDER BY similarity DESC\n        LIMIT 10\n        \"\"\",\n        task_embedding=task_embedding,\n        user_id=user_id\n    )\n\n    # Merge and deduplicate results (combines keyword + semantic scores)\n    pages = merge_results(keyword_results, semantic_results, top_k=3)\n\n    # Summarize if total tokens exceed budget\n    total_tokens = sum(count_tokens(p.content) for p in pages)\n    if total_tokens > max_tokens:\n        pages = [summarize_page(p, max_tokens // len(pages)) for p in pages]\n\n    return pages\n```\n\nThe 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.\n\n**Core tradeoff**: Almanac chooses context freshness and operational simplicity over scale and sub-second response times.\n\n**Use Almanac's architecture when:**\n\n**Avoid this approach when:**\n\nThe 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.", "url": "https://wpnews.pro/news/almanac-s-company-context-agent-how-yc-s26-wires-internal-knowledge-into-every", "canonical_source": "https://dev.to/mech_app_ai/almanacs-company-context-agent-how-yc-s26-wires-internal-knowledge-into-every-llm-call-45gc", "published_at": "2026-09-02 20:07:20+00:00", "updated_at": "2026-09-02 20:24:10.515402+00:00", "lang": "en", "topics": ["ai-agents", "ai-infrastructure", "developer-tools"], "entities": ["Almanac", "Y Combinator", "Slack", "Gmail", "Granola", "GitHub", "Vercel"], "alternates": {"html": "https://wpnews.pro/news/almanac-s-company-context-agent-how-yc-s26-wires-internal-knowledge-into-every", "markdown": "https://wpnews.pro/news/almanac-s-company-context-agent-how-yc-s26-wires-internal-knowledge-into-every.md", "text": "https://wpnews.pro/news/almanac-s-company-context-agent-how-yc-s26-wires-internal-knowledge-into-every.txt", "jsonld": "https://wpnews.pro/news/almanac-s-company-context-agent-how-yc-s26-wires-internal-knowledge-into-every.jsonld"}}