Paid service · enquiry first · async
Pick the right agent stack before you burn weeks on the wrong one.
A paid, async, vendor-neutral architecture review. Submit your use case, constraints, and current shortlist. If we agree on the scope and terms, you receive a written recommendation grounded in the independent catalogue behind this site. No calls.
Why this exists
Choosing a stack depends on your task, data, budget and team. A framework's documentation explains that tool; it doesn't decide whether the tool fits your constraints. The review starts with your brief and one question:
“Given my use case, data, budget, team, and constraints — what should I build with?”
What you get
Recommended architecture pattern
The shape of the system for your use case — and why that shape, not a trendier one.
Component-by-component stack
Relevant layers (ingestion, retrieval, orchestration, eval, hosting…) with candidate tools, trade-offs, and clear “skip if” notes.
Implementation checklist
The concrete steps to get from prototype to a first usable version — in order.
Watch-outs
The specific failure modes for your case: retrieval quality, cost traps, eval gaps, lock-in.
One async revision
One correction if I misunderstood a stated constraint. The report format and revision terms are confirmed with the scope.
How it works
- 1
Submit your use case
Fill the form below — task, users, data, constraints, budget, and anything you’ve ruled out.
- 2
Scope confirmation by email
I review the request and confirm whether it’s a fit. If it needs a different scope or implementation help, I’ll say so before you decide whether to pay.
- 3
Agree on terms
Before payment, confirm the deliverables, fee, delivery date, report format, revision and cancellation/refund terms by email. The form does not take payment or reserve a delivery date.
- 4
Receive your written review
If we agree to proceed, the review is prepared for the confirmed brief and delivered by email on the agreed schedule.
Why independent matters
Agent Search Engine is a sponsor-blind directory of AI agents, MCP servers, frameworks, and agent infrastructure. Rankings are never sold. If the right answer is self-hosting, I'll say that. If it's a commercial platform, I'll say that. If the right answer is “don't use agents here,” I'll say that too. The point isn't to validate a favorite vendor — it's to help you avoid an expensive wrong turn.
It's written by the person who builds and maintains that index. The catalogue is a starting point for checking relevant tools against your brief; inclusion alone is not a product test or a recommendation.
Illustrative example
The shape of a written review
Example use case: a RAG knowledge assistant for a small B2B SaaS support team — answering internal questions from help docs, product docs, and selected past tickets, with citations; starting narrow, avoiding enterprise spend, maintainable by a small team. This is an invented brief to show the format, not a completed client review or a tested deployment.
Recommended pattern
Start with a boring, inspectable RAG pipeline before any autonomous behavior: ingest from stable sources → normalize to clean markdown → chunk with metadata → embed → retrieve with filters → (optionally) rerank → answer with citations, logging every question, retrieved chunk, and answer. A 30–50 question eval set from real tickets exposes bad chunking and hallucinations before launch. Don't start with a multi-agent system — the first version is a grounded answer engine with escalation, not a “support agent” that invents policy.
The stack, layer by layer
| Layer | Good options | Why | Skip / avoid if |
|---|---|---|---|
| Ingestion + cleaning | Direct export · Firecrawl · Scrapling | Prefer a direct CMS / help-desk / repo export; Firecrawl to turn web docs into clean markdown; Scrapling only as a fallback for brittle pages (mind each site's terms). | Scraping as your primary source when a clean export exists — raw HTML noise quietly wrecks retrieval. |
| Chunking + pipeline | Haystack · RAGFlow · Dify | Code-first control (Haystack) vs. a packaged RAG platform (RAGFlow / Dify). | Don’t trust default chunk settings until you’ve tested them on your actual docs. |
| Vector store | Platform-native (Dify / RAGFlow) · pgvector / Qdrant | Use the platform’s native knowledge base first; a separate store buys control. | Don’t stand up a separate vector DB on day one without a real scale or multi-tenancy reason. |
| Retrieval + rerank | Haystack · RAGFlow | Hybrid retrieval + metadata filters + reranking — where quality is won. | Avoid “top-k vector search only” on messy support docs — it retrieves similar-but-wrong chunks. |
| Orchestration | LangGraph · Pydantic AI · LangChain | Explicit states (retrieve → answer → escalate); typed boundaries; broad integrations. | Skip multi-agent (CrewAI / AutoGen) for v1 — it adds moving parts before retrieval is proven. |
| Memory | Simple chat history · mem0 | For support-doc Q&A, short-term chat history is usually enough; reach for mem0 only if you truly need user-specific memory across sessions. | Don’t add long-term memory before you know what should persist — bad memory is another wrong-answer source. |
| Eval + observability | Langfuse · Phoenix · Ragas · DeepEval | Log query, retrieved chunks, answer, citations, latency, cost — then run a fixed eval set. | Don’t launch on vibes. RAG regressions are subtle: a prettier answer can be less grounded. |
| Hosting | Self-hosted Dify / RAGFlow + a small DB | For low-spend, self-host one platform plus a small database; keep re-index scripts boring. | Avoid Kubernetes unless you already operate it — the ops load will outweigh the value for v1. |
What to watch out for
- Retrieval quality dominates model quality — the wrong chunk just makes a better model write a more convincing wrong answer. Build a 30–50 question eval set first.
- Chunking needs product context — generic splitting separates a pricing rule from its exception. Preserve headings, product area, version, date, and source URL as metadata.
- Stale docs are worse than no docs — old policies that stay searchable fail loudly. Add freshness metadata and re-index on a schedule.
- Cost blowups come from invisible loops — reranking, long context, and multi-step flows multiply spend. Cap retrieved chunks, answer length, retries, and tool calls before users touch it.
Questions
How fast do I get it?
The delivery date is confirmed by email after the scope is reviewed, before you decide whether to pay. Submitting the form does not book a review.
Do you do calls?
No — async only. Form, email, written report. That keeps the price sane and the recommendation focused.
Is it truly vendor-neutral?
Yes. Agent Search Engine is sponsor-blind: rankings are never sold and paid placements never influence recommendations. No vendor kickbacks steer the answer.
What if I disagree with it?
That’s fine — the review explains the reasoning and trade-offs so you can weigh it yourself. You also get one async revision if I misunderstood a stated constraint.
Do you implement the stack for me?
No. This is architecture and tool selection, not build work. You get a practical implementation checklist; you or your team build it.
What do you need from me?
Your use case, target users, data sources, privacy constraints, budget, preferred language/frameworks, hosting constraints, current shortlist, and anything you’ve already ruled out.
Is my information kept private?
Yes. Your intake and review are never published, reused as a case study, or shared with vendors. Please don’t submit secrets, API keys, or regulated data.
Request your Stack Review
Tell me what you're building. This sends an enquiry; it does not take payment or book a review. Scope, delivery and payment terms are confirmed by email before any payment. Prefer email? hello@agentsearchengine.app