Top stories

Hi HN, I am Arlan and I am building Nia (https://trynia.ai), a context layer for AI coding agents. Nia lets tools like Cursor, Claude Code, and other MCP clients index and query real codebases and documentation so they stop hallucinating against outdated or wrong sources, with applications beyond coding agents to any AI system that requires grounded context across domains.

Coding agents are only as good as the context you give them. General models are trained on public code and documentation that is often old, and they usually have no idea what is inside your actual repo, internal wiki, or the exact version of a third party SDK you use. The result is very familiar: you paste URLs and code snippets into the prompt, the agent confidently uses an outdated API or the wrong framework version, and you spend more time verifying and correcting it than if you had written the code yourself. Once models are good enough at generating code, feeding them precise, up-to-date context becomes the bottleneck.

I ran into this pattern first on my own projects when (a few months ago) I was still in high school in Kazakhstan, obsessed with codegen tools and trying every coding agent I could find. I saw it again when I got into YC and talked to other teams who were also trying to use agents on real work.

The first version of Nia was basically “my personal MCP server that knows my repos and favorite doc sites so I do not have to paste URLs into Cursor anymore.” Once I saw how much smoother my own workflow became, it felt obvious that this should be a product other people could use too.

Under the hood, Nia is an indexing and retrieval service with an MCP interface and an API. You point it at sources like GitHub repositories, framework or provider docs, SDK pages, PDF manuals, etc. We fetch and parse those with some simple heuristics for code structures, headings, and tables, then normalize them into chunks and build several indexes: a semantic index with embeddings for natural language queries; a symbol and usage index for functions, classes, types, and endpoints; a basic reference graph between files, symbols, and external docs; regex and file tree search for cases where you want deterministic matches over raw text.

When an agent calls Nia, it sends a natural language query plus optional hints like the current file path, stack trace, or repository. Nia runs a mix of BM25 style search, embedding similarity, and graph walks to rank relevant snippets, and can also return precise locations like “this function definition in this file and the three places it is used” instead of just a fuzzy paragraph. The calling agent then decides how to use those snippets in its own prompt. One Nia deployment can serve multiple agents and multiple projects at once. For example, you can have Cursor, Claude Code, and a browser based agent all pointed at the same Nia instance that knows about your monorepo, your internal wiki, and the provider docs you care about. We keep an agent agnostic session record that tracks which sources were used and which snippets the user accepted. Any MCP client can attach to that session id, fetch the current context, and extend it, so switching tools does not mean losing what has already been discovered.

A lot of work goes into keeping indexes fresh without reprocessing everything. Background workers periodically refetch configured sources, detect which files or pages changed, and reindex those incrementally. This matters because many of the worst “hallucinations” I have seen are actually the model quoting valid documentation for the wrong version. Fixing that is more about version and change tracking than about model quality.

We ship Nia with a growing set of pre-indexed public sources. Today this includes around 6k packages from common frameworks and provider docs, plus package search over thousands of libraries from ecosystems like PyPI, npm, and RubyGems, as well as pre indexed /explore page where everyone can contribute their sources! The idea is that a new user can install Nia, connect nothing, and still get useful answers for common libraries. Then, as soon as you add your own repos and internal docs, those private sources are merged into the same index. Some examples of how people use Nia so far: - migrating from one payments provider or API version to another by indexing the provider docs plus example repos and letting the agent propose and iterate on patches; - answering “how do I do X in this framework” by indexing the framework source directly instead of relying only on official docs that might be stale; - turning an unfamiliar public codebase into a temporary wiki to self onboard, where you can ask structural questions and jump to specific files, functions, or commits; - building a browser agent that answers questions using up to date code and docs even when the public documentation lags behind.

Nia is a paid product (https://www.trynia.ai/) but we have a free tier that should be enough for individuals to try it on real projects. Above that there is a self-serve paid plan for heavier individual use, and organization plans with higher limits, SOC 2, seat based billing, and options for teams that want to keep indexing inside their own environment. For private GitHub repos we can clone and index locally so code does not leave your infrastructure.

We store account details and basic telemetry like query counts and errors to operate the service, and we store processed representations of content you explicitly connect (chunks, metadata, embeddings, and small graphs) so we can answer queries. We do not train foundation models on customer content and we do not sell user data. Moreover, I can see Nia play out in the larger context of the agents space due to the global problem of providing reliable context to those systems. Early signals show that people are already using Nia for healthcare data, cloning Paul Graham by indexing all of his essays and turning him into an AI agent, using Naval’s archive to build a personalized agent, and more.

I would love to get Nia into the hands of more engineers who are already pushing coding agents hard and see where it breaks. I am especially interested in hearing about failure modes, annoying onboarding steps, places where the retrieval logic is obviously wrong or incomplete, or any security concerns I should address. I will be in the thread to answer questions, share more technical details, and collect any brutal feedback you are willing to give!

Legion Health (YC S21) operates a psychiatric practice and is building the AI-native operations layer for mental health care. We focus on the operational backend: scheduling, intake, documentation, billing, and care coordination. These workflows—not diagnostics—are the main bottlenecks in mental health delivery.

We run our own clinic, so the systems you build ship directly into real patient care. Our agent infrastructure currently supports more than 2,000 patients with one human support lead.

We’re hiring a Founding Engineer (in-person, San Francisco). You’d work directly with the founders on:

event-driven backend systems (Node.js, TypeScript, Postgres/Supabase, AWS)

LLM agent tooling (tool use, retries, memory, context management)

internal operations tools for both humans and agents

state/coordination logic that represents a patient’s journey

HIPAA-compliant data and audit pipelines

We’re open to backend or full-stack/product engineers who think in systems and have owned real workflows end-to-end. Prior experience with LLMs is optional; interest is required.

Details: full-time, in-person SF, salary $130k–$180k, equity 0.1–0.6%.

Apply here: https://www.ycombinator.com/companies/legion-health/jobs/oc6...