Persistent Agents With Their Own Identities Are Shipping Now: What Enterprise Buyers Need to Decide Before They Arrive

The enterprise AI market has spent two years debating copilots. That debate is now largely settled, and a more consequential one has begun. Microsoft, OpenAI, and Salesforce are each shipping or finalising agent products that hold persistent identities, operate outside user sessions, and coordinate multi-step work autonomously. These are not incremental feature additions to existing platforms. They represent a structural change in how AI systems participate in enterprise workflows, and the governance frameworks most organisations have built for session-based AI are not designed to handle them.

Companion piece to our broader work on vendor lock-in and persistent agent architecture. See Agent Platform Lock-in: OpenAI & Anthropic's Shift for analysis of how persistent memory and autonomy create hidden pricing and platform dependency risks.

What Makes This Generation of Agents Structurally Different

Identity Persistence

Previous AI tools operated within a user session. When the session ended, so did the AI's context. Persistent agents hold their own identity tokens, maintain memory across sessions, and can be granted standing permissions to act on behalf of users or systems without a human initiating each task.

This changes the threat surface in ways that identity and access management teams have not typically modelled. An agent with a persistent identity is, from a security architecture perspective, closer to a service account than a chatbot. The policies that govern service accounts, including least-privilege access, rotation schedules, and audit logging, need to apply here.

Background Execution

Microsoft's Autopilot agents, OpenAI's operator-mode capabilities, and Salesforce Koa are each designed to run tasks in the background, triggered by events rather than user prompts. This means the agent is executing work when no human is actively watching.

The operational implication is that standard human-in-the-loop review models break down. Organisations that have relied on the natural checkpoint of a user reviewing an AI response before acting on it no longer have that checkpoint when the agent acts first and reports later.

The Delegation Boundary Problem

Delegation is the central governance question that persistent agents force into the open. When an agent can send emails, update records, trigger workflows, or call external APIs autonomously, the question is not whether to allow delegation but where to draw the boundary, and who owns that decision.

Most enterprises have not formalised delegation boundaries for AI systems because, until recently, they did not need to. The answer was implicit: the AI suggested, the human acted. Persistent agents dissolve that implicit boundary, and without an explicit policy framework, individual teams will draw their own lines inconsistently.

The risk is not a single catastrophic failure. It is a gradual accumulation of autonomous actions across dozens of agent deployments, each individually sanctioned but collectively ungoverned. By the time the pattern is visible, it is embedded in production workflows.

Cost Attribution for Continuous AI Work

Session-based AI cost models are straightforward. A user initiates a task, tokens are consumed, a cost is recorded. Persistent agents running background tasks do not map cleanly onto this model. They consume compute continuously, often in response to system events rather than user requests, which means cost attribution requires a different accounting approach.

The practical problem is that most enterprise finance and IT teams have not built the tooling to attribute continuous AI compute costs to business units, projects, or outcomes. Without that tooling, AI spend becomes an undifferentiated infrastructure line rather than a measurable investment with identifiable returns.

Organisations evaluating persistent agent platforms should require, before procurement, that the vendor can support per-agent cost telemetry at a granularity that maps to their internal cost centres. This is a solvable technical requirement, but it is far easier to specify upfront than to retrofit after deployment.

The Vendor Architecture Decisions That Are Hard to Reverse

Each of the three major platforms embeds persistent agents differently into their broader architecture. Microsoft ties Autopilot agents to Entra identity and the Microsoft 365 permission graph. OpenAI's operator model integrates with its own memory and tool-use infrastructure. Salesforce Koa is built on the Einstein platform and Data Cloud, meaning agent memory and action history live inside Salesforce's data layer.

The consequence is that agent memory, audit logs, and permission structures are not portable across platforms. An organisation that builds production workflows around Salesforce Koa's agent identity model will find that memory and permission structures do not transfer if they later want to move to a different platform.

This is not a hypothetical vendor lock-in concern. It is a concrete architectural dependency that compounds over time as more workflows reference the agent's persistent state. The decision about which platform to build on is, in practice, a multi-year commitment to that vendor's data model and identity infrastructure.

What to Decide Before Procurement, Not After

There are four decisions that enterprise technology leaders should resolve internally before signing a platform commitment.

First, define the delegation boundary policy: which categories of action an agent may take autonomously, which require human approval, and who has authority to change those boundaries over time.

Second, establish an agent identity governance model: treat persistent agents as managed identities with the same lifecycle policies applied to service accounts, including provisioning, audit, and decommissioning procedures.

Third, build cost attribution requirements into the procurement specification: require per-agent telemetry that maps to internal cost centres as a contractual deliverable, not a future roadmap item.

Fourth, assess data residency implications of agent memory: understand where the agent's persistent state is stored, under what retention policy, and whether that aligns with existing data governance obligations before the first agent goes into production.

Organisations that treat persistent agents as a straightforward extension of their existing copilot deployments will find that the governance gaps surface quickly once agents are running unsupervised in production. The decisions above are not complex, but they require deliberate effort before deployment rather than reactive remediation after it.