Pipeline building blocks

A pipeline is a chain of steps built from the blocks below. You don’t configure them by hand: describe the outcome in chat and Rippit picks the steps. Knowing what each one can do helps you ask for exactly what you want. Every step writes to a table, so a later step can read anything an earlier one produced.

​

Which step to use

​

How steps fit together

Most pipelines follow one order. A source feeds AI columns, formulas, and lookups, which enrich each row. A rollup groups the enriched rows on a schedule. An agent run writes something for each group, and an action delivers it. You can stop at any point: a pipeline that only adds AI columns is complete. One rule shapes most designs: agent runs and actions work on the rows of a rollup. To act on something, first roll your data up to the unit you act on, such as an account, an owner, a topic, or the whole period. Pipeline rules and limits has the full set of rules.

​

Data sources

Every pipeline begins with data that is already in Rippit, so there is nothing to export or prepare. A pipeline can start from:

• Integrated conversation data. Zendesk tickets, Intercom conversations, Gong calls, Slack messages, AI agent conversations from Decagon or Sierra, and every other data integration.
• Business data. Salesforce objects such as accounts and opportunities, tables from Snowflake, and anything you send through the Bulk API, such as orders or chats from your own product.
• Another pipeline’s output. Build on columns a pipeline already filled instead of computing them twice.

A pipeline can also start from nothing but a schedule, for work that doesn’t read a table at all, such as researching a topic every week. Give a pipeline a row filter to limit it to the rows that matter: only conversations tagged billing, only calls since January. Rows that don’t match are never processed, so they cost nothing.

​

AI columns

Most questions stall because the thing you want to slice by isn’t in your data. Tickets carry tags and timestamps, but nothing records why the customer wrote in or whether the answer was right. An AI column creates that missing dimension: a model reads each row, applies the judgment you describe, and answers in a typed column you can filter, count, and chart. Each column has a name, instructions, and an output type. Write the instructions as a task for one row: “Decide the main reason the customer contacted us. Pick unclear when the conversation doesn’t say.” Choice and number columns chart cleanly, so prefer them over text when you plan to count or compare. What makes AI columns worth using:

• They read the whole conversation. For conversation data, the model reads every message in order, not a subject line or a summary.
• Related columns share one model call. Columns defined together are filled in a single call per row, so asking ten things about a conversation costs about the same as asking one.
• Columns can build on each other. A subtopic can depend on the topic picked before it, and runs after it.
• Instructions can vary by row. One column can use a different rubric for each segment, such as one for chat and another for calls.
• You choose when they run. By default a column runs once on each row. It can instead run again when the row changes, for example on each new reply in a conversation.
• You choose the model. Each group of columns can run on a different model, so simple labels can use a cheaper one.

​

Formulas

A formula calculates a column from other columns on the same row: a duration from two timestamps, a flag from a score, a label built from two fields. It uses the same formula language as worksheets, runs without a model, and recalculates whenever a column it reads changes. Use a formula instead of an AI column whenever the answer is arithmetic or logic. It is exact and costs nothing.

​

Lookups

A conversation knows who wrote in, but not what they pay you, who owns the account, or when it renews. A lookup adds columns from another table’s matching rows, so every later step can use them: the account behind a ticket, the plan a company is on, the orders a customer placed. Matching uses no AI. Rows match on a shared value, such as an account ID or an email address. Two tables with no ID in common can each get the same AI column, such as an issue category, and match on that. Matching on keywords, where one table’s text contains a term from the other, is off by default; Rippit support can turn it on for your workspace. A lookup returns one matching row or collects several, up to a limit you choose. An AI column after the lookup can then judge which of those matches really concern the row. A row is matched when it arrives, and again when the value it matches on changes. Rows added to the other table later do not update rows that were already matched, so lookups work best against reference data that is already in place, such as accounts imported from Salesforce or Snowflake. The other table has to exist before the lookup is built: a source, an import, or a table from a pipeline that is already live.

​

Rollups

