Operating Loops
After a loop is published, the Operate group of the console is where you watch it: All runs for each run as it happens, and Metrics for the same runs counted per loop.
All runs
All runs shows every run in the account as it happens, including the conversations each member started from My conversations: who it is for, how it reached the loop, what it has spent, and why it ended. Choose a run to read what it did: the conversation, each tool call, and what it wrote. Each answer is headed by the loop’s name, and a run outside a loop by its agent’s name, such as Researcher. A run you started yourself opens in My conversations, where you can carry it on.
The Started by chips narrow the list: Mine, Visitors, Your server (through the API with a key), Automatic (a schedule, a webhook or a new record) and Test cases (a run of one of the loop’s test cases, which names its case, such as test case “a user submits repair request”). A run says where it was reached in words, such as on your site, on your site or app or through your server, and the meter above the list reads Runs still going: $0.12 spent of $5.00 allowed. Turn on several to see all of them; with none on, the list shows every run. The address keeps your choice, so a link to the page opens with the same chips on.
A run with no user, started by a schedule, a webhook or a new record, has no conversation. Its title names what started it and who it is for, such as Webhook · L-ab0508. What it did is in its outputs.
A run that the platform closed says so in words: Ran past its time limit, Failed on our side, Halted from outside, or Closed: no record of its run. Metrics uses the same words under How runs ended. A loop with several agents shows each agent’s work on its own row, with its own spend and its own ending.
Stop a run
Press Stop on a run. The turn in flight finishes, then the run ends as stopped and the user
reads the loop’s stopped message. If the run does not stop soon, the button offers Stop
again.
Take over a conversation
You can speak to a user yourself, in place of the model. Choose the run and press Take over this run. The turn in flight finishes first, then your messages go to the user and the model is silent. Press Hand back to the model to give the conversation back. The model reads what you and the user said, in order, as your team’s answer. It is told not to answer again a question you answered, and that where your words differ from the loop’s instructions, yours win in that conversation, so it answers only what the user said after your last message.
One member holds a run at a time. If another member holds it, the page names them; ask them to hand it back.
Decisions a loop waits on
A step that the loop’s record gates on operator waits for a member of your account to decide.
Home lists each one under Needs you, ahead of every other notice and the one to answer
soonest first, with the time to answer by. Decide opens that run on All runs, or, for a
decision on a run you started yourself, its conversation in My conversations, where its card
is. On All runs,
the Needs you chip shows only the runs that wait on a decision. Open one, read what the step
would do, then press Approve or Decline. Answering there answers that run.
Only decisions are counted: on Home, beside My conversations in the menu, and on All runs. A decision on a run of your own counts too. A conversation that waits for your next message reads Your turn on its row and is not counted, because it may be a question or a chat that has said all it needs to.
To ask before you decide, write in Note to the agent and press Reply. A reply approves nothing and declines nothing: the step does not run, and the agent reads your note. It can ask the person in the conversation, then send the step back to you, changed if your note asked for a change. A note also travels with Decline, so the agent knows why. Approve sends no note. The card then reads “You replied with a note”, and the run’s line “You replied with a note about the step to save a record”, never “declined”. Grant cards take a note and Reply the same way; a card about budget or turns does not.
The card names the step in words: a built-in tool reads, for example, “Allow this run to save a record?”. A tool you added on Tools reads “Approve this step?”, and the card’s Tool line shows the name you gave the tool.
The card says why the step waits. “This loop asks for approval before this step” means the loop’s record declares a gate on it. “This tool is high risk” means the tool always needs a person, whatever the role allows. A step can wait for both reasons, and the card then says both.
If nobody decides before the gate’s lifetime ends, the run that waits ends with the loop’s
lapsed message, and the action never happens. A visitor never waits for your decision: their
conversation has already ended with the loop’s closing line.
Only the approver a step names can decide it, on every surface, the API and Connect an AI
tool included. A user step is the run’s user’s own card: a member answers it only on a run
they started for themselves, and otherwise takes over the run to act for that user. An external
step waits on the outside service the run called, and only that service’s signed callback answers
it. A member who tries either gets a refusal that says who answers.
A question the run asks in words is its user’s in the same way. A message sent to the run answers the question only from the run’s own user. Another member’s message is refused; to answer for the user, take over the run. A message to a run that waits on no question is kept for its next turn, from any member.
Publish refuses an approval that nobody can give: every tool that needs approval must name who approves it.
Metrics
Metrics shows how each loop is doing: its runs, how they ended, what they cost, and how long people waited. Choose Last 7 days or Last 30 days.
A loop opens on All versions: every version that ran in the window, summed, with a line such as “38 runs started in the last 7 days, on versions 9 to 15”. Publishing a new version therefore never makes a loop look empty while earlier versions ran. Choose one version under Version to see it alone, for example to compare a new version with the one before it. Each version in that list shows how many runs started on it. Checks that refused counts each check by its name, on the versions that declare it, and across versions it names them.
Only runs started through the loop’s chat, page or API are counted, not your own chats or test
cases. The numbers are counted as runs happen, so nothing from before counting began is included;
More under the numbers says when counting began. Times, turns and spend per run are read from
fixed ranges, so each says “up to” the top of its range: “half up to 2 s · 95 in 100 up to 8 s”. Time to the first answer runs from a run’s start to the first words its agent showed a
person; time the person then takes to answer a card is not in it, and a run whose agent showed
no words has none. Tool calls that failed names each tool as the loop’s card does. Sent (emails and
webhooks) counts what was sent, what failed, and each email that was not sent because its recipient is
not verified, as Loops counts them. Sent means the receiver took it: a webhook answered
2xx, or our mail service accepted the email. An accepted email can still bounce later, and it
then moves from sent to failed.
Press Pages above the list to see how each published page is used:
- Views: the visits from readers outside your account. Sorting, filtering or refreshing the page adds none.
- Readers turned away: the readers the page’s door refused, and why. A reader is counted only where the page was found, so this number is at least what it says.
- Rows readers added, changed and removed through the page’s forms and rows.
- Runs started from row buttons: presses of a button that runs a loop on its row.
- Page actions answered: what the page did for a loop’s chat on it, such as filtering a block, and how many of those failed.
Your own looks at a page from the console, and your previews, are not counted.
Deliveries
On Loops, each webhook or email output of a loop says how its deliveries are doing: how many failed, how many are waiting or retrying, when the last one arrived, and the last error. An email that bounced says to correct the address. A failed delivery never changes how the run ended.