Why Twig Ships Three Strategies ?

Redwood, Cedar, and Cypress — and how to pick between them

Why we built three strategies instead of one

Most RAG systems are built as if there's a single correct pipeline. Embed the query, hit the vector store, stuff the top-k into the context window, generate. That works right up until it doesn't — and the point where it stops working is different for every deployment.

We kept running into the same three failure shapes across customer deployments:

1. The over-engineered FAQ bot. A knowledge base of 200 well-written help articles, users asking clear, self-contained questions like "what are your business hours." Running query expansion, dual-tier retrieval, and a cross-encoder rerank on that is burning latency and tokens to arrive at the same chunk direct vector search would have returned in 900ms. You've made the product feel slower and cost more for zero accuracy gain.

2. The naive pipeline that can't handle turn two. User asks "do you support SSO?" Agent answers. User asks "how do I set it up?" Embed that second query on its own and you get a vector that means nothing — "how do I set it up" is semantically adjacent to every setup doc in the corpus. Retrieval quality collapses on exactly the queries where users have the most intent. Standard RAG has no mechanism to fix this because the failure happens before retrieval, in the query itself.

3. The vocabulary mismatch. The knowledge base says "credential recovery workflow." The user types "forgot my login." Cosine similarity in embedding space is better at this than keyword search, but it is not magic — and when your corpus spans multiple domains with distinct terminology, single-shot dense retrieval quietly returns plausible-but-wrong chunks. The model then generates a confident answer grounded in the wrong document, which is the worst failure mode in the entire system.

You cannot solve all three with one pipeline, because the fixes trade against each other. Fixing (2) and (3) costs you extra LLM round trips and reranking latency — which is precisely the tax you don't want to pay in case (1).

So we stopped trying. Twig ships three named strategies, selectable per agent, switchable at runtime.

The three strategies

Redwood — Standard RAG

The baseline, and deliberately so. The user's original query goes straight to embedding with no rewriting.

query → embed → vector search (top-k) → build context → LLM → response

One LLM call. Minimal token overhead. ~1–2 seconds end to end.

Redwood is the right default when your queries are well-formed and self-contained — API reference lookups, product info, FAQ surfaces, anything high-volume and cost-sensitive. It is the wrong choice the moment queries start referencing prior turns or arriving ambiguous.

Cedar — Context-Aware RAG

Cedar inserts a rewriting step between the user and the vector store. Before retrieval, it reads conversation memory and rewrites the query into something explicit and searchable.

query → analyze memory → rewrite query → embed → vector search
      → build context → LLM → response

"How do I set it up?" becomes something closer to "how do I configure SAML SSO for my account" — a vector that actually lands where it should. That single transformation is what makes multi-turn support agents work.

Cost: one additional LLM call, ~2–3 seconds total. For most conversational deployments this is the right trade, and Cedar is where we point the majority of customer support and internal-wiki agents.

Cypress — Advanced RAG with Reranking

Cypress is the accuracy-maximizing path. Ten steps, three distinct mechanisms layered on top of Cedar's rewriting.

query → memory enhancement → query expansion
      → Tier 1 retrieval (topK=50)
      → Tier 2 retrieval (topK=50)
      → cross-encoder rerank (bge-reranker-v2-m3) → top 10
      → context assembly → final context-aware rewrite → LLM → response

Three things are worth calling out for engineers:

Query expansion. The rewritten prompt is expanded with synonyms, related terms, and alternative phrasings before it hits the index. Concretely:

Original: "reset password"
Expanded: "reset password, change password, recover account,
           password reset process, account recovery, reset credentials"

This is the direct fix for vocabulary mismatch. You are widening the region of embedding space you sample from, which raises recall at the cost of precision — which is fine, because the next stage exists to buy the precision back.

Tier-based retrieval. Sources are split into Tier 1 (official documentation, primary knowledge bases) and Tier 2 (community content, secondary sources), each retrieved at topK=50. Both tiers are then treated equally in reranking, so tier membership shapes what gets pulled without hard-coding a trust hierarchy into the final ranking.

Cross-encoder reranking. The 100 candidates are reranked with bge-reranker-v2-m3 and cut to the top 10. This is the part that matters most. A bi-encoder embedding comparison scores query and document independently; a cross-encoder scores the pair jointly, so it can model the actual relationship between the question and the passage rather than their independent positions in vector space. It's more expensive per candidate, which is exactly why it runs on 100 pre-filtered chunks rather than the whole corpus. Retrieve wide, rank narrow.

Cost: multiple LLM calls plus a rerank pass, ~3–4 seconds. Use it when a wrong answer is expensive — medical and legal Q&A, compliance, multi-domain enterprise knowledge bases.

Comparison

Feature matrix

Note the bottom half of that table: everything Cypress adds is a retrieval-side mechanism. Chunking, memory, and privacy controls are platform-level and identical across all three. The strategy choice is strictly about how hard you work to find the right chunks — not about what the rest of the stack can do.

Picking one

Is speed the top priority?
├─ Yes → Redwood
└─ No
    └─ Are questions conversational/ambiguous?
        ├─ Sometimes → Cedar
        └─ Often
            └─ Is highest accuracy critical?
                ├─ Yes → Cypress
                └─ No → Cedar

Mapped to real deployments:

Our honest default: start on Cedar. Most real agents get conversational faster than teams expect, and Cedar's rewriting step is the single highest-leverage addition to a baseline pipeline. Drop to Redwood if your traffic turns out to be genuinely stateless and you want the latency back. Move to Cypress when you can point to specific queries that are failing on terminology or ambiguity.

Don't guess — A/B it

Strategy is a per-agent setting, changeable in agent settings under RAG Strategy, effective immediately. That makes empirical comparison cheap:

1. Duplicate your agent.

2. Assign a different strategy to each copy.

3. Run the same test set against both.

4. Compare responses, latency, and citations.

5. Pull quality metrics from analytics.

Because the copies share chunking, embeddings, and knowledge base, the retrieval strategy is the only variable. That's a clean experiment, and it's a better basis for the decision than any table we can write for you — including the ones above.

One caution: changes go live immediately. Test in the Playground before you flip production.

Read the deep dives: RAG Strategies overview · Redwood · Cedar · Cypress