As Otto, Action Fabric, and autonomous AI turn human requests into enterprise actions, organizations will need more than workflow logs. They will need durable records of the intent, context, authority, and conversation behind those actions.
Imagine an employee asks an enterprise AI assistant for something that sounds routine.
Give Priya access to the vendor contracts through Friday. She’s covering for me while I’m out.
The AI knows who Priya is. It identifies the relevant files, checks her role, evaluates the organization’s access policies, determines that the request falls within the employee’s authority, and initiates the necessary workflow. Another AI agent may become involved. An identity system gets updated. An approval is recorded. Priya gets access.
The entire process may take seconds.
Six weeks later, somebody asks why it happened.
Now the question is no longer simply whether the enterprise can prove that Priya received access at 2:13 p.m. Modern workflow platforms are already exceptionally good at recording system events.
The harder question is whether the enterprise can reconstruct the intent that caused those events.
What exactly did the employee request? Who participated in the conversation? What constraints were stated? What did the AI infer rather than receive explicitly? Which policies and permissions applied at that moment? Was another agent given the complete original context or only part of it? And if the resulting action crossed an AI assistant, ServiceNow, an identity platform, an external model, and another enterprise application, which system owns the authoritative record of the conversation that started everything?
That question becomes much more important when AI stops answering questions and starts doing things.
ServiceNow understands that transition exceptionally well.
From System of Record to System of Action
ServiceNow spent much of 2026 assembling an increasingly ambitious architecture for autonomous enterprise work.
ServiceNow Otto brings together the company’s conversational AI experiences and is designed to let employees, partners, and customers ask for work to be completed across systems and departments. Context Engine supplies enterprise context. Workflow Data Fabric connects AI and workflows to data that may live elsewhere. Action Fabric opens ServiceNow’s governed execution capabilities to external AI agents through its Model Context Protocol server. Autonomous Workforce extends the idea further with role-scoped AI specialists intended to complete end-to-end processes rather than merely recommend what a human should do next.
ServiceNow describes the platform in terms of an AI system that can sense, decide, act, and secure enterprise work.
I think agentic enterprises are going to need another verb.
Not memory in the increasingly elastic AI-marketing sense. Not another vector database holding embeddings. Not simply a transcript archive.
They will need durable records of the human and machine conversations from which enterprise actions emerged.
That distinction matters because the enterprise AI problem is quickly changing. The challenge is no longer simply giving a model enough data to produce a useful answer. Increasingly, it is giving an autonomous system enough context and authority to make a decision and then allowing it to change something in the real world.
ServiceNow’s own 2026 Enterprise AI Maturity Index illustrates the gap. The research found that 59% of organizations are using agentic AI, while only 9% have made significant progress creating autonomous, multistep workflows.
The models are arriving faster than the infrastructure required to trust what they do.
And when an AI action begins with a conversation, one particularly important piece of that infrastructure may be missing.
An Action Record Is Not a Conversation Record
This is not an argument that ServiceNow fails to record conversational or operational information. Quite the opposite.
ServiceNow already maintains extensive records of its AI interactions. Its documentation describes conversation records containing metadata and transcripts, interaction records across supported channels, and downloadable Virtual Agent transcripts that can include user inputs, AI responses, flow actions, subflows, inputs, and outputs. For AI voice interactions, ServiceNow separately documents execution plans, individual tool executions, conversation records, and generative-AI logs that can contain prompts, responses, and errors.
That sophistication is precisely why ServiceNow makes such an interesting case. The problem is not that the platform lacks records. The harder problem begins when the conversation, interpretation, decision, and resulting action no longer belong to the same platform.
Consider the employee-access example again.
The initial request might arrive through Otto. ServiceNow may supply the enterprise context. An external model might interpret part of the request. An AI specialist could invoke a workflow. An identity platform could execute the actual permissions change. A manager might later approve an exception in Microsoft Teams. Another agent could summarize what happened for an auditor.
Each system can create excellent records of its part of the process.
But those records answer different questions.
A transaction record can tell us what changed. A workflow record can tell us how it changed. A conversation record can help explain why people and machines believed it should change in the first place.
That is a different kind of enterprise record.
It is a record of intent.
The Transcript Is Only Part of the Evidence
It is tempting to say the answer is simply to preserve the transcript.
That helps, but a transcript is not the conversation.
A useful enterprise record may also need to preserve who participated, when an interaction occurred, which application carried it, which media accompanied it, what documents were supplied, what analysis was subsequently generated, which information was redacted, and how later versions relate to the original.
That becomes even more important when machines participate.
If an AI agent turns a conversational request into an action, the enterprise may eventually need to establish not only what the human said but what the AI received, what contextual information was added, what was inferred, which agent or model produced an analysis, and what resulting artifact another system relied upon.
This is where the emerging work around vCons, or Virtualized Conversations, becomes particularly interesting.
The IETF Virtualized Conversations Working Group is developing a platform-independent JSON format for representing conversational data across applications, enterprises, and trust boundaries. The current core Internet-Draft provides structures for parties, dialog, attachments, and analysis, along with signed and encrypted forms and mechanisms for redaction and amendment. It is an active Standards Track work item, not yet a completed RFC.
That distinction is important.
vCon should not be presented as a finished answer to the governance problems autonomous AI is creating. The work itself is still developing.
But it introduces an important architectural idea:
Treat the conversation as a first-class data object.
Not a recording trapped inside the contact-center platform that captured it. Not a transcript exported as text. Not a CRM note summarizing what someone remembers happening.
A structured conversation object capable of moving while retaining important context about the interaction it represents.
That may become increasingly valuable as the distance between what someone says and what enterprise systems subsequently do becomes shorter.
The Emerging Architecture Around vCons Matters Too
The vCon work is also expanding beyond the basic container.
As of August 2026, the IETF Working Group has active drafts covering the vCon core, a Contact Center Extension, an overview, and a privacy primer. Related individual Internet-Drafts, work that has not itself been adopted as IETF Working Group standards, are exploring agent sessions, lawful basis, generation provenance, and vCon lifecycle management using SCITT.
That direction is particularly relevant to agentic AI.
The provenance work explores how information about models, inputs, parameters, and outputs associated with generated analysis could accompany a vCon. The lifecycle work considers how transparency infrastructure might record events such as creation, processing, transmission, consent changes, and deletion. These remain proposals, but they point toward a larger problem the enterprise AI industry will have to solve whether or not these particular drafts ultimately become standards.
When AI acts on conversational information, organizations will increasingly need decision lineage.
Not merely an audit log saying that Agent A called Tool B.
Decision lineage connects the human request, the conversation in which it was made, the context subsequently supplied, the machine interpretation, the permissions in force, the action selected, and the resulting enterprise change.
That does not mean preserving a model’s private chain of thought. It means preserving the observable evidence around a decision: inputs, outputs, provenance, policy checks, approvals, tool calls, and the records on which subsequent systems relied.
No single transcript provides all of that. No single transaction log provides all of it either.
The architectural opportunity is to connect them.
Why ServiceNow Is Such a Natural Place to Do It
There is a second reason ServiceNow is an especially interesting company through which to examine this issue.
Its current strategy is built around interoperability.
Workflow Data Fabric allows enterprise data to remain in external systems while ServiceNow works with it. Zero Copy connectors provide access to sources including Snowflake, Databricks, Google BigQuery, Amazon Redshift, and Oracle without requiring that data to be duplicated inside ServiceNow.
Action Fabric extends the same philosophy to AI agents. ServiceNow says external agents, including agents built with platforms such as Claude or Copilot, or an enterprise’s own technology, can use its MCP server to trigger governed actions through ServiceNow.
That creates an elegant architectural asymmetry.
ServiceNow is increasingly making enterprise data interoperable.
It is increasingly making AI agents interoperable.
It is increasingly making enterprise actions interoperable.
What might the equivalent interoperability layer be for the conversations that initiate, constrain, approve, explain, and sometimes reverse those actions?
As of August 29, 2026, I found no public ServiceNow documentation or announcement identifying native support for the IETF vCon format.
That does not mean ServiceNow conversational data is inaccessible, it plainly is not. ServiceNow supports transcript downloads, APIs, interaction records, and data exports.
The distinction is subtler and, I think, more consequential.
Exportable data and portable meaning are not the same thing.
A JSON export can move fields from one application to another. A standardized conversation object is intended to let multiple systems understand what those fields collectively represent.
That becomes especially important when no single vendor owns the entire path from conversation to action.
Sense. Remember. Decide. Act. Secure.
Imagine inserting a conversation record into ServiceNow’s own description of the autonomous enterprise.
The AI senses what is happening. The relevant human and machine conversation is preserved as a structured record. Context Engine supplies the enterprise context needed to understand it. An agent decides what should happen. Action Fabric and ServiceNow workflows execute the approved action. AI Control Tower and the surrounding governance infrastructure oversee the process.
The architecture becomes:
Sense ➡️ Remember ➡️ Decide ➡️ Act ➡️ Secure
The word remember does more work here than it first appears to.
It means the organization can preserve the difference between what the human actually requested and what the AI concluded the human meant. It means the organization can retain context across a handoff between AI systems. It means a future auditor does not have to reconstruct intent from a ticket, a transcript, three application logs, a generated summary, and someone’s memory.
It means the conversation can become evidence in the same way that the subsequent transaction already is.
That does not require making the conversation immutable forever. Enterprises need correction, redaction, retention, deletion, access control, and lawful data-processing mechanisms. In fact, treating conversation data as an important enterprise record makes those controls more important, not less.
The goal is not permanent memory. The goal is governed by continuity.
What Adoption Could Actually Look Like
If ServiceNow ever chose to support vCons, it would not require a reinvention of the platform.
The first useful step could be surprisingly modest: support vCon as an additional representation for exporting suitable conversational interactions. ServiceNow already captures many of the underlying ingredients. A vCon export could package the relevant participants, dialog, attachments, metadata, and derived analysis into a standardized conversation object instead of requiring each downstream system to reconstruct those relationships from separate exports and APIs.
A second step could work in the opposite direction. Workflow Data Fabric could ingest vCon-formatted conversational records produced by contact centers, collaboration platforms, voice systems, CRM applications, or other AI interfaces, allowing Context Engine and ServiceNow workflows to use conversational history without requiring a bespoke conversational schema for every source.
Eventually, ServiceNow’s MCP capabilities could make appropriately permissioned conversation records available as resources to external AI agents. An agent would not merely ask ServiceNow for the current ticket status. With the proper authorization and controls, it could retrieve the relevant conversation object that explains how the ticket came to exist, what the customer actually requested, what had already been promised, and which prior analysis was derived from the interaction.
That is a much more useful form of enterprise memory.
Critically, none of this requires ServiceNow to surrender the differentiated value of Context Engine, Workflow Data Fabric, AI Control Tower, or Action Fabric.
Standards do not eliminate competitive advantage. HTTP did not eliminate browsers, SQL did not eliminate databases, and MCP is not eliminating AI platforms. Interoperability can instead expand the value of the systems surrounding the standard.
ServiceNow itself is demonstrating that principle by opening its system of action to outside agents rather than insisting that every agent originate inside ServiceNow.
Conversational data could eventually deserve the same treatment.
The Stakes Are Higher Than Customer Service
It would also be a mistake to treat this solely as a contact-center problem.
Customer service provides an obvious starting point because enterprises already capture enormous quantities of voice and messaging data there. But agentic AI is taking conversational interfaces into HR, IT operations, security, procurement, finance, legal work, field service, sales, healthcare, and virtually every other enterprise function.
Consider an AI security specialist responding to an incident after an employee reports suspicious activity conversationally. Consider an HR agent acting on a manager’s spoken request to change an employee’s access while that employee is on leave. Consider a procurement agent interpreting negotiations about price, delivery terms, and an exception to standard purchasing authority.
Or consider a customer telling an AI service agent, “Yes, go ahead and cancel it, but only after the replacement arrives.”
The action matters.
So do the words only after.
Enterprise systems have historically been optimized to record the transaction that eventually occurs. Agentic systems will increasingly need to preserve the qualifying language, commitments, exceptions, permissions, and context that determine whether that transaction should occur at all.
That is why I believe conversations are becoming infrastructure.
The Next System of Record
ServiceNow has good reason to be confident about the direction it is taking.
The company reported that ServiceNow AI crossed $1 billion in annual contract value in the second quarter of 2026. At its Financial Analyst Day, it outlined a 2030 ambition of more than $30 billion in subscription revenue, with AI expected to represent roughly 30% of annual contract value and a long-term Rule of 60+ target.
Those numbers matter less for what they say about ServiceNow than for what they say about enterprise software generally.
Autonomous AI is not remaining a demonstration technology.
It is being attached to the machinery of business.
And once AI can change that machinery, the evidentiary burden changes with it.
ServiceNow may never decide that vCon belongs natively inside its platform. Another standard may emerge. Enterprises may assemble the capability from several technologies. The current vCon drafts will undoubtedly evolve.
The architectural requirement will remain.
Once AI systems are permitted to turn conversations into actions, organizations will need records that travel farther than the application in which a conversation happened. They will need to preserve enough context to establish who participated, what was communicated, what was inferred, what authority existed, what subsequently changed, and how one led to the other.
For decades, enterprise systems have become progressively better at recording transactions.
Agentic AI changes the evidentiary problem.
A transaction can tell us what happened. A workflow can tell us how it happened. The conversation can preserve the intent and context that help explain why it happened.
ServiceNow is building one of the most ambitious systems of action in enterprise software. As AI begins converting human language into enterprise action, ServiceNow, and every company building the agentic enterprise, will have to decide what becomes the durable record of the intent behind those actions.
AI does not just need permission to act.
The enterprise needs a record of why the system concluded that permission existed.







