Once an agent is live, its Runs view shows everything it has done β every time it fired, the steps it took, and whether each run worked. Use it to check a new agent is behaving on real triggers, and as the first place you look when something seems off.
Beta note: This article covers the Keragon Agents early-access release. Behaviour, limits, and UI may change during the early access period; this page is updated on a rolling basis as we learn from early adopters.
Open your agent's run history
Open the Agents section and select the agent you want to check β say, your Waitlist Appointment Confirmation agent.
Open its Runs view. Every run the agent has done β whether a schedule fired it or an event in a connected app (a new booking in your scheduling tool, a form in Healthie) β is listed here, newest first.
Read the runs list
Each row is one run, showing its status β completed, failed, or still running β and when it happened. The list covers the last 7 days β runs older than that are deleted automatically. A scheduled agent that runs every 15 minutes still builds up hundreds of rows in that window, so two tools help you get to the one you care about:
Finding a specific run
- Filter by status β show only failed runs when you're chasing a problem, or only completed ones to confirm the agent is healthy.
- Search β type to search across the run history and jump to the runs that match.
Inspect a single run
Click any run to open its detail. This is the step-by-step record of what the agent actually did:
- The trigger input β what fired the run and the data it received (e.g. the new patient-intake record from Healthie, with the fields the agent was handed).
- Each step the agent took β its reasoning as it worked through the task, in order.
- Every tool it called β and what came back β e.g. Get patient in Athena Health returning a match, then Create appointment returning the booking.
- The final outcome β where the run ended, e.g. the confirmation posted to your #patient-intake Slack channel.
- Every tool call returned a result, not an error. An error icon on a step means that call failed β even if the final message reads fine.
- The final outcome matches what you asked for. Compare it to the agent's instructions; if it references records that never came back from a successful tool call, treat it as unreliable.
- No tool is called over and over with near-identical inputs. That repetition is the signature of a run that's looping.
Debug a failing run
When a run fails or stalls, open it and read down the steps β the point where it went wrong is usually right there in the sequence. Errors at the very start, when the trigger fires, are captured too, so a run that never really got going still tells you why.
Reading a failed run
Look for the error icon on a tool-call step β that's the signal, even if the agent carried on and produced a final answer. Expand that step β it shows the error message and the reason the call failed, not just the arguments the tool was sent (for example, Athena Health returns a 400, or Slack returns "channel not found"). The fix usually lives in the agent's instructions or its authentication, not in the run itself β see Troubleshooting agents for the failure-mode-by-failure-mode checks.
What gets logged β and what's protected
Every run is recorded in full β the trigger input, each step the agent took, every tool it called and what came back, and the final result. Because agents work with real patient data, healthcare-sensitive information (PHI/PII) is redacted by default in what's stored β so you get a complete record of what the agent did without exposing the underlying patient details. Run records are kept for 7 days, then deleted automatically β the runs list always shows up to your agent's last 7 days of activity.
Β