Blog
Saga: a control room for a workforce of agents

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 design-sprint prototype of the one console that serves all three. If you’re putting agents into production this year, use it to decide what to capture and why, before the first regulator or the first bad night asks the question for you.

Updated
July 21, 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 owner’s reason is the one almost everyone misses, and the one with the most money attached. It follows from how agents behave: an agent explores rather than runs a script, so the record of its route is both the explanation of what happened and the raw material for making future runs reliable. Throw the trajectories away and every task is the agent’s first day on the job, forever. First the auditor’s reason, then the engineer’s, then the owner’s, then the console the sprint arrived at for serving all three.

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, less than two weeks away as I update this post. If your agents make or shape decisions like that in Europe, keeping a record of what they did is now 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. 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 has a failing metric and a guess.

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. Keep the trajectories and the exploration your agents already did this quarter becomes the raw material for the pathways they’ll follow next quarter. That is the owner’s reason to capture agent work, and it has nothing to do with regulators or debugging.

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.

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.

Anchor every claim your console makes to a test a human wrote in advance, and grow the suite from real transcripts.

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.

The tools this replaces were built to watch servers

The monitoring products Saga resembles were built to watch machines that only ran the code humans wrote: they collect telemetry, draw graphs, and page a human when a threshold trips. That model assumes the interesting failures are crashes and latency. A workforce of agents fails differently; the disclosure breach crashed nothing and tripped no threshold. So the operator’s job turns into something closer to a manager reviewing staff than an engineer reading gauges, and the front page becomes an editorial act: it ranks three items, writes a plain headline and a next action for each, and pushes the healthy aggregates below the fold, because a manager’s scarce resource is attention.

Supervising staff you can’t see also raises a demand a CPU graph never had: every claim about what an agent did has to be checkable, because the reader’s next move is to act on it. Each item on the queue is pinned to something a person wrote down in advance (a named policy, a named test case, the release that preceded the change), and the pass rate is a score against fourteen named tests. 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 specificity is the case we make in the bespoke SaaS post, and Saga is that argument applied to the layer that watches the agents.

Pathways compound

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, and teams that don’t will spend it re-learning, one overnight run at a time, what their agents already figured out and forgot.

The demo carries one more warning worth restating plainly: every top-line metric stayed green straight through the disclosure breach. Sessions, containment, satisfaction, all healthy, for the entire window in which the agent was breaking a disclosure rule. That is why the aggregates live below the fold, and why the ranked queue, anchored to tests, gets the top of the page.

If you’re putting agents into production this year, start keeping the trajectories now; the logs can’t be reconstructed after the fact, and August 2, 2026 is close. Then open the prototype above and check whether its three readers match the three in your building.

References

  • EU Artificial Intelligence Act, Article 12: Record-Keeping
    European Union2024

    High-risk AI systems must technically allow automatic recording of events (logs) over the system’s lifetime (Article 12); deployers must keep the logs at least six months (Article 26(6)). Obligations for high-risk systems apply from August 2, 2026 (Article 113).

  • AI Hero: the solution surface
    Documentation2026

    Where Saga's kind of software fits in what AI Hero designs, builds, and operates. Saga itself is a prototype, not a shipped product.

Article byRahul 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.