> ## Documentation Index
> Fetch the complete documentation index at: https://docs.rippit.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Agent Apps

> Put a recurring analysis on a schedule so it runs, formats itself, and delivers without anyone remembering to ask.

An Agent App is an analysis that runs on its own. You describe it once in plain language, Rippit builds it as a flow you can inspect, and after you test and activate it, it runs on a schedule and delivers the result to Slack or email.

Open **Agent Apps** in the left sidebar to see what you have and to create one. Or describe what you want to build in any chat, and Rippit builds it in that conversation, where you can also test it, change it, and put it live.

## How to describe what you want

Think of it as briefing someone on a standing job rather than asking a question. A chat answer is for right now; an Agent App is the version that still happens every Friday when nobody remembers to ask.

The one habit worth forming: describe the whole job in your first sentence, not just the interesting part. Most people write the analysis ("summarize billing complaints") and stop, because that is the part they care about. But Rippit builds the entire flow from that sentence, so everything you leave out is something it has to guess or stop and ask you about.

A good description names four things:

* **When it runs.** "Every Monday morning" or "every day at 9am."
* **Which data it reads.** The source, and how far back each run should look.
* **What judgment you want.** Not a filter over metadata, but the reading you would ask a person for: what the theme is, why it happened, whether it is getting worse.
* **Where the result goes.** A Slack channel, a person, or an email list.

A few things that help:

* **Say what "done" looks like.** "A short digest with links" and "a full breakdown by theme" produce very different apps.
* **Say what should happen when nothing matches.** Otherwise you get silence on a quiet week and cannot tell it apart from a broken app.
* **Expect questions.** Building happens in a conversation, so the app may pause and wait on your answer in chat before the flow fills in.
* **Prove it in chat first.** If you are unsure the analysis works at all, ask it as a normal question, then turn the version you liked into an app.

## What to use it for

Anything you would want to know on a schedule, across support, revenue, and product. Rippit ships a handful of ready-made examples, and editing one of those is usually faster than starting from an empty box. Everything below works either way, as a starting example or as a prompt you write yourself.

**Understand what support is dealing with**

* "Every Friday, post one Slack report summarizing the biggest themes from the past week's support conversations."
* "Every morning, post an urgency summary to Slack, including a brief update when nothing urgent is found."
* "Every Monday, email me a summary of coaching opportunities from last week's support conversations."

**Watch revenue and churn risk**

These depend on what your workspace brings in. Sales call transcripts and a connected CRM open up the accounts and calls angle; with support conversations alone, stick to the sentiment and complaint versions.

* "Every Monday, email me the accounts renewing in the next 60 days that raised a complaint we never resolved."
* "Every day, post a negative-sentiment summary with conversation links to Slack, including when none are found."
* "Every week, summarize the objections that came up in calls that did not close, and post it to the sales channel."

**Track what the product gets wrong**

* "Every day, post a summary of suspected product bugs with conversation links to Slack for triage."
* "Every Friday, summarize feature requests and product friction from customer conversations and post a digest to Slack."
* "Every Monday, tell me whether complaints about checkout went up or down against the four weeks before."

Two of the support and revenue examples above say what to do when nothing matches, which is the difference between a quiet week and an app that silently stopped working.

## What Rippit builds

Every app has the same shape, and you can open any part of it to adjust it:

* **Scope** decides which records the app sees: a date field, how many days to include, and whether to split the data so you get one output per group instead of one for the whole period.
* **Analysis** investigates the scoped records and produces the raw findings.
* **Formatting** turns those findings into the actual message, email, or note you want published.
* **Delivery** sends it. Slack and email are built in, and you can post to a channel or send to one person.
* **Schedule** controls when a new run starts: hourly, daily, or weekly. There is a plain-language box for this too, so "every Monday at 9am" works.

You can edit any of these by hand, but the faster way is usually to say what you want changed in the app's chat: "look back 30 days instead of 7," or "send this to the support channel too." Rippit makes the change to the right part of the flow, and the more involved parts of scope are designed to be edited this way rather than in the panel.

## Test before you activate

<Warning>
  A test is a real run on sample rows. Any step that emails or posts will actually email or post, so people receive it. Point early tests at yourself or a scratch channel.
</Warning>

Testing is the step worth your patience, because a schedule turns a small configuration mistake into a recurring one. You can run a single sample, run the whole thing, or run a capped number of samples when the full set would be slow or expensive.

You can also test one step at a time, which is usually the faster way to fix something: run just Analysis, check the findings look right, then run Formatting on that output. Later steps need the earlier ones to have run first.

When a test fails, **Fix it with Rippit** hands the failure back to chat so you can work through it there.

## Going live

**Save & activate** puts the app on its schedule, or you can just tell the chat to activate it. Rippit recommends testing first but does not require it, so an untested app will activate if you confirm you want it to. Deactivating and deleting work from chat the same way.

A few things change once an app is live:

* Edits you save apply on the next scheduled run, not the current one.
* Output lands in a real table after the first live run. Tests write to a temporary worksheet instead, so an app that has never run live has nothing in its output yet.
* **Deactivate** pauses future runs and keeps everything: configuration, output, and both test and run history. You can activate it again.
* **Delete** requires deactivating first. It removes the app from the list but keeps the output table and history.

The list can be filtered by state, including **Draft**, **Live**, **Inactive**, and **Errored**, so a job that started failing is visible without opening it.

<Note>
  Anyone in your workspace can create and run Agent Apps. Connections are shared, though: a server connected as "only me" is invisible to Agent Apps, so it has to be connected with the organization-wide scope. See [Connect a server](/agentic-chat/connect-a-server).
</Note>