What Loops Are For

A loop takes one bounded job off your hands. You say once what the job is, what the loop may read and call, what it must produce and what a run may cost; then it does that job for each person who comes, or each time something happens. Every job below is one loop. The ones marked (live) run on the plutonium.io home page, so you can try them before you build your own.

Jobs with a person in the conversation

These loops talk to someone — a visitor on your site, a customer in your product, or one of your employees — and end in an answer, a record, or an action a person approved.

• Answer questions from your docs (live). A visitor asks how your product works. The loop searches your docs site and the files you upload, answers in a few sentences, and names the page it used. When your pages do not answer a question, it says so rather than guess. The “Try one first” box on Getting Started is this loop.
• Qualify a lead (live). A prospect says who they are. The loop asks a few questions, one at a time, and files the lead as a record you can read, export or send to your CRM.
• Book a slot (live). A customer asks for a time. The loop offers the slots that are still open, books the one they pick, and does not offer it again; or it books through your own calendar endpoint.
• Sort a support message (live). A customer writes in. The loop answers them like a support chat, with one next question, and behind the reply it keeps one ticket for the conversation, sorted as billing, bug or how-to. Nothing is sent until a person approves it.
• Approve a refund (live). A customer asks for their money back. The loop decides the request and prepares the refund — and does nothing until you press Allow.
• File an expense (live). An employee pastes a receipt. The loop turns it into one expense record and asks only for what the receipt does not show, such as the category.
• Turn meeting notes into actions (live). Someone pastes the notes of a meeting. The loop writes one action item per task, each with an owner and, when the task has one, a due date.
• Help a shopper find a product (live). A shopper says what they need. The loop narrows the product list on your page to match, recommends, and can write a cart or a quote through your own endpoint.
• Intake. Claims, applications, patient intake, support tickets: a conversation that collects the facts and the documents a case needs and ends in one structured record. The loop can check the person’s email address before the record is saved, and hand the case to your team.
• Onboard a new customer. A signed-in customer is walked through setup. The loop reads their state from your product, tells them the next step, and records their progress.
• Help your employees. HR policy, IT help, access and expense requests for an employee signed in with your company account: the loop answers from your policies and files the request through your internal tools.
• Surveys, interviews and training. A loop asks a fixed set of questions, adapts to the answers, and writes one record per person — a research interview, an exit interview, a satisfaction follow-up, or a short assessment with a score.
• Consent and registration. An agreement, an identity check or an event registration, taken as a conversation that ends in a checked record.

When a conversation needs a person, you can take it over and speak to the user yourself.

Jobs with nobody in the conversation

A loop does not need a user. A headless run starts on a schedule, from a webhook, from a new record or from your server, works on that record, and ends in an output. See Triggers and Schedules.

• A weekly digest. Every Monday the loop reads the week’s bookings, reviews and questions and writes the owner a summary.
• Score a new lead. A form submission starts a run that looks the company up through your tool, scores it, writes the lead and notifies your CRM.
• Triage what comes in. Each new ticket, email or form is sorted, routed, and answered with a draft that waits for a person before it is sent.
• Process documents. Each uploaded contract, invoice or application is read and its fields written to a collection; one the loop cannot read is passed to a person.
• Watch a page and judge the change. A page you care about is checked on a schedule, and a run decides whether a change matters before anyone is told.
• Reconcile two systems. Each night a run compares two of your endpoints and writes the differences down.
• Follow up. A conversation that ended without an answer starts a follow-up a day later that reaches the same person.

When the same work repeats

Some jobs are the same steps every time: fetch a page, pull out the fields, compare them with last time, store the result. A model does not need to think about those steps on each run. An agent you give the permission to install automations can propose an automation for such a job: the fixed steps, run on a schedule, with no model in them, so each run costs a small fraction of a loop’s run. You read and approve it before it runs, and it can start a loop when what it finds needs judgement. The work you repeat most becomes the cheapest to run.

Every loop, whatever its job

• It has a budget. Each call a run makes is reserved against your wallet first, and you cap what one run, one user and the loop’s month may spend.
• It acts only as approved. A loop holds the tools its published version names and nothing more, and a tool that asks first waits for a person before each call. See Permissions and Trust.
• It is recorded. Every run is kept turn by turn, and you can watch one live or stop it.

Start one

Describe the job to LoopAssistant in the console’s Chat, in your own words. It asks what it needs to know and proposes the loop for you to read and edit before anything runs. See Getting Started, and Core Concepts for the parts a loop is built from.