All posts

Product

Agents: who ran this

The Wytness Team
·3 min read

The first question after an incident is what happened. The second — usually within a minute — is who did it. The Agents page exists for the second question: a census of every automated actor in your estate, with each one's track record attached.

You can't govern a list you don't have

Agents accumulate the way spreadsheets used to. A team ships one for support triage. Another wires one into deployments. A vendor embeds one in a product you bought. Ask most organisations "how many agents are acting on your systems right now?" and the honest answer is a shrug — not because anyone is careless, but because nobody owns the list. Every governance framework starts with an inventory question for exactly this reason: you cannot review, classify, or defend actors you haven't enumerated.

Wytness builds the list from the stream: any agent that acts is in the inventory, because the actions themselves report in. The census stays current without anyone maintaining it — there is no onboarding form to forget and no spreadsheet to go stale. In the first week of recording, most teams meet at least one agent they didn't expect to see, and that discovery is the page doing its job: the surprise you get in a dashboard is the surprise you don't get in an audit.

app.wytness.ai · agents
the censusevery agent, with its track record attached

A row is a reputation

Each agent's row is its at-a-glance record: how many events it has produced, how often it fails, and whether its chain is intact. That last one matters more than it sounds — chain state per agent means tamper-evidence isn't one global health light but a per-actor answer, so "is this agent's history trustworthy?" has its own verdict, independent of every other agent's.

The columns turn directly into work. Sort by error rate and you have a worklist — the agent failing four times as often as its peers is either broken or being asked to do something it shouldn't, and both deserve a look this week. Sort by event count and you see where the real activity concentrates, which is rarely where people assume. Filter to one team's agents and you've built a review meeting's agenda in three clicks.

Names are labels. Identity is checkable.

In ordinary logging, "which agent did this" is a naming convention — a string someone chose, hopefully unique, hopefully stable. Conventions drift: services get renamed, two teams pick the same label, a redeploy changes the identifier and history silently splits in two. Under the AGT model every event names its agent under a cryptographic identity, so activity groups by actor rather than by whatever the log line happened to say. When the census says an agent took four thousand actions last month, that's an attribution you can stand behind, not a string match.

Drill in: one agent's story

Click through and you get the agent's own page: its recent activity, the tools it touches, the sessions it ran, its error history. This is the view for the recurring review questions — what does this agent actually do all day, has its behaviour changed, is it still needed? That last question is quietly valuable: estates accumulate agents that once mattered and now run out of habit, and an inventory with per-agent activity makes retirement decisions a reading exercise instead of an argument. An inventory that answers those questions turns agent governance from an annual archaeology project into a weekly glance.

The census pairs with the tape: Events shows the actions, Agents shows the actors — and for the governance layer on top (risk tiers, approvals, the register an auditor reads), the Registry builds on this census. Questions about how agents appear in your inventory? Ask us.

ShareXLinkedIn

Keep reading

We set no cookies. Sign-in and preferences use essential first-party browser storage only — no tracking, advertising, or third-party analytics. Privacy Policy

You can't govern a list you don't have
TABLE OF CONTENTS