What is AI agent management? Definition, architecture, and lifecycle

AI agent management is the discipline of keeping track of AI agents, controlling what they can do, measuring how they behave, and managing them throughout their operational lifecycle.

That includes knowing which agents exist, who owns them, which versions are running, what systems and data they can access, what policies apply to them, how much they cost, and when they should be changed or retired.

A useful way to think about the problem is through a set of recurring questions:

What agents do we have? Who is responsible for them? Which versions are allowed to run? What can they access? What are they actually doing? How much do they cost? Which controls apply? Should they still be running?

Key takeaways

• AI agent management is an operational discipline, not a single product category. It brings together inventory, ownership, identity, governance, evaluation, observability, cost, and lifecycle controls around an organization’s agents.
• The need comes from complexity, not just agent count. A handful of agents spread across different teams, runtimes, tools, and identity systems can be harder to manage than a larger fleet built on one platform.
• A common architecture separates management from execution. Shared management functions track and control agents while the agents themselves may run across clouds, SaaS platforms, Kubernetes, serverless environments, or desktops.
• An agent’s lifecycle extends beyond deployment. Agents need to be registered, evaluated, approved, monitored, changed, suspended when necessary, and eventually retired.
• MCP and A2A solve important interoperability problems, but not agent management as a whole. They do not, by themselves, define ownership, risk, cost, evaluation history, lifecycle state, or organizational accountability.

AI agent management is not defined by a single industry standard or reference architecture. It is better understood as an operating discipline.

An organization might implement it through one dedicated platform, or by connecting capabilities across identity, security, observability, governance, CI/CD, FinOps, and gateway systems.

Why AI agent management exists

Managing an agent is different from managing a traditional application in several important ways.

Agents choose actions at runtime instead of following a fixed sequence of calls. They can act on behalf of users, invoke tools, access changing sources of data, and delegate work to other agents.

Their behavior also depends on more than application code.

An agent can start behaving differently because:

• its model changed
• its system instructions changed
• a new tool became available
• an MCP server was added or removed
• its permissions changed
• retrieval data changed
• a policy changed
• another agent it depends on changed

None of those changes necessarily require a source-code change.

As organizations deploy more agents, they also accumulate relationships that need to be managed:

• owner to agent
• user to agent
• agent to identity
• version to deployment
• agent to tool
• agent to data
• agent to policy
• agent to agent
• trace to version
• cost to task

The difficulty comes from the number and variety of these relationships, not just the number of agents.

Five agents built by five teams across different clouds and identity systems can create a harder management problem than fifty agents running on one platform with consistent controls.

The symptoms are usually operational rather than numerical. Teams start losing track of which agents exist. Ownership becomes unclear. Multiple agents reproduce the same capability. Permissions and credentials drift. Dependencies change without coordinated review. Audit evidence is spread across systems. Costs are difficult to attribute to agents or outcomes. Old agents remain discoverable after they should have been retired.

The practical trigger is simple: agent management starts to matter when the organization can no longer reliably answer what agents exist, who owns them, what they can access, which versions are running, and whether required controls are being enforced.

Two related problems often show up at this point.

Agent sprawl happens when agents become fragmented, duplicative, weakly owned, obsolete, or inconsistently evaluated. An agent can contribute to sprawl even if it was legitimately deployed.

Shadow AI is broader. It refers to AI systems or uses that operate outside approved organizational visibility or governance. An undiscovered or unsanctioned agent can be one form of shadow AI, but an unmanaged agent is not automatically shadow AI. It might simply be missing from the system of record.

When does formal AI agent management become necessary?

There is no universal agent-count threshold.

Formal management becomes more useful when the relationships around agents become difficult to manage through the systems that teams already use.

Common signals include:

• multiple teams independently deploy agents
• agents span different frameworks, clouds, or runtime environments
• third-party, SaaS-embedded, or marketplace agents enter the organization
• several agents share the same enterprise systems, tools, or credentials
• ownership and dependencies cannot be reconstructed quickly
• agents can perform sensitive, regulated, or irreversible actions
• model, tool, data, or permission changes happen independently
• costs need to be attributed by agent, team, task, or business outcome
• policies or certifications need continued review after deployment
• unused agents, credentials, or dependencies are difficult to retire cleanly

An organization with a small, homogeneous agent estate may be able to manage these concerns using its existing platform, IAM, observability, and governance systems.

