Skip to content
All posts
Articles
  • Product

Every agent answers to someone

What is accounted for: an agent with access, budget and policy enforced beside it and a kill switch, and on the right a monitoring chart and an activity log

Agents spread the way spreadsheets once did. One team builds one to answer customers, another builds one to chase invoices, and a year later nobody can say how many are running, who owns them or what they cost. When something goes wrong, the first question is always the same: whose agent was that? Most companies can't answer it.

From day one, we set one rule: no agent runs on aixplain without an owner, and nothing it does goes unaccounted for. Accountability isn't a report you pull after the fact. It's built into how an agent runs.

Every IT team should be able to answer four questions about every agent, at any moment:

  • Where are all our agents, and who owns each one?
  • What can each one touch, and what can it spend?
  • Can we switch any of them off, right now?
  • Is there a record of everything it did?

The answers start in the loop. Three things are enforced on every step an agent takes, not checked afterwards:

  • Access: Bodyguard checks every call to a tool, a data source or a model against the agent's permissions and allow list before it fires. It runs in the infrastructure, so a call that isn't allowed never runs, whatever the prompt says.
  • Budget: Bodyguard holds each agent to its limits on credits, run time and tokens, and to its number of iterations. A run that reaches its cost cap stops planning and answers with the work already done.
  • Policy: Inspectors check the request, each step and the answer against your rules. When a check fails, they stop the run, send the agent back, rewrite the content or log it.

Then everything is observable. Every run, every change and every credit is tracked, in a form a person can read:

  • Reporting and monitoring: usage and spend by member, by key and by asset, agents included, against each budget, with the forecast for the month, and alerts when latency, escalations or cost drift past your threshold.
  • The agent's dashboard: every run step by step, from the input and the thinking to each tool call, every Guardian action and every approval, with what it consumed in tokens and credits, the API key it came through and that key's owner. Each run carries two codes kept apart: a governance status for a violation, such as blocked by an Inspector or by a budget, and an error code when something fails in the runtime or the system, so a policy stop is never mistaken for a fault.
  • An activity log for audits: every change to the agent itself, as an asset: its rules, a new version, its limits, a change of owner, sharing with another team, a new channel it answers on. Who changed it, when, and under which policy.
  • A kill switch: every agent has one, and turning it off stops every run at once.
What is accounted for. Enforced in the loop: the agent with its owner and version; access, checked by Bodyguard, with CRM and data calls allowed and Payments blocked; budget, held by Bodyguard, with meters for credits, run time and tokens; policy, checked by Inspectors on the input, each step and the answer; and a kill switch that stops every run at once. Observability, everything tracked: a monitoring chart of usage by member, key and asset against an alert threshold; the agent's dashboard with every run step by step, including a run allowed by governance, its tokens and credits, the API key and its owner, a Guardian edit and a failed run with its error code; and the activity log of changes to the agent: a rule added, version 4 deployed, an iteration limit, sharing with Customer care, a WhatsApp channel and the owner.

We think of it as a badge and a logbook. Every agent wears a badge: its owner, what it may reach and what it may spend. Every agent keeps a logbook: what it did on its dashboard, and what was changed about it in the activity log. The badge says what the agent is allowed to do. The logbook proves what it did.

The real reason to build this way isn't the audit. It's delegation. A manager hands work to a new hire because there's a name on the work, a limit on what they can sign and a record of what they did. Agents need the same before anyone trusts them with work that matters. When your CISO asks what an agent did last Tuesday, and why it was allowed to, the answer should take one click, not a project.

And it holds wherever the agent runs: on cloud, in your VPC, on-prem or air-gapped. The owner, the limits, the kill switch and the record stay with the agent when it moves inside your perimeter.

Autonomy is only useful if someone can answer for it. An agent nobody owns is an agent nobody should run.