Skip to main content

Record Guide

This guide covers what to look at once it has run: how to read the results, how to trace what happened, and how to revisit things from the track record.

How the records work is covered in Records and metrics.

Where a section has a place on screen, you will find where to set or check what it asks you to decide at the end of it.

Where to look​

There are four places.

  • Overview — how things stand now: the latest status of each step for a workflow, what each agent has been doing recently for a cycle. Pressing an agent on a step card or in “Agent activity” takes you to the execution history narrowed to that agent
  • Execution history — the runs. Ones still going appear here too. The “Started by” column shows what started each one (Manual, Scheduled, External API, Email, Sweep, Webhook) and, where a person or an app started it, their name (an external sender has “External ([EXT])” in front). Review requests that have been decided appear as rows too, with “Reviewed by (name)” or “Decided automatically” in the agent column. You open one from here. From the run record of a workflow step, “View this run in history” narrows the list to the records of that workflow run
  • Workflow history — the workflow runs. It appears for workflows only (a cycle has no run that spans the steps). It is not narrowed to what is still going. Each agent placed on a step has one dot (a review step or a step with no agent has one dot per step); redoing does not add dots, and the latest state is shown: “Planned” for steps not reached yet, “Not run” for steps that did not run because the run failed or was rejected, and “Cancelled” from the step that was stopped onwards when the run was cancelled (hover over a dot to see it as “step name (agent name): state”, or “step name: state” for a review step or a step with no agent)
  • KPI — the figures over a period. It sits inside Overview

In the project list, the cards under “My Projects” also show “Completion rate (7d)” for the last 7 days and the number running (a stopped project shows “Stopped” and its status). The rate is counted the same way as the agent completion rate. Cards under “Public Projects” do not show these.

Review requests across projects are seen under “Review requests” on the left (Review Guide).

Figures across projects are seen under “Insights”. It shows the figures for the projects you are a member of taken together, and a list by project (how they are counted is under “Reading the figures” below).

Decide who checks runs that did not end well and insufficient records, review requests left undecided, and the authentication status of connectors, and how often (what does reach you as a notification is in the Connection Guide). For the applications workflow, the owner might look at these each morning and nudge the reviewers about what is left in review requests.

Where on screen Opening a project gives you the Overview / Execution history / Workflow history / Settings tabs (Workflow history for a workflow only). KPI is under “KPI” inside Overview, and the record of operations inside the project is under “Records (audit trail)” inside Execution history. Figures across projects are under “Insights” at the top of the screen before you open a project

Reading a single run​

Pick a time in the execution history and that one run's record opens. This is the run record.

Where a run did not end well, a “Failure summary” comes first. It gives Cause, Impact and Next action, and What to review where one was recorded — and the next action points at where to look (connector settings, execution rules, step settings and inputs, or what was done). Read this first.

“What to review” is where the fix most likely lies. It shows as “Instructions (prompt)”, “Settings and connections (harness)”, “Restricted by an administrator or the system”, “External service” and the like, and when the agent's report has no comment, or the failure came from the platform, an explanation of what to review comes with it. The next-action buttons follow What to review where it narrows things down, and otherwise follow the failure category.