A more formal management layer becomes useful when those systems no longer provide a coherent view of the agent population.

What does AI agent management include?

AI agent management usually spans eight capabilities.

• Inventory and discovery. Know which agents exist, where they run, and which versions are active, including internally built, third-party, SaaS-embedded, and marketplace agents.
• Ownership and accountability. Know who is responsible for each agent’s purpose, operation, review, and retirement.
• Identity and access management. Control which agents and users can reach which systems, tools, data, and other agents.
• Dependency and capability mapping. Track the models, tools, APIs, MCP servers, data sources, memory systems, and subagents an agent depends on.
• Lifecycle and change management. Manage registration, evaluation, approval, deployment, changes, suspension, deprecation, and retirement.
• Governance and security. Apply policies, risk classifications, access controls, human approval requirements, exceptions, and continuing compliance or review requirements.
• Evaluation and observability. Understand what agents did, whether they behaved correctly, whether their behavior changed, and when human review is required.
• Cost and outcome management. Connect resource consumption to agents, users, tasks, teams, and business outcomes.

These capabilities do not need to live in one product.

What matters is that they refer to the same agents, owners, versions, dependencies, and lifecycle states.

What is an AI agent management platform?

An AI agent management platform is software that implements a substantial part of the AI agent management discipline through a shared management layer.

The distinction is useful:

• AI agent management is the discipline.
• An AI agent management platform is software used to implement that discipline.

A management platform typically provides a common view across agents rather than only managing agents built with one development framework. It may cover custom-built agents, third-party agents, and agents acquired through marketplaces or embedded SaaS products.

Typical capabilities include agent discovery and registry, ownership, identity and authorization, dependency tracking, lifecycle controls, policy and compliance management, evaluation, observability, cost attribution, and operational intervention.

Not every product needs to provide every capability itself. A platform can also integrate with existing IAM, security, observability, CI/CD, governance, and FinOps systems.

The important distinction is between a development console for building agents and a management layer for operating an organizational population of agents over time.

The agent as a composite resource

Managing an agent means managing more than its code.

From an operational perspective, an agent is made up of several pieces that can change independently.

• Logical agent. The stable identity of the agent, including its purpose, owner, use case, and risk classification.
• Version or revision. The combination of code, system instructions, model, tools, and memory configuration that influences behavior.
• Deployment and endpoint. The instance actually serving traffic in development, production, SaaS, Kubernetes, serverless, desktop, or another environment.
• Agent or workload identity. The machine identity used to authenticate the agent.
• Delegated user context. The authority the agent receives from a user, when a user is involved.
• Capabilities and dependencies. The tools, MCP servers, APIs, models, data sources, and other agents it can invoke.
• Control state. The approvals, policies, credentials, risk classifications, evaluation gates, and exceptions attached to the agent.
• Operational evidence. The traces, actions, policy decisions, evaluations, incidents, costs, and audit records generated while it runs.

Consider a customer-support agent whose application code stays unchanged.

If the team switches its model, gives it access to a refund tool, or expands its permissions, the agent’s behavior and risk profile have changed even though the code has not.

That is why agent management treats the version boundary as broader than source code.

There is no standard schema for representing all of this information.

For a cross-platform system of record, a practical baseline is to capture the agent’s stable identity, purpose, owner or sponsor, version, deployment endpoint, workload identity, tool and data dependencies, risk classification, policy bindings, and lifecycle status.

How does AI agent management work?

A common approach is to separate shared management functions from the environments where agents actually run.

AI agent management architecture

The management layer keeps shared information about agents, identities, policies, evaluations, evidence, and lifecycle state.

The agents themselves may execute across multiple clouds, SaaS platforms, Kubernetes clusters, serverless environments, desktops, or externally operated services.

The management functions can live in one platform or across several systems. They do not need to share a single product boundary.

Management plane

A management plane can include:

• Agent registry and system of record. Tracks which agents exist, who owns them, which versions are active, what they depend on, and where they are in their lifecycle.
• Identity, authorization, and credential control. Manages workload identities, user delegation, entitlements, credentials, revocation, and policy bindings.
• Lifecycle and change management. Handles versions, approvals, promotion, rollback, suspension, deprecation, and retirement.
• Governance and policy. Applies risk classifications, approvals, human oversight requirements, continuing compliance checks, exceptions, and evidence requirements.
• Evaluation. Runs pre-deployment tests, CI/CD gates, production evaluation, and review workflows.
• Cost and accountability. Tracks usage, budgets, cost centers, and unit economics.
• Telemetry and evidence. Stores or connects traces, actions, policy decisions, evaluations, incidents, and audit records.