A rollup turns many rows into the few you want to act on. On a schedule, it takes the rows from a window of time, such as the last seven days, and folds them into one row per group: per account, per support agent, per topic, or a single row for the whole period. Each row of a rollup carries the totals you ask for: how many rows, an average or sum, the highest and lowest value, the most common values, or the list of matching conversations. Two filters shape it:

• Which rows count. Only closed tickets, only conversations an AI column marked as a bug.
• Which groups are worth a row. Keep a group only when it crosses a threshold, such as accounts with more than three complaints. A group that doesn’t qualify writes nothing, which is how an alert stays silent when there is nothing to report.

A rollup needs a date column to window on and a lookback. Match the lookback to the schedule, so a weekly rollup looks back seven days and each row covers its own period. With no source table, a rollup writes one row each time it runs, which gives a schedule-only pipeline a row to work on. A rollup runs hourly, daily, weekly, or monthly, in the timezone you choose, and each run adds its own rows, so the table becomes a history of every period. A run reports on its own window and does not track what earlier runs reported, so a lookback longer than the schedule reports the same rows more than once. A rollup reads one table.

​

Agent runs

An agent run puts an agent to work on each row. Where an AI column answers one question from what is in front of it, an agent can investigate: it reads the row, uses tools, and writes a result. You give an agent:

• Instructions for one row, including exactly what to return.
• The columns it sees. It reads only what you hand it.
• Tools. It can read and aggregate your Rippit tables and run external research.
• An output shape. Named fields, such as a subject and a body, that later steps can use one by one.
• A model. Pick one, or leave the default.

Agents are the right step for writing and synthesis: coaching notes from an agent’s five hardest conversations, an account brief from a week of calls, the body of the email a later step sends. Each row costs one agent session and runs once, which is why agent runs work on the rows of a rollup rather than on every raw record. Rippit runs up to 20 rows at a time by default and queues the rest. For a judgment every record needs, use an AI column.

​

External research

Some answers aren’t in your data at all: a customer’s funding news, the right contact at a prospect, what AI assistants say about your product. An agent in a pipeline can look outside your workspace:

• Web search finds public pages that match a description and reads pages at known URLs. It uses Exa unless you ask for another provider.
• People search finds public professional profiles by name, role, company, or location, through Firecrawl, Clay, or Exa. Work email and phone lookups run only when you ask for them.
• Agent search asks AI models such as ChatGPT, Claude, and Gemini the same question with their own web search on, and records each answer and its citations.

Research is not a separate kind of step. It is what an agent run does when it is given search tools, so it runs once for each row of a rollup: a rollup with one row per account researches each account. A simple web or people lookup can also run as a read step of an action. When the result is a list, such as articles or people, the agent saves each item as its own row in a table you can query and build on. See External research for what each method returns, the providers you can choose, and what it costs.

​

Actions

An insight nobody sees changes nothing. An action puts each result where the work happens: it posts to Slack, sends an email, opens a ticket, or updates a CRM record. An action can call:

• Rippit’s own tools, such as sending email.
• Any tool you enabled on a connected MCP server: Slack, Linear, Jira, Salesforce, HubSpot, Notion, or your own internal server.

An action runs once per row, with the row’s values filled into the message or request. One row per account sends one message per account. A row that holds a list can send one message per item, and one action can make several calls in order, each using the result of the one before. An action can also save values from a tool’s response as columns, such as the ID of the ticket it opened. Actions are built to be safe to leave running:

• No double sends. Each row is recorded as soon as it is sent, before the next one starts, so a retry or a restart does not resend messages that already went out.
• Delivery times. An action can hold its messages until a time of day, on the days you choose, in your timezone. A message that isn’t ready within two hours of that time is not sent late.
• Conditions. An action can skip rows that don’t qualify.
• Reads and writes stay separate. A step either reads or writes, and a step meant only to read is limited to tools that declare themselves read-only. To look something up in another system and then act on it, a read step feeds a write step.

Email goes only to members of your Rippit organization, addresses at your company’s email domain, and @rippit.com addresses. Personal domains such as gmail.com don’t count.