The record is laid out as five questions.

  • Request — which step it ran as the agent for, and what started it. Who set it up (or, where an app started it, which app; for a workflow started by email, who sent it), when it was accepted, and the attempt number from the second attempt on. Where there are input files set on the agent or files received from the previous step, they are listed separately under “Input files set on the Agent” and “Files received from the previous step”. On a step set to “Run at the same time”, “Agents run at the same time” lists how each agent of the same round is doing; on a workflow run with lanes, once the split has begun, every record of that run shows how each lane stands now (waiting for the other lanes, joined and so on) — an earlier step's record shows the current state too
  • Evidence — how many reads, how many kinds of tool were used, and how many external-service calls there were, of which how many failed (counts per connector are shown too). Whether the connectors connected shows as “Connectors connected: ◯/◯”, with the ones that did not connect and, separately, counts by reason
  • What was done — the number of tool calls, a list of which tool did what, and what became of each (performed, attempted only, denied, effect confirmed). Where the matched rule was recorded, a denial comes with the “Matched rule”. The agent's output and the files it produced appear here too
  • Confirmation — split into “Questions from the Agent” and “Review requests”. In a project's runs the agent does not ask a person anything partway through, so Questions from the Agent shows “The agent asked no questions or confirmations of a person in this execution”. Review requests appear in the run record of the review request's row (not in the record of an agent's row); a decided one shows the decision and who made it, and one not yet decided shows “Waiting for confirmation”
  • Result — how it ended. When the run simply completed and there is nothing to add, such as a reason or an error, this item does not appear (the badge in the heading shows the result)

Denials can appear under “What was done”. Those are operations stopped by the execution rules or by limits fixed on the product side (Execution Rules Guide).

The “What was done” list opens under “Operation details”. Reads and external-service calls appear there too. But the substance of an operation — the values passed in, the body written — does not.

In a run record, pressing a name under “Input files set on the Agent”, “Files received from the previous step” or “Artifacts” opens a preview, where it can also be downloaded. This is for members of the project. The versions shown are the latest one and those written since the start of the first run that recorded the file as an artifact.

The “Run info” tab has “Settings at run time”. These are the values saved at run time (such as the basic rules at run time and the model), and changing the settings later does not change this view. They are checked against the values the execution platform saved for the same run, and an item that differs shows “Differs”, with a notice at the top of the run record as well. An item with no value shows “Not recorded”.

Unless the agent has been removed with “Remove from project”, “View current settings” in the heading shows that agent's current settings (removing it only from a step does not hide it). Its goal (instructions), guardrail, and the names of the playbook, skills and input files set on it are shown read-only. These are the settings as they are now, not as they were when it ran. “Edit Agent” is shown only to the agent's owner.

The review requests under “Confirmation” show only the decision and who made it. For the content, press the name to open the review request (Review Guide). The body of the exchange is not shown here either.

Some runs have a gap in the record. Where it says no result was recorded, it is counted as neither success nor failure.

Where on screen The Execution history tab ＞ a time in the list ＞ the run record. The “Record” tab lists “Request”, “Evidence”, “What was done”, “Confirmation” and, when there is something to add, “Result”; where a run did not end well, a “Failure summary” comes first. “Settings at run time” is on the “Run info” tab

Do not misread the words for the result​

How it ended is given in seven words.

  • Completed — it means the agent neither reported that it could not finish nor said so in its final result
  • Failed (reported by agent) — the agent itself reported that it could not finish, or said so in its final result
  • Failed — it ended abnormally
  • Failed (stopped) — a person or the platform stopped it
  • Timed out — it reached the time limit
  • Not allowed by rules — the platform forbade the run itself
  • Nothing to do — there was nothing to act on, so the run never started

“Completed” is no guarantee that the work went well. The agent simply did not say that it could not finish, so check what was done under “What was done”. Since the substance of the operations is not shown, whether it was right as a piece of work is checked against the output itself.

There are three kinds of “Failed”. What you do about them differs, so read what is in the brackets: for “Failed (reported by agent)”, read the “Agent's closing report” in the “Failure summary” at the top (permission, missing input, the connected service not responding, restriction by the execution rules, and so on); plain “Failed” ended abnormally, so read the reason given with it; “Failed (stopped)” was stopped by a person or the platform.

Tracing what happened​

Review decisions, changes to execution rules and members, and similar events are traced under “Records (audit trail)”. Each is listed with its time and who did it (the events that are recorded are in the Records reference).

They can be filtered by event type, and searched by word. They can be exported as CSV too, but only the event type filter carries into the CSV; the search term does not. The list shows 50 at a time, newest first; “Load more” reads earlier ones. When the CSV is cut off at the limit, the number exported and the total are shown.

Not everything was done by a person. “Agent” and “System” appear there too. An automatic action at a deadline is recorded as System (Review Guide).

Where on screen The Execution history tab ＞ “Records (audit trail)”. “Search records”, the “Event” filter and “Export CSV” are in the same place

Opening the body leaves a reason behind​

Where a run has a body, you can open the exchange with the agent. Opening it requires a reason (up to 300 characters). Owners and members alike can open it. “Open the full record” shows the body, read-only, on a separate screen. Some runs have no body, and those cannot be opened. The conversations created for step runs and sweeps are titled “[project name] agent name” (a run started by a webhook has “[webhook]” in front, and a sweep started by email has “[mail]”).

The reason and the viewer are recorded. “Export” on the run record works the same way and requires a reason. Who looked, when, and what for is kept.

“Export CSV” on “Records (audit trail)” is a different thing, and needs no reason. What it exports is the Records (audit trail) list only; it holds no bodies.

Who looked at a body is visible to the person concerned. They can check who has looked at the body of their own run under who viewed this record. The project's owners and members can check the same record.

A body holds the content of the work. Open it only where you need to.

Where on screen The run record ＞ “Open the full record” / “Export”. The list of who looked is under “Who viewed this record” on the same screen

Reading the figures​

The figures for the results count one agent execution as the unit. You can choose the period (values are in the Settings reference).

🚨 The review figures count something different from the results. And how an automatic action at a deadline is treated differs by figure on top of that. Get this wrong and you misread how much people are doing.

  • Reviews (per workflow run) — counts only what a person decided
  • Approved by people and Send-back rate — what advanced automatically at a deadline affects neither figure. What was sent back or rejected automatically does
  • Send-backs, rejections, cancellations and Typical wait — these include automatic actions

How each figure is counted is in the Results reference.

A retry is counted as a separate execution by the agent. The same agent running the same step twice makes two.

Some things are left out of the figures. Nothing to do, still running, and insufficient records are all excluded from the “Agent completion rate”. Where a run has no recorded result, the figure is provisional. Under “KPI” in Overview, “Records incomplete” appears in place of the figure; in “Insights”, a note says it is provisional (both give the number of runs with no recorded result).

The “Agent completion rate” is not the business outcome. It is the share of runs whose result came out as “Completed”. Runs that ended with no report at all count as completed, unless the final result said the agent could not finish, but timed out, stopped, not allowed by rules and failed do not.

In “Insights”, the agent completion rate, the counts and the typical duration are counted in the same way. They take the executions of the projects you are a member of together. The list by project also shows how many runs have insufficient records, and each row opens the execution history for the same period. The review figures do not appear there; see them in each project's KPI. The initial period differs from a project's KPI (values are in the Settings reference).

Where on screen The Overview tab ＞ “KPI”. “Period” and “CSV” are in the same place. Figures across projects are under “Insights” at the top of the screen before you open a project, with “Period” in the same place

Revisiting it from the track record​

The clues for revisiting are the run records and the review track record. Choose what to fix from what you see.

What you seeWhat to fix
The “Failure summary” causeWhere to look first for each cause is in the Run Results Reference. If the execution rules stopped it, also see whether that operation should stay blocked, and whether the goal can avoid using it
Denials are listed under “What was done”Likewise the execution rules, or the goal (Execution Rules Guide)
Send-backs keep coming, with the same point in the reasonsThe agent's goal and skills
“Completed”, yet the deliverable cannot be used in the workThe goal's “to what state it finishes”, and the skills (Design Guide)
In a cycle, the same item is picked up again and againThe rules for the markers in the shared record (Design Guide)

How to try a fix before applying it is in the Design Guide.

From a workflow step run that did not go well, you can consult the AI for improvement ideas. The “Failure summary” shows “Ask for improvement ideas (alpha)” on runs that are “Failed (reported by agent)” with a recorded category, “Not allowed by rules” because a guardrail or an execution rule forbade it, or “Timed out” on reaching the execution time limit. What the AI reads is the closing report, the list of what was done (up to 80), the settings, and the body of the skills (the first five) and playbook you can read. A long body may be used only in part. The agent's output is not passed to the first consultation; if you choose to include it, it is passed from your next message (only in part when long).

The proposals come in three kinds — “Revise instructions” (the agent's goal and guardrail, a step's description), “Hand over to a person” (adding a review step, removing a placement) and “Add to Skill or Playbook” — and missing inputs or connections are shown as “Add missing input or connection”. Additions to skills are shown as proposals only for now, and cannot be applied.

Members can consult too, but only owners can “Apply”. Applying saves the chosen changes on the spot, and they are used from the next run. That run's result stays as it was, and nothing is re-run automatically. Where the agent to change belongs to someone else or is also used in another project, the agent is copied and only this project's placement switches to the copy. If the same agent is placed on several steps in this project, a change to its goal or guardrail applies to every step where it is placed. A playbook owned by someone else is copied, and the agent is made to use the copy. A playbook you own is changed itself, even if it is used elsewhere. If a setting the proposal relied on changed after the consultation, that change is not saved and the changes after it are not applied (earlier ones have already been saved). Check the content and consult again.

Loosening the reins on reviews​

This section is about workflows. A cycle has no review steps, so this setting does not appear for one (Review Guide).

It is safer to start on "Stop and wait for a decision" together with "Notify and keep waiting", and loosen it once you have a track record. "Stop and wait for a decision" on its own is not enough: depending on what is set for after the deadline, it may advance, send back or reject automatically (Review Guide).

There are two figures to look at.

  • Approved by people — the higher it is, the greater the share of decisions a person approved
  • Send-back rate — the lower it is, the smaller the share of send-backs

Send-backs and rejections done automatically affect both of these. When what is set for after the deadline is "Send back automatically" or "Reject automatically", these two do not represent people's decisions alone.

Where the first is high and the second is low, you can change to "Notify and proceed after the deadline". Where send-backs keep happening, revisit the agent's goal before loosening anything (Design Guide).

The review method is changed per step, and only the owner can change it. It can be changed under Execution rules on the Settings tab or under “Check settings” for the review step in the editor, and both change the same setting; the KPI screen is there to show the track record. Who changed it and what they changed are recorded. A changed review method applies to runs started afterwards. Runs in progress keep the method they started with.

🚨 Loosening the review method does not allow an operation the execution rules block. The review method governs the flow of the work; which operations are allowed is a separate axis (Execution Rules Guide).

Where on screen The track record is under the Overview tab ＞ “KPI” ＞ “Review methods and track record by step”. The change is under the Settings tab ＞ “Execution rules” ＞ “Step review method” ＞ the change button on each row (in a workflow, for the owner only). “Open settings” next to “Review methods and track record by step” also takes you to “Execution rules”. It can also be changed under Edit ＞ select the review step in the diagram in the middle, then “Check settings” on the right ＞ “Basic settings” ＞ “Review method”

Confirming the effect​

The KPI period is chosen from set lengths counted back from today (Settings reference). It cannot be cut at the day you made a change. So export the KPI CSV before the change and keep it, then, once the same length of time has passed after the change, export it again and compare. What the CSV holds is in the Run Results Reference.

Alongside the Agent completion rate, check the deliverables against when the work is done, as settled for the work (Design Guide).

Distinctions worth keeping straight​

These are the distinctions that cut across the sections above.

  • Taking “Completed” for a success in the business sense. It means the agent neither reported that it could not finish nor said so in its final result. What was done is checked under “What was done”
  • Looking for the count of external-service calls under “What was done”. The counts of external-service calls and of their failures are under “Evidence”. The count under “What was done” is the number of all tool calls; the list itself also carries reads and external-service calls
  • Thinking the record follows an operation down to its substance. What you get is what was done — not the values passed in or the body written
  • Reading the review figures as one. They count different things, and they treat an automatic action at a deadline differently. “Approved by people” is unaffected by what advanced automatically at a deadline, yet it is affected by what was sent back or rejected automatically
  • Thinking that loosening a review loosens the operations. The review method and the execution rules are separate axes. A blocked operation stays blocked whatever the review method
  • Opening the body lightly. A reason is required, and who looked, when, and what for is kept
  • Looking for “Workflow history” in a cycle. It does not appear there. What is running is seen under Overview and the execution history
  • Taking a run with no record for a failure. It is counted as neither success nor failure. In the figures it is left out as insufficient records