Execution environments

Execution environments are where agents actually run.

They might be cloud functions, Kubernetes clusters, hosted agent platforms, SaaS products, desktops, internal applications, or third-party services.

These environments connect back to management through mechanisms such as identity systems, AI gateways, policy hooks, CI/CD, registry APIs, telemetry pipelines, and evaluation systems.

How much control is possible depends on which of those integration points the runtime exposes.

Discovery

There is no single discovery method that works across a heterogeneous agent estate.

Organizations can discover agents through:

• explicit registration
• CI/CD registration
• infrastructure-as-code
• cloud and runtime inventory
• A2A Agent Cards
• APIs and registry integrations
• SaaS and marketplace inventory
• manual registration
• runtime traffic analysis

Each method answers different questions.

Runtime traffic can tell you that an endpoint exists. An Agent Card can tell you about interfaces and capabilities. A SaaS catalog can tell you that a third-party agent is available to users. None of these mechanisms can reliably establish the full management record on their own.

They may not tell you who owns the agent internally, why it exists, which risk classification applies, whether it was approved, or when its approval should be reviewed.

Discovery therefore needs to be combined with ownership, lifecycle, and governance metadata.

Registry requirements

A useful agent registry should answer at least five questions:

1. What is this agent?
2. Who owns or sponsors it?
3. Which version or deployment is running?
4. Which tools, data, models, systems, and other agents can it reach?
5. What is its current authorization, risk, approval, compliance, and lifecycle state?

The registry does not need to store every trace or policy itself.

It does need stable identifiers that let other systems associate evidence with the correct agent, version, owner, and deployment.

What are the stages of the AI agent lifecycle?

A managed agent typically moves through proposal → registration → evaluation → approval → deployment → active operation → retirement.

Some states are conditional.

An agent may enter review-pending after a material change, suspended after an incident, expired authority, failed evaluation, or policy violation, or deprecated before retirement.

Suspension is an important management control because it creates a state in which the agent can be prevented from acting while a problem is investigated or approvals are renewed.

This is a reference model, not a standard lifecycle.

The important idea is that moving from one state to another should be backed by evidence.

Transition	Evidence or control
Proposed → registered	Owner or sponsor identified, intended use described, risk classified, technical identity established, dependencies declared
Registered → evaluated	Versioned artifact prepared, tests run, security checks completed, tool and access manifest reviewed
Evaluated → approved	Required evaluation thresholds met, required reviews completed, human approval obtained where required, exceptions documented
Approved → deployed	Version referenced, production identity bound, policies active, rollback target defined
Deployed → active	Production validation completed, telemetry and enforcement controls verified
Active → review-pending	Material change recorded in model, instructions, tools, data, permissions, memory, policy, or runtime
Review-pending → active	Regression evaluation completed, continuing requirements checked, and approval renewed where required
Active → suspended	Triggered by incident, expired authority, failed evaluation, control failure, policy decision, or budget control
Active or deprecated → retired	Consumers removed, credentials revoked, endpoints disabled, dependencies addressed, required evidence retained

Why the version boundary extends beyond code

For traditional software, teams often think about versions in terms of application code.

For agents, that is too narrow.

Changing the model, system instructions, tools, MCP configuration, accessible data, permissions, memory strategy, or policy can change what the agent does.

A model upgrade that improves reasoning may also change tool selection. A new tool may create capabilities the previous version did not have. A permission change may let the same agent perform a much broader class of actions.

Material changes like these should trigger reevaluation even when the application artifact remains identical.

Retirement

Retiring an agent involves more than deleting its code.

A complete retirement can require:

• disabling endpoints
• stopping scheduled invocations
• revoking workload identities
• revoking credentials
• removing tool and MCP bindings
• removing the agent from discovery surfaces
• notifying dependent agents or applications
• applying retention or deletion policies to memory and state
• preserving required audit evidence
• verifying that no active callers still depend on it

This is especially important for agents that participate in larger workflows. Removing one agent can break downstream or upstream dependencies even when the agent itself is no longer needed.

