How can my coding agent see when an agent started and stopped in Rius?

Rius gives your coding agent the agent_lifecycle_events tool on its MCP server, which lists when each agent instance started, finished, was lost or recovered. Ask in plain words, such as “When did the planner agent’s copies die today?”, and your client fills in the arguments. The reply is a Markdown log, newest first, timed when each event happened. It is the same log the Rius console’s Agent page draws its timeline from.

How it works

Each running copy of an agent is an instance. agent_lifecycle_events returns one row per event for the instances in a workspace. The kinds are:

• started: the instance’s first heartbeat.
• finished: a clean-shutdown ping.
• lost: the instance went silent past the gone threshold. The event is timed at the sweep that noticed, and it carries last_seen_at, the last ping before the silence.
• recovered: a ping arrived after the instance was lost.

For lost and recovered moments, the reply also gives open_trace_count and open_traces, which say what was in flight at that point.

The main parameters, all optional:

Status words such as stale are not events. They appear on the live view from list_agents, which reports running, ready, stale, gone or stopped for each instance. The full argument list is in the tool reference.

Set it up

1. Connect your coding agent to the Rius MCP server once. In Claude Code, run this in your terminal. The browser sign-in opens the first time a session uses the server. If you use the Rius plugin, the server is already registered as rius. For agents without a browser, use a read-scoped API key as described on the MCP page.

   claude mcp add --transport http rius https://mcp.eu.console.rius-glassflow.com/mcp

2. Ask for the events in plain words. Your client picks the tool and sends the arguments:

   When did the planner agent’s copies die today?

   { "name": "agent_lifecycle_events", "arguments": { "agent": "planner" } }

3. Follow one copy over a longer window by naming its instance:

   Everything that happened to inst-planner-01 this week.

   {
       "name": "agent_lifecycle_events",
       "arguments": { "hours": 168, "instance": "inst-planner-01" }
   }

4. If you are not sure of an agent’s exact name, ask which agents exist first, for example “Which of my agents are running right now?”. That runs list_agents and gives you names and instance ids to reuse.

5. If more events match than limit, the reply carries a next-page hint. Your client passes it back as cursor to fetch the next page.

What you get

• A newest-first log of starts, clean finishes, losses and recoveries for one agent, one instance or the whole workspace.
• The time each event happened, not the time you loaded a page.
• For a lost instance, the last time it was heard from, so you can see how long it ran before the silence.
• For lost and recovered moments, the traces that were still open, so you can tell what a lost copy was doing.
• The same figures a person reads on the console’s Agent page, so your agent and your team talk about one set of events.

For the rest of an investigation, Monitor AI agents in production shows how traces, agents and alerts fit together. To look at what a run did, take a trace id from list_agent_traces, which also accepts agent as a filter, and pass it to get_agent_trace.

When something else fits

• To see which instances are alive right now, use list_agents. It gives the live status of each instance rather than a history of events.
• Heartbeats show liveness, not progress. A hung process that still sends heartbeats shows as running, so use list_agent_traces or agent_traces_summary to see whether runs are completing.
• To be told when something goes wrong without asking, set up an alert instead. The MCP overview covers the alert tools your client can use.

Related