Agentset: a TypeScript RAG platform where ingestion, retrieval and citations ship together

The gap Agentset fills between a vector store and a shipped product

Most RAG stacks are assembled, not installed. You pick a parser, a chunker, an embedding model, a vector database, a retrieval strategy, and then a separate layer for citations, and you write the glue between all of them. Agentset's README frames the project as the alternative: it describes "end-to-end tooling: ingestion, vector indexing, evaluation/benchmarks, chat playground, hosting, and a developer-friendly API." The intended user is a product team building a document question-answering feature or an internal knowledge assistant who does not want to own that glue. The feature list names "Built-in multi-tenancy," which is a signal about audience: this is not a single-user demo kit. Multi-tenancy in a RAG platform usually means per-tenant document isolation and retrieval scoping, and the README lists it as a first-class feature rather than an extension. If you are building a tool for one team inside one company, that capability is overhead you will pay for in schema complexity. If you are building something where customer A must never retrieve customer B's chunks, it is the reason to look here at all.

What the stack is made of, and what that implies for your infrastructure

The README states the project is "Built with TypeScript, Next.js, AI SDK, Prisma, Supabase, and Trigger.dev." That list is the most useful sentence in the repository for anyone estimating operational cost, because each name is a dependency you inherit. Prisma means a relational schema and migrations, which is why the quick start includes a migration step. Supabase means you are expected to have Postgres plus Supabase's auth and storage surface available. Trigger.dev means long-running ingestion work is dispatched to a background job runner rather than executed inside a request. That last choice is the architecturally interesting one: document ingestion is slow, and pushing it to a queue is the correct design, but it also means a local `bun dev:web` session is not a complete system. The README's own quick start runs only the web app, so ingestion paths that depend on the job runner are not exercised by that command. The README does not document the retrieval pipeline's internals, so how chunking boundaries are chosen, whether hybrid search is supported, and how citations are attached to generated spans cannot be confirmed from this material. Treat those as questions for the docs, not as settled behaviour.

Getting it running locally: the four commands the README gives

The README's local development section is short and specific. First, `cp .env.example .env`, which means the required configuration lives in the example file and you are expected to fill in real values before anything else works. Second, `bun install`, so Bun is the assumed package manager rather than npm, pnpm or yarn. Third, `bun db:deploy` from the repository root, described as running database migrations. Fourth, `bun dev:web` to start the app. Two additional scripts are listed: `bun db:studio` opens Prisma Studio, and `bun dev:web` is repeated as the way to run only the web app. That is the entire documented local path. Note what is absent: there is no documented command for starting the background worker, no seed script, and no health check. The README also points to a self-hosting guide at docs.agentset.ai/open-source/prerequisites rather than restating prerequisites inline, so the environment variables, the Supabase project setup and the Trigger.dev configuration all live outside the repository text. If you are evaluating this for adoption, the prerequisites page is the document that decides whether the install is an afternoon or a sprint.

Where the README stops being useful

The claim "Model agnostic: works with your choice of LLM, embeddings, and vector DB" is the one most likely to disappoint on contact. Agnosticism in practice means an adapter layer, and adapter layers cover a subset of providers well and the rest thinly. The README does not name a single supported LLM, embedding model or vector database, so you cannot check in advance whether your current Postgres plus pgvector setup is covered or whether you would be writing the adapter yourself. The same applies to "22+ file formats" from the repository description: the count is asserted, the list is not given, and format support is exactly the kind of feature where the last ten percent (scanned PDFs, complex tables, nested spreadsheets) determines whether the product works on your corpus. There are no releases retrieved for this repository, which means there is no changelog entry to read for upgrade guidance and no tagged version to pin. That is a real constraint for anyone who needs to argue for a dependency in a review: you would be tracking the main branch. The README does not describe the evaluation and benchmark tooling beyond naming it, so its methodology, datasets and metrics are unknown from this material.

The wrong fit: when a library beats a platform

Agentset is the wrong tool when your retrieval logic is the differentiator. If you are building a domain-specific ranking function, a custom chunker tuned to legal contracts, or a retrieval pipeline where you need to inspect and modify every stage, a platform that owns ingestion through retrieval is a layer between you and the code you care about. The comparison that clarifies this is a library such as LangChain's TypeScript packages or LlamaIndex: those give you composable pieces and leave deployment, tenancy, persistence and the chat interface to you. Agentset inverts the trade. You get the chat playground, the typed SDKs, the OpenAPI spec and the multi-tenancy model already wired, and in exchange you accept Next.js, Prisma, Supabase and Trigger.dev as the shape of your system. Neither approach is better in the abstract. The deciding question is whether the parts Agentset pre-builds are the parts you would have spent months on, or the parts you would have written in a week and then wanted to rewrite. If it is the latter, the platform's opinions become constraints rather than savings.

Maintenance, upgrades and the MIT licence

The repository is MIT licensed, which is permissive: you can use it commercially, modify it, and redistribute it, subject to the usual requirement to preserve the copyright and licence notice. That is the full extent of what can be said here; anything about your specific obligations, including how MIT interacts with the Supabase, Trigger.dev or model provider terms you accept separately, is a question for your own counsel, not for this article. On maintenance, the honest position from the available material is that there is no release history to reason about. The changelog link in the README points to GitHub releases, but no releases were retrieved, so upgrade planning means following commits on main. Combined with a Prisma migration step in the documented setup, that implies schema changes arrive as migrations you apply with `bun db:deploy`, and you should read each migration before running it against a database with real tenant data. The README's contributing section invites issues and pull requests, which suggests an actively maintained project rather than a frozen one, but the README's own "Star Us" section is a reminder that the project is early and asking for attention, not that it has a stable API contract.

How to decide in an afternoon

Run the four documented commands in a scratch environment and see how far you get before the prerequisites page sends you to a third-party signup. If Supabase and Trigger.dev accounts are already part of your stack, the setup cost is low and the bundled citations, playground and multi-tenancy are close to free. If they are not, you are adopting three vendors to evaluate one project, and that should change how you weigh it. Then test the agnosticism claim against your actual corpus: pick one document type you care about, confirm it is among the supported formats, and confirm your intended embedding model and vector database are supported before you plan around them. The repository description mentions an MCP server, which is not covered in the README body, so treat that as a separate investigation rather than a reason to adopt. Finally, decide whether you are comfortable depending on main. With no tagged release retrieved, pinning a commit hash is the only reproducible option, and that is the detail to settle before the first production deployment rather than after.

Editorial conclusion

Adopt Agentset if you want a single TypeScript codebase that already covers ingestion, chunking, embeddings, retrieval and citations, and you are willing to run Postgres, an auth provider and a background job runner to get it. Do not adopt it if you need a narrow embedding library, if you cannot operate Supabase and Trigger.dev alongside the app, or if your retrieval logic is the product and you want to own every line of it. Before committing, verify the prerequisites page at docs.agentset.ai/open-source/prerequisites, confirm which environment variables .env.example actually requires, and check whether the vector database of your choice is among the supported options, because the README claims model and vector DB agnosticism without listing them.

Official sources

1. agentset-ai/agentset on GitHub
2. Issues
3. License: MIT
4. Project website
5. README