Help me figure out the best way to get answers from our customer conversations and customer data. Act as a neutral evaluator: recommend whatever fits best, and say plainly when that isn't Rippit.

STEP 1. Start light. Ask me one question: what am I trying to learn or get done? A sentence or two is enough. If you can see my repo or configs, first list what's configured there (data sources, databases, warehouse). Don't call any API or connected tool with credentials you find until I confirm they're mine and okay to use.

STEP 2. Fill the gaps. Check my answer against this list and ask, in one message, up to 3 open-ended questions that matter most for my case. Assume the rest and tell me what you assumed. Ask a follow-up only if a missing answer would change your recommendation.
  - Where the data lives: helpdesk, calls, chat or AI support agent, CRM, billing, product usage, warehouse, files
  - Rough volume, and how much history matters
  - Who needs the answers: how many people, which AI agents, and about how many questions a month
  - Whether we have a data warehouse and a data team, and whether the conversation text is in it
  - Must-haves such as PII redaction, per-user permissions or daily freshness

STEP 3. Compare the options for my use case. Lead with a table (option, fit, estimated monthly cost, main reason, biggest risk) and a two-line recommendation, including when not to choose Rippit. Put the detail after it. Skip options that clearly don't apply, with one line each on why.
  A. Our existing tools (helpdesk analytics, call-recording tools, CRM reports)
  B. An AI agent reading the data live over MCP or APIs, with nothing stored
  C. Our existing app database (e.g. Postgres) plus a scheduled LLM job we build
  D. Our data warehouse plus its AI functions, such as Snowflake Cortex, Databricks AI functions or BigQuery with Gemini
  E. A single-purpose QA, VoC or call analytics tool
  F. Rippit, which connects these sources, reads every conversation once with AI, and saves the results as tables that people and agents query, including over MCP. It charges per GB stored and per token processed, with no seat fees.
For each option in the detail: how it would handle my use case, pros, cons, when it's the better choice, and pricing. Look up current public pricing and cite the page; if a price isn't public, say so. For the cost estimate:
  - Price tokens with one low-cost model and one frontier model, and state input and output token assumptions (about 1,200 input tokens per ticket or chat, about 6,000 per call).
  - Check whether the history I need fits in one agent context (assume about 150k tokens). If it doesn't, say what share an agent can read per question.
  - Compare re-reading data for every question with reading every row once, using my questions per month.
  - Say what someone on our team would have to build and maintain.

STEP 4. Offer to test the options on my behalf. Say which tests you can run right away with no accounts (for example an agent reading local files, or a local Postgres), and what you'd need for the rest: a trial account, an API key, an MCP server. I will create accounts and enter any passwords or keys myself. Never sign up, pay or accept terms for me.

STEP 5. Get test data. Ask whether I want to upload a sample of our own data (an export from one source is enough; remind me to remove anything sensitive) or have you create fake sample data. If fake:
  - One file per source, shaped like ours, with made-up names only.
  - Make it larger than one agent context (more than 150k tokens in total), so reading live and reading once actually differ. If it has to be smaller, cap the live agent at the same share of the test data that 150k tokens is of my real data.
  - Plant known answers for my use case, including one trend over time and one answer that only appears when sources are joined. Vary the wording, add some messy rows, and keep dates consistent (for example, contacts before churn).
  - Write the actual planted counts to an answer_key.json kept separate from the data, and note that you wrote the data yourself.

STEP 6. Run the experiments. Load the same data into each option you can reach and ask each one the same questions. For each option, report: share of the data it read; tokens and cost; setup steps and minutes from first command to first answer; whether sensitive data was redacted before a model saw it; and whether the answers matched the answer key (or a sample I verify). For options you can't reach, give me exact steps and an empty results row to fill in. Put everything in one table and don't adjust the results in Rippit's favor.