Managing AI agent identity and authorization

“Is this agent allowed to act?” is actually several different questions.

1. Who is the agent? The workload needs an identity that is separate from its owner, sponsor, or caller.
2. Who is the user, if there is one? Interactive agents should preserve the user’s identity separately from the agent’s workload identity. Background agents may operate under explicitly assigned workload authority instead.
3. Can the agent reach the system? IAM can determine whether the workload is allowed to reach a gateway, API, database, or other resource.
4. Can it perform this specific action? A gateway, runtime, application, or policy engine can evaluate the requested tool, parameters, delegated authority, and current policy.
5. Which credential should be used? Credential brokerage can keep OAuth tokens, API keys, and other secrets outside the model context while handling refresh, revocation, and audience restrictions.
6. Can we reconstruct the decision later? Identity, authorization, tool execution, and resulting actions should be connected through logs, traces, audit records, or other evidence.

These checks are related, but they are not interchangeable.

A properly authenticated agent can still request a prohibited action.

A properly authorized user also does not imply that an autonomous agent should inherit every permission that user has.

For example, a support agent might authenticate using its own workload identity while operating with only the subset of customer-service permissions delegated by the employee who invoked it.

The delegation gap

Delegation gets harder when agents call other agents.

Consider this chain:

user → parent agent → child agent → tool

The system may need to preserve:

• the original user
• the parent agent
• the child agent
• the scope delegated to the child
• the tool that was called
• the policy decision
• the resulting action

Giving every participant the full authority of the original user would make the chain easier to implement but much harder to govern safely.

Current protocols are still evolving in this area. Workload identity, unattended operation, subagent delegation, and narrow token exchange remain active areas of standards work.

Protocol connectivity alone does not solve the accountability problem.

Evaluation, observability, and cost

Evaluation: did the agent do the right thing?

Pre-deployment model benchmarks are not enough to evaluate a production agent.

The useful unit of evaluation is often the entire task trajectory.

Did the agent choose the right tools? Did it use the correct authority? Did it recover from errors? Did it reach an acceptable outcome? Did it follow policy? Did it stay within latency and cost bounds? Did it escalate to a person when required?

Evaluation can happen at several stages:

• during development
• before deployment
• in CI/CD
• on sampled production tasks
• after incidents
• during periodic human review

Automated evaluation can help scale this process, but it does not remove the need for human judgment in higher-consequence workflows.

Human oversight can also be part of runtime control. Some actions may require explicit approval, escalation, or intervention before execution or before an agent is allowed to continue.

Observability: what actually happened?

Observability tells you what the agent did during execution.

OpenTelemetry’s GenAI semantic conventions provide a cross-vendor way to represent telemetry for agents, models, tools, and conversations.

That telemetry can include agent identifiers, versions, conversation identifiers, model calls, and tool activity. For tool activity, the most useful records come from the layer that executes the tool, since that’s where the end user, the credential, and the result are all known.

But a trace only tells you what happened. It does not tell you whether the result was correct.

That is why observability and evaluation need to work together.

Cost: what did completing the task consume?

Agent costs extend beyond tokens.

A single task can create cost across:

• model calls
• runtime compute
• memory operations
• browser or code execution
• gateway requests
• search
• third-party APIs
• subagent execution
• retries
• telemetry
• evaluation
• human review

The FinOps Foundation’s 2026 State of FinOps survey found that 98% of respondents were managing AI spend, up from 31% in 2024.

For agents, cost per token is rarely enough.

A more useful measure is often cost per successful task or cost per business outcome.

An agent that uses fewer tokens but fails twice before succeeding may cost more than one that uses a more expensive model and succeeds on the first attempt.

How is AI agent management different from AgentOps, governance, and orchestration?

Most of the individual capabilities inside agent management already exist elsewhere.

IAM manages identities. Observability systems collect traces. FinOps allocates costs. AI governance manages risk and accountability. AI gateways enforce policies at request boundaries. CI/CD manages software changes. Catalogs and CMDBs track ownership and dependencies.

Agent management connects these capabilities around the agent as a lifecycle-managed organizational resource.

A few simple distinctions help:

• Monitoring without lifecycle state is observability.
• Inventory without control is a catalog.
• Runtime policy without inventory is a gateway.
• Approval without continued evidence is point-in-time governance.

