Saga dashboard

Saga: a control room for a workforce of agents

When an agent does real work overnight, three different people need the record of how it did that work: an auditor, an engineer, and the owner trying to make next month better than this one. Saga is a sprint exploration that asks what one console serving all three should look like. If you’re putting agents into production this year, use it as a practical way to think about what to capture and why, before the first regulator or the first bad night asks the question for you.

Updated
July 12, 2026
Reading Time
8 min
Saga — an interactive prototype. Click to open it live.

One overnight run, three people who need it

An agent handles a few hundred banking conversations overnight. It verifies identities, freezes cards, files disputes. Sometime after a routine version update, it stops telling a fraction of new users that they’re talking to an AI. Nothing crashes, no pager fires, and every top-line number stays healthy. That’s the opening scene of Saga’s demo. Saga is a design prototype from one of our design sprints, not a shipped product; the scenario is staged, and I’ll flag its numbers as demo data as they come up.

The morning after that run, three different people want the same record for three different reasons. An auditor wants to know whether a rule was broken, when it started, and which conversations it touched. An engineer wants to know why the behavior changed and what the agent actually did, step by step. And the owner of the workflow wants something the other two don’t: a way to make the agent do this work more reliably next month than it did last night.

The case for capturing how agents work rests on those three readers. Most teams build for none of them; the tools they inherit were made for watching servers. The third reader is the one almost everyone misses, and the one with the most money attached.

The auditor’s reason: the record is becoming law

This one now has a date on it. Under the EU AI Act, high-risk AI systems must be technically capable of automatically recording events over their whole lifetime (that’s Article 12), and the organizations deploying them must keep those logs for at least six months [1]. The high-risk category covers decisions about people: creditworthiness, employment, access to essential services, the administration of justice. Those obligations apply from August 2, 2026, which is weeks away as I write this. If your agents make or shape decisions like that in Europe, keeping a record of what they did is no longer a nice-to-have; it’s a legal floor with fines behind it.

What matters for design is the grain of the record an auditor needs. “The model is well behaved” is not an answer. In the demo, the compliance card ties the disclosure failure to a named policy (POL-DISCLOSURE-AI-1), a named test case (tc-disclosure), the release that preceded the change (v2.4.0 to v2.4.1), and the specific conversations that violated the policy. This rule, these conversations, that release. A record at that grain answers an audit in an afternoon instead of a quarter.

The engineer’s reason: the trajectory is the explanation

An agent doesn’t run a script. Given a task, it explores: it reads the ticket, picks a tool, tries a query, gets a partial answer, backtracks, tries another way. The sequence of steps it took, the trajectory, is the only honest explanation of how the work got done in your environment. If the team has written skills for the agent (the guidelines and procedures it’s supposed to load and follow), the trajectory is also where you find out whether a skill was discovered, followed faithfully, or quietly abandoned halfway through.

The demo’s failing-traces list shows what this looks like in practice: a wire transfer over a set limit, and a request for investment advice that the agent answered with a specific stock-and-bond allocation, which is precisely the regulated advice a bank assistant must never give. The metric says a check failed. The trace says where in the conversation the agent left the rails, and what it was attempting when it did. Without the trace, the engineer is debugging a rumor.

The owner’s reason: hill-climbing

Hill-climbing is improvement by small tracked steps: keep what worked, discard what didn’t, and start each attempt a little higher than the last. For agent work the loop has a specific shape. At first the agent explores, and some routes reach a good outcome. You capture a working route as a skill, which turns one success into a general pathway the agent can find and follow next time. Then the record shows you where the pathway still wobbles, and that’s the next thing you refine. We measured how much a written pathway changes what an agent does unsupervised in our skills benchmark; the short version is that the route matters as much as the model.

Three panels showing hill-climbing: an agent's many wandering exploration routes, then attempts converging around a captured skill route, then a single reliable pathway, with a loop back for new tasks.

The hill-climbing loop: explore, capture the route as a skill, refine the pathway. Each pass is only possible because the steps were tracked.

None of this works without the record. Throw the trajectories away and every task is the agent’s first day on the job, forever. Keep them, and the exploration your agents already did this quarter becomes the raw material for the pathways they’ll follow next quarter. That’s the reason to capture agent work that has nothing to do with regulators or debugging: the record is how the system gets better.

The console: a short queue, every claim tied to a test

Saga’s front page is built for the owner who has ten minutes. The engineer who wants raw traces and a query surface gets them one tab away. The most prominent element is a section titled Pay attention · 3 items: a short, ranked list of cards, each with a severity, a plain-English headline, a one-line diagnosis, and a single next action. The activity numbers executives ask about (sessions, containment, satisfaction) sit below the fold in a quiet weekly strip. In the demo, all of them stay green straight through the disclosure breach, which is exactly why they don’t get the top of the page.

What keeps the queue honest is that nearly every claim on the screen is falsifiable against a test a human wrote down in advance. The disclosure card cites tc-disclosure; the behavior-drift card cites tc-consent; the pass rate (83% in the demo) is a score against fourteen named test cases, so it can be inspected, argued with, and fixed. The compliance checks are owned by legal and risk, sitting in the same suite as the product team’s support cases, and the system drafts new test cases from real transcripts for a human to keep or discard. The suite grows the way the agents’ actual behavior grows.

Observability for agents isn’t a monitoring problem. It’s an evaluation problem wearing a monitoring costume.

Anchoring to tests is also what lets one screen serve all three readers. The auditor gets policy-linked evidence with the affected conversations attached. The engineer gets the failing trace one click from the card. The owner gets the trend: which pathways are tightening, which tests keep failing, and where the next skill is worth writing. Even the cost card follows the pattern; a cache-hit drop means little on its own, so the demo card translates it into a run-rate figure ($2,140/day, demo data) and a probable cause the owner can act on.

Pathways compound

A generic monitoring product can’t surface Saga’s first card, because the card is made of one organization’s actual rules: which disclosures are regulated, which policy code maps to them, which transfer limit must never be crossed. Software whose value lives in that kind of specificity is the case we make in the bespoke SaaS post, and Saga is what the argument looks like applied to the layer that watches the agents.

The forward-looking reason to start capturing now is that pathways compound. Every route you capture becomes a skill; every skill raises the floor for the next quarter’s work; every tracked failure tells you which pathway to refine next. Teams that keep the record will spend next year turning exploration into reliable procedure. Teams that don’t will spend it re-learning, one overnight run at a time, what their agents already figured out and forgot.

References

Article by

Rahul Parundekar

Rahul Parundekar

San Francisco-based consultant specializing in cutting-edge Generative AI (GenAI). I partner with organizations to pinpoint high-impact opportunities, streamline AI operations, and accelerate the launch of innovative products—efficiently, cost-effectively, and with controlled risk. Founder of Elevate.do and A.I. Hero, Inc.