What an AI Agent Management System Must Record Before You Scale Agents

A company can have a complete list of its AI agents and still have no idea who is responsible for them.

The list may show each agent's name and model. It may name an owner and show the connected tools. It may even show whether the agent is running.

Then one of those agents changes a CRM record. Another drafts a proposal from stale notes. A third sends a clean weekly report that hides a broken handoff.

Now the useful question is not, “Which agents do we have?” It is this:

What is each agent trusted to do, and who answers for the result?

An inventory cannot answer that on its own. You need an operating record.

A registry tells you what exists

Agent management is becoming a real software category.

Workday has made an Agent System of Record generally available. Microsoft has released an open-source Agent Governance Toolkit. IBM now treats AI agent management as a distinct management job.

This is good progress. Companies need to discover agents, secure them, and see how they behave.

But those controls answer only part of the problem.

A registry tells you that an agent exists. An operating record tells you how that agent fits into accountable work.

That difference becomes important as soon as an agent can affect a customer, a commitment, or a business decision.

The missing link is accountable work

Technical identity answers questions about the software:

• Which agent is this?
• Which version is running?
• What tools can it use?
• Where is it deployed?
• Is it healthy?

An operating record answers questions about the work:

• What outcome does the agent support?
• Which sources can it trust?
• What may it change?
• Where must a person approve the work?
• What evidence does it leave behind?
• When should it be paused or retired?

Both layers matter. The mistake is treating the first as proof that the second exists.

A registry becomes an operating system when it connects an agent to accountable work.

The Agent Operating Record below makes that connection.

The Agent Operating Record

Use this record for any production or scheduled agent that can create a meaningful consequence.

That does not mean every small helper needs a committee. It means the management record should grow with the agent's authority.

The record has eight parts.

1. Identity

Start with the facts you would expect in a registry:

• stable name and ID;
• purpose;
• current version;
• runtime environment;
• lifecycle status;
• technical owner.

This tells you which agent you are discussing. It does not yet tell you whether the agent belongs in the workflow.

2. Outcome and owner

Name the business result the agent supports. Then name the person who owns that result.

Also record the workflow owner and a backup owner. In a small company, one person may fill all three roles. The names still matter.

“AI team” is not an owner. Neither is “the business.”

The record should also state what happens when the agent is wrong. That makes the consequence visible before an incident does it for you.

For a deeper ownership check, use the Agent Ownership Scorecard.

3. Bounded job

Describe the agent's job in workflow terms.

Record:

• the trigger;
• the inputs;
• the output;
• the workflow stage before the agent acts;
• the stage after it finishes;
• what remains outside its job.

“Helps sales” is not a boundary.

“Turns approved discovery notes into a proposal draft for human review” is much closer.

The job should survive a model change. If changing the model also changes the job, the operating contract is probably buried in the prompt.

4. Source-of-truth rules

List the sources the agent may treat as authoritative.

Then record what happens when data is missing, stale, or in conflict.

This distinction is easy to lose. An agent may be able to read a document without being allowed to treat that document as truth.

Public research can support a hypothesis. It cannot prove buyer intent. A chat can hold useful context. It may not own the final CRM state.

The record should make those differences explicit.

5. Permission and approval

Describe the agent's authority with a verb:

• observe;
• summarize;
• draft;
• recommend;
• route;
• execute.

Then name the transitions that still need human approval.

“Human in the loop” is too vague. The record should say which human approves which transition.

A draft becoming an external message is one transition. Research becoming a qualified CRM stage is another. A recommendation becoming a production change is another.

6. Evidence and handoff

The agent should leave enough evidence for the next owner to judge its work.

Record the expected output shape, source references, and acceptance criteria. State which system receives the work. Name the receiving owner.

The handoff should also preserve status. Drafted, approved, sent, and accepted are not the same event.

A good artifact is not permission to act.

For a fuller handoff pattern, read A Company Brain Needs Typed Handoffs, Not Shared Ownership.

7. Runtime and correction history

The runbook says what should happen. The runtime shows what is configured now.

Keep both.

Record the live schedule or trigger. Note the destination and current permission state. Keep the last successful run alongside warning and failure history.

When an event is wrong, add a correction. Do not silently rewrite the old event. The correction is part of the evidence.

Notifications need their own rule. A detailed internal record does not require a detailed interruption. Often the right human message is one short action, approval request, or exception.

Use the automation binding reconciliation playbook when the runbook and runtime may have drifted.

8. Scorecard and lifecycle

Decide how the agent will be judged before it becomes permanent by habit.

The scorecard should cover:

• value;
• quality;
• risk;
• review burden;
• use inside the real workflow.

Then write the decision rules. What evidence would justify expansion? What would trigger repair? When should the agent pause? When should it retire?

An agent without a retirement rule tends to become infrastructure through repetition. It keeps running because it ran last week.

Copy the record

# Agent Operating Record

## 1. Identity
- agent_name:
- stable_id:
- purpose:
- version_or_config_ref:
- runtime:
- lifecycle_status: proposed | pilot | active | paused | retired
- technical_owner:

## 2. Outcome and ownership
- business_outcome:
- accountable_outcome_owner:
- workflow_owner:
- backup_owner:
- failure_consequence:

## 3. Bounded job
- trigger:
- inputs:
- output:
- stage_in:
- stage_out:
- out_of_scope:

## 4. Source-of-truth rules
- canonical_sources:
- source_owner:
- reference_only_sources:
- prohibited_sources:
- freshness_rule:
- conflict_rule:
- missing_data_behavior:

## 5. Permission and approval
- allowed_operations: observe | summarize | draft | recommend | route | execute
- prohibited_operations:
- read_access:
- write_access:
- approval_required_for:
- approval_owner:
- escalation_condition:
- stop_or_rollback_condition:

## 6. Evidence and handoff
- output_schema:
- evidence_references:
- receiving_system:
- receiving_owner:
- acceptance_criteria:
- rejection_reasons:
- acceptance_receipt:
- outcome_return_path:

## 7. Runtime and corrections
- live_runtime_binding:
- schedule_or_trigger:
- destination:
- permission_state:
- last_successful_run:
- warning_failure_history:
- action_receipts:
- correction_rule:
- notification_rule:
- last_reconciled_date:

## 8. Scorecard and lifecycle
- value_metric:
- quality_metric:
- risk_metric:
- review_burden_metric:
- workflow_use_signal:
- review_cadence:
- next_review_date:
- expand_criteria:
- repair_criteria:
- pause_criteria:
- retire_criteria:
- lifecycle_decision_owner:

How to evaluate an agent management system

Ask to see one real agent record. Do not begin with a feature tour.

If the system records technical identity and runtime status, it is an inventory or control plane. That may be useful. Just do not mistake it for the whole management system.

A system can support governed work when it also connects the agent to:

• a named business owner;
• a bounded job;
• source-of-truth rules;
• approval points;
• evidence and handoffs;
• correction history;
• a scorecard;
• a lifecycle decision.

No single product has to store every field. Identity software may hold some fields. The CRM, workflow platform, policy system, or incident system may hold others.

What matters is that the records connect. Their owners should be clear. A reviewer should be able to inspect them together.

A company brain can be distributed. Accountability cannot be implied.

One action this week

Pick one agent that already runs in production or on a schedule.

Choose the agent with the most consequence, not the best demo.

Fill out the eight parts of the record. Mark each field as known, unknown, or not applicable.

Do not debate the perfect schema. The unknowns are the point.

If you cannot name the owner or trusted source, you have found an operating gap. The same is true when approval and retirement rules are unclear. Close those gaps before adding another agent.

For the wider management layer, read From AI Sprawl to an Operating System.

If this problem already spans several revenue workflows, map your revenue bottleneck. Start with the bottleneck. The platform shortlist can wait.