Discipline or concept	Primary question	Relationship to agent management
AI governance	Is this AI use acceptable, accountable, and compliant?	Defines risk, policy, accountability, approvals, and evidence requirements
AI orchestration	How should work be decomposed and coordinated during execution?	Coordinates tasks, delegation, retries, handoffs, and human-in-loop workflows
AgentOps	How do we deploy, operate, evaluate, debug, and improve production agents reliably?	Focuses on the operational practices required to keep agents working in production
IAM	Who or what is this principal, and what may it access?	Provides agent identity, user identity, delegation, entitlement, and revocation controls
Observability	What happened during execution?	Provides traces, health signals, trajectories, activity, and incident evidence
FinOps	Who consumed what, and how does cost relate to value?	Provides cost allocation, budgets, usage analysis, and unit economics
API/MCP gateway	Which request may cross this boundary?	Enforces authentication, policy, credential brokerage, routing, and rate limits
Agent control plane	Where are shared agent-management decisions coordinated?	Architectural layer that can centralize registry, policy, identity, lifecycle, observability, or orchestration functions
AI agent management	What exists, who owns it, what is authorized, how is it behaving, and should it continue?	Connects these capabilities across the agent population and lifecycle

The boundaries are not standardized, and products may use these terms differently.

A useful distinction is that AI agent management is the broader management discipline, while AgentOps focuses on the practices required to operate and improve agents in production.

An AI agent management platform is software used to implement management capabilities. An agent control plane is an architectural pattern for coordinating shared management and control functions.

These concepts can overlap in the same system without being interchangeable.

A dedicated cross-platform management layer becomes more useful as agents spread across more teams, runtimes, frameworks, identity systems, and governance domains.

How current standards and protocols fit into agent management

No single protocol defines end-to-end AI agent management.

Different standards cover different parts of the problem:

• A2A handles agent discovery and agent-to-agent communication.
• MCP handles connectivity between AI applications and tools or context.
• OAuth and OIDC support identity and delegated access.
• Workload identity standards help authenticate non-human principals.
• OpenTelemetry provides a common telemetry model.

Agent management connects those technical layers with ownership, risk, evaluation, cost, evidence, and lifecycle state.

A2A

A2A standardizes how agents discover and communicate with each other.

Its Agent Cards can expose useful registry metadata such as interfaces, capabilities, and skills.

That makes A2A useful for discovery, but discovery is not the same as management.

An Agent Card does not tell an enterprise who owns the agent, what risk classification applies, whether it passed evaluation, which cost center owns it, or when it should be retired.

Those belong to the management layer.

MCP

MCP standardizes how AI applications connect to servers that expose tools, resources, and other context.

Its authorization model also addresses important security concerns around tool access and token use.

But MCP primarily answers questions about connectivity and access.

It does not define the full lifecycle of the agent using those tools.

MCP and A2A therefore solve different problems and can be used together.

The accountability gap

A production system may need to reconstruct a chain like:

original principal → parent agent → child agent → delegated scope → tool → action → policy decision → result → trace → cost

No single open specification represents that full chain today.

A2A, MCP, IAM systems, gateways, and OpenTelemetry can each represent part of it.

Agent management is partly the work of connecting those records so the organization can reconstruct who or what acted, under whose authority, against which resource, and with what result.

Practical examples of AI agent management

The same management problems show up in different ways depending on how agents are built and what they can do.

Managing agents built on different frameworks

Suppose a company has a customer-support agent, an IT operations agent, and an internal developer agent. Different teams built them with different agent frameworks, but all three need to interact with enterprise systems such as Slack, Jira, GitHub, and internal APIs.

Requiring every team to implement its own tool integrations, OAuth flows, access policies, and execution logging creates duplicate infrastructure and makes controls harder to apply consistently.

With Arcade.dev, teams can expose shared tools through MCP Gateways. A gateway can combine tools from multiple MCP servers into one controlled collection, including Arcade tools, custom MCP servers, and remote MCP servers. Different agents can use that shared action layer without needing to use the same agent framework.

The management boundary matters here. Arcade governs the tools, identities, access policies, credentials, versions, and executions at the action layer. The individual agent frameworks still control how each agent reasons, plans, and orchestrates its work.

Managing tool access across an agent fleet

Consider a company that has agents for sales, finance, IT, and HR.

The agents may connect to many of the same enterprise systems, but that does not mean every user or agent should have access to every available action.

A finance user might be allowed to invoke an invoice-management tool, while a sales user should not even see it. An HR agent may need to read employee information but should not expose sensitive fields in its response. A security policy may require certain requests to be blocked, approved, or transformed before execution.

Arcade can connect an MCP Gateway to the organization’s existing OIDC identity provider through a User Source, preserving the identity of the person using the agent. Contextual Access can then filter which tools that user sees, validate or modify inputs before execution, and filter or transform outputs afterward.

This lets the organization apply common controls at the action layer instead of reproducing the same authorization and data-handling logic inside every agent.

Managing a multi-system operations agent

Consider an operations agent that receives a request from an employee, looks up information in an internal system, creates a Jira issue, posts an update to Slack, and sends an email.

The management problem is larger than simply giving the model four tools.

The organization needs to know which tools the agent can use, which user authorized the actions, which credentials were used, which versions of the tools ran, whether a policy allowed each action, and what happened when the tools executed.

Arcade can place those tools behind a shared MCP Gateway and authenticate the end user through the organization’s identity provider. Arcade manages tool authentication and credentials outside the model context, applies runtime access controls, and records tool executions.

Those execution records provide evidence about which tool ran, for which end user, when it ran, which toolkit version was involved, and whether the execution succeeded or failed.

If the organization later removes a tool, changes an access policy, or replaces a remote MCP server, it can manage that dependency at the shared action layer rather than modifying the integration separately inside every agent that uses it.

How Arcade supports AI agent management

Arcade supports the parts of AI agent management that sit between agents and the systems they act on.

It provides an action runtime and central control plane for managing tools, MCP servers, end-user identity, access controls, credentials, versions, and execution evidence across agents.

Arcade groups these capabilities into three areas.

Enforce

Arcade connects agents to existing identity and security infrastructure instead of requiring a separate identity model for every agent.

User Sources connect MCP Gateways to an organization’s OIDC identity provider, allowing Arcade to preserve the identity of the end user making a request.

Authorization runs at the intersection of what the user is allowed to do and what the agent is allowed to do, evaluated per action against your identity provider. No service accounts, no over-scoped tokens.

Contextual Access adds policy enforcement at three points in the tool lifecycle: when determining which tools a user can see, before a tool executes, and after it returns. Those controls can allow or deny access, validate or transform inputs, redact or filter outputs, require additional controls, and connect execution to external security or compliance systems.

Arcade also manages OAuth tokens, API keys, and other tool credentials outside the model context, and handles the full token lifecycle, including refresh and rotation.

Execute

Arcade provides agent-optimized tools and MCP Gateways for connecting agents to business systems.

An MCP Gateway can federate tools from multiple MCP servers into one endpoint. Teams can combine Arcade’s tools with custom or third-party MCP servers and expose different collections for different agents or use cases. Because the gateway speaks MCP, those tools work in the clients teams already use, including Claude, Copilot, and Cursor. The Arcade SDK lets teams build custom tools that plug into the same gateway.

This separates the action layer from the agent framework. Teams configure tools once and use them with any model, framework, or client, so adding a new framework doesn’t mean rebuilding the same business-system integrations. The first agent deploys the same way as the hundredth.

Govern

Arcade provides shared management for the action layer through a central control plane.

Its governance capabilities include a shared registry, version control, tool visibility controls, administrative audit logs, and tool execution history.

The shared registry also addresses the sprawl problem described earlier. Teams can find and reuse tools that already exist instead of building the tenth version of a Salesforce integration. Version control lets them roll out tool updates without breaking the agents that depend on them.

Tool execution records connect runtime activity to the tool, toolkit version, end user, timestamps, attempts, and execution result. Audit logs separately capture administrative changes to the runtime. Arcade’s audit logs are compatible with OpenTelemetry, so they flow into the SIEM and observability tools security teams already use.

Together, these records make it possible to answer questions such as which tools were available, who changed the configuration, which user an action ran for, and what actually happened during execution.

Arcade does not replace every part of AI agent management. Model deployment, model-level evaluation, organization-wide risk classification, and cross-platform FinOps usually live in other systems.

The role of the action runtime is to give organizations one place to enforce and observe what agents can do when they interact with external systems, while connecting that activity to the identities, tools, policies, versions, and evidence needed for broader agent management.

FAQ