Customer-support assistant
The outcome
A support team ships an assistant that answers questions from their own help docs, knowledge base, and past tickets — not a generic model guessing. Every answer is grounded in your content (retrieval-augmented), so it’s accurate and traceable, and it stays current: when a doc or ticket changes, the index updates and the next answer reflects it.
Point it at customers for self-serve deflection — fewer tickets reach a human — and at agents as a copilot that surfaces the right passage and a drafted reply in seconds, for faster resolution. Same content, same pipeline, two audiences. This is real production software, and you build it by driving the dodil CLI with Claude rather than assembling a stack of vendors.
How it maps to Dodil
The architecture is the standard RAG loop: documents land in object storage, a pipeline chunks and embeds them on upload, questions are embedded and matched against the vector index, and a chat model writes a grounded answer from the retrieved passages. You describe that flow to Claude; it drives the CLI to stand each piece up. Every role maps to one K3 engine or Ignite service:
- Object storage — K3 Objects : drop docs and tickets in a bucket. Every upload is an event the rest of the flow reacts to.
- Auto-embedding pipelines + vector search — K3 pipelines chunk, embed, and index each new file into K3 Vector for you — no ingestion glue to write.
- Embeddings + chat — Ignite Models : OpenAI/Cohere-compatible inference for embedding both your content and incoming questions, and for generating the final answer.
- Serving the endpoint (optional) — Ignite Compute : run the answer endpoint serverless, next to your data, with no servers to manage.
Why it’s faster and cheaper here
Without Dodil you’d assemble and operate: a vector DB vendor, an embeddings/LLM API, ingestion glue that re-chunks and re-embeds on every doc change, object storage, compute to serve it, and auth wired across all of them. Each is a separate account, integration, and bill — and the ingestion glue is code you own forever, since support content changes constantly.
On Dodil that collapses to one platform, one IAM token, pipelines that embed on upload automatically, and serverless compute — all reached from a single typed CLI an agent can drive. The pieces are built to fit, so there’s nothing to integrate between them.
- Faster — ship in days, not weeks. Less code to write (no ingestion or embedding glue), and one auth instead of credentials wired across four to six services.
- Cheaper — fewer vendors and fewer bills, no glue to maintain, no idle compute to pay for, and far less ops surface to monitor and keep in sync.
These wins are structural — they come from removing vendors, glue, and idle capacity, not from a pricing trick.
Build it
- K3 Objects and K3 pipelines — get docs and tickets in, and have them chunked, embedded, and indexed on upload.
- K3 Vector — the search side: match embedded questions against your content.
- Ignite Models — embeddings and the grounded chat answer.
- For a full step-by-step walkthrough of the build, see the blog .
See also
- Use Cases — what teams build on Dodil, and why it ships faster
- CLI · MCP — the typed surface you (and Claude) drive to build this
- Ignite Compute — serverless compute to serve the endpoint
- Get an Access Token — the single IAM token used across all of it