Investigation and timeline workspace progress

It has been quiet on this blog for a few weeks, but Tellagen has not been quiet.

Most of the recent work has been product depth: making the investigation tab useful during a real incident, polishing the timeline workspace, and making the UX more effective during the heat of an incident.

This is a short update on what has changed and why.

Investigation tab

The investigation tab started as a place to collect findings from an external AI workflow. That was useful, but it was still too passive. If nothing had run yet, the screen did not do enough to help a responder start.

The newer direction is more operational:

• show whether an agent is connected;
• explain the local MCP path for teams that want to run investigations from Claude Code or another local LLM client;
• support an on-premise tellagen-agent path for teams that want investigations dispatched automatically inside their own infrastructure;
• keep the current incident context visible while an investigation starts;
• stream findings and progress back into the incident record.

The important product line here is control. Tellagen should not need direct access to logs, metrics, traces, repositories, or private services. In local mode, the LLM and tool access stay on the user's machine. In agent mode, the agent runs in customer infrastructure and talks to Tellagen over WebSocket. The data stays where it belongs, and Tellagen only gets the investigation output that the agent produces - leaving auditable agent traces and investigation results in the incident record.

Agent trace

One problem with AI investigation tools is that they can feel like a black box. A summary appears, but nobody can tell what the agent actually checked.

The Agent trace work is meant to fix that. Instead of only showing the final conclusion, Tellagen can now show the investigation steps: which tool ran, whether it is running or complete, what result summary came back, and how those steps connect to findings.

This becomes important during the incidents because responders need to know what has already been ruled out. "No findings" is not enough. "The agent checked Grafana logs, looked at deploy timing, and did not find a customer-impacting error pattern" is much more useful.

Better investigation outcomes

I also spent time on how investigation results are presented when the outcome is not a clean success.

There are now clearer states for runs that complete without findings, time out, fail because of provider limits, or stop before producing a reliable conclusion. That sounds small, but it changes how a responder reads the screen. A failed run should not look like a successful run with an empty list.

The goal is to make the UI honest about uncertainty. If the system does not know, it should say so clearly.

Timeline workspace

The Timeline workspace has also been getting a lot of polish.

Recent work focused on making it easier to scan, edit, and preserve context while the incident is still moving:

• cleaner timeline list and detail panes;
• better selected-event behavior;
• properties, comments, evidence, and AI context closer to the event being reviewed;
• timeline event types that include investigation output as first-class incident evidence;
• improved mobile behavior for narrow screens.

The principle is the same as the investigation work: useful information should end up in the incident record without making responders fight the interface.