CMLewis

I see what you're saying, we may tweak the hero to make it a bit clearer. Thanks for the note!

Thanks for trying it out!

Yeah good catch on the demo. If this were a production deployment, the citations would be hyperlinked to object storage. Captain is just the index, so the real files would be wherever they were indexed from.

You're right that you can chat with files using Gemini or a codegen'd RAG pipeline, and that does work well for a lot of teams.

The problem that Captain really addresses comes when production pipelines need to run continuously over large file corpora with fast, incremental indexing, and reliable latency. The maintenance required in these situations is often quite significant.

Captain focuses specifically on making sure the retrieval layer can operate smoothly so folks don't have to scale & maintain the infrastructure themselves.

OpenSearch provides general search infrastructure and they recently added vector search. It's a low level engine so users would still need to build their own ingestion, parsing, chunking, embeddings, re-ranking, permissions, etc.

Onyx, Sana, and Glean are closer to application-layer enterprise AI products. Their internal knowledge assistants can search across SaaS tools but the interface is more graphical and seats are purchased as end-user software.

Captain sits in between because it's an API-first retrieval system to fully-manage file workloads. This adds search capabilities to existing AI agents but the agents are managed by the developers, outside of Captain.

Kore.ai however is more of an agent platform. Their focus is building and orchestrating agent workflows (which can include document retrieval, but that's not their main focus).

Thanks, just shipped a fix ;)

Yeah QMD is quite impressive! The main difference between us and them is the scale folks would be looking at indexing. The serverless ingestion engine I described in the post is optimized for processing large batch jobs with high concurrency. We depend on a lot of cloud compute for this which isn't something QMD's local-first environment is optimized for. That said, it's a great option for OpenClaw!

No way, that's awesome!

Thanks! The largest alternative to Captain is folks trying to build file search themselves. As mentioned in the post, it is a lot to manage.

The most similar product I've seen is Vertex File Search. They're hosted inside of GCP which can fit nicely into existing cloud deployments. Captain indexes from more sources (like R2 for example) and anecdotally provides faster indexing.

Great question, we have deterministic page # citations for PDF results and exact bounding box citations coming very soon.

If you want to check out the Query API response example, here's a link: https://docs.runcaptain.com/api-reference/query/collection-v...

Thanks, we're just starting to optimize more for the semi-structured data. So far, we've been parsing tables into Markdown and running them through the contextualized embedding model with no overlap, taking advantage of how it strings together chunks. This isn't great for big files so we're exploring agentic exploration (slow but good for more structured numerical data) and automated graph creation (promising for more relational data).

Love the auto-process markdown idea, we'll add it to our roadmap :D