Meta and Sierra publish Poppy agent protocol draft with 35 new partners including OpenAI, Visa, PayPal and Mastercard
Meta and Sierra have published the first technical draft of the Personal Agent Protocol, known as Poppy, and announced 35 additional design partners, including OpenAI, Visa, Mastercard, PayPal, Cloudflare, Bank of America, BBVA, and Walmart-related ecosystem participants. Released on October 9, 2026, the specification proposes a common framework through which personal AI agents can identify themselves to businesses, obtain customer authorization, and perform tasks across websites, APIs, and company-operated agents.
The announcement follows the protocol's initial unveiling on October 6 at Sierra Summit, where Meta and Sierra introduced the initiative alongside companies including Genesys, Rocket, Shopify, Stripe, and Walmart. The newly published draft version 0.1 provides developers with concrete mechanisms for service discovery, authentication, session management, and agent-to-business communication, moving the initiative beyond its original conceptual announcement.
Poppy addresses a growing limitation of autonomous AI systems: although personal agents can navigate websites and operate software interfaces, businesses frequently cannot reliably distinguish an authorized agent from an ordinary customer session or determine which actions the customer has permitted. This creates friction when agents attempt to manage reservations, return purchases, modify subscriptions, interact with financial institutions, or resolve customer-service problems.
The proposed solution combines established technologies, including OAuth 2.0, JSON Web Tokens, HTTPS, OpenAPI, and the Model Context Protocol (MCP), within a shared interaction model. Instead of requiring an agent to impersonate a customer through conventional browser automation, participating businesses can identify the agent, issue restricted permissions, and determine whether the task should proceed through a website, a dedicated API, or an interaction with the company's own AI agent.
A significant distinction concerns the involvement of financial institutions and payment companies. Visa, Mastercard, PayPal, Adyen, and several banks have joined the design process, but Poppy does not yet define a complete payment framework. The current specification establishes identity and authorization mechanisms, while payment-specific functionality remains an area for future development.
The initiative's commercial significance therefore depends on two separate developments: whether major AI platforms and businesses adopt a common interaction standard, and whether its security mechanisms can support transactions with meaningful financial, legal, or operational consequences. The October release establishes an initial technical foundation, but it does not demonstrate that all participating companies already operate production-ready Poppy integrations.
··········
META AND SIERRA EXPAND POPPY FROM AN INITIAL INDUSTRY PROPOSAL TO A 35-PARTNER DESIGN INITIATIVE.
The October 9 announcement broadens the initiative from customer-service and commerce applications toward an ecosystem involving AI platforms, financial institutions, insurers, telecommunications providers, retailers, and enterprise software companies.
Sierra initially announced Personal Agent Protocol on October 6 with Meta and a group of partners representing customer-service software, e-commerce, payments, and financial services. The publication of the draft three days later added 35 organizations that will participate in evaluating and shaping the specification.
The breadth of the new partner group is commercially relevant because autonomous customer agents will need access to several different types of business infrastructure. A travel-planning agent may interact with an airline, a hotel, a payment provider, and an insurer during a single trip, while a financial-services agent may need to retrieve account information, verify identity, exchange documents, and request a product or service from an institution.
Without interoperable access, developers must create separate integrations for individual companies or rely on browser automation that may fail when page layouts, authentication methods, or anti-bot systems change.
Poppy proposes a common entry point through which businesses describe their available interfaces and authorization requirements. That does not make every company accessible automatically, but it can reduce the amount of organization-specific integration code that personal-agent developers need to maintain.
The 35 additional design partners span several industries.
........
Industry group | New design partners |
Banking, payments and financial technology | Adyen, Atomic, Bank of America, BBVA, Chime, Mastercard, PayPal, Plaid, Synchrony, Venmo, Visa, Wells Fargo |
Insurance and healthcare | Cigna, GEICO, Insurify, Liberty Mutual |
Retail and travel | Gap Inc., Hertz, Nordstrom, Target, United Airlines |
AI, cloud and enterprise software | Cloudflare, ElevenLabs, Klaviyo, Notion, Okta, OneSignal, OpenAI, 1Password, Zapier, Zendesk |
Media and telecommunications | Comcast, DIRECTV, FOX, SiriusXM |
........
These organizations represent 35 additional design partners, not 35 independently verified production deployments. Their participation indicates involvement in the standard's development, but the announcement does not establish that each company has implemented the draft or committed to supporting every proposed capability.
OpenAI's participation is particularly significant because the company develops personal and professional AI agents capable of working across external applications. A standardized authorization interface could eventually allow these systems to complete customer-directed operations without relying exclusively on custom connectors or fragile browser interactions.
The presence of Visa, Mastercard, and PayPal also signals interest in the infrastructure needed for agent-driven commerce. However, their participation should not be interpreted as confirmation that Poppy already enables universal autonomous checkout, payment authorization, or settlement.
For the companies involved, the commercial incentive is to preserve visibility and control over customer relationships as AI assistants become an increasingly common intermediary. A customer may initiate an interaction through a personal agent rather than visiting the company's website directly, but the business still needs to authenticate the customer, enforce account permissions, apply commercial policies, and record the outcome.
This is the problem Poppy attempts to solve through a shared technical interface.
··········
POPPY USES FIVE BUILDING BLOCKS TO CONNECT PERSONAL AGENTS WITH BUSINESS SYSTEMS.
The draft defines a sequence covering discovery, session creation, customer authentication, cross-channel continuity, and task execution through whichever interface the business chooses to expose.
The starting point is a machine-readable discovery document published by the business at a standardized address:
https://example.com/.well-known/poppy.json
An agent can request this file to determine whether the organization supports Poppy, which authentication system it uses, and which interaction channels are available.
The file identifies the organization, protocol version, authentication provider, and any exposed APIs or company-agent endpoints. It can also describe supported extensions, allowing participants to discover capabilities beyond the core specification.
Once the agent discovers the organization, it initiates a session identifying itself and the customer it represents. This session can initially operate without customer sign-in, allowing activities such as checking product availability or retrieving public information.
When a task requires account access, the customer can authenticate through an approved mechanism. The company then issues access credentials that reflect the permissions granted, allowing the personal agent to continue its task without automatically receiving unrestricted control of the account.
The session can remain consistent across the business's website, APIs, and agent conversations. Consequently, an agent that begins by asking a question through an API may continue through a company chatbot or webpage without losing the relationship between the customer and the ongoing interaction.
The final stage concerns task execution. Businesses determine which interfaces they expose and which actions those interfaces support, while the personal agent selects an available route consistent with the customer's request and authorization.
........
Building block | Technical mechanism | Purpose |
Discovery | /.well-known/poppy.json | Advertises identity, authentication and available interfaces |
Sessions | Agent identity and session tokens | Connects activity to one user, agent and business |
Sign-in | OAuth-based authorization and supported alternatives | Grants account access with defined permissions |
Cross-channel continuity | Shared session across web, APIs and conversations | Preserves context while changing interaction channels |
Task execution | Web interfaces, OpenAPI, MCP or company agents | Allows the business to select how work is performed |
........
This architecture separates the agent's ability to find and communicate with a business from its permission to perform a particular operation.
An agent may discover a retailer and retrieve publicly available product information without being permitted to access customer orders. After authentication, it might receive permission to inspect those orders while remaining unable to modify payment details or cancel subscriptions.
The distinction is important because the availability of a technical interface does not itself constitute authorization to use every operation exposed through that interface.
Poppy also avoids requiring businesses to abandon existing software systems. A company can begin with its website, expose an existing OpenAPI interface, connect an MCP server, or provide access to its own conversational agent.
This flexibility reduces the conceptual barrier to adoption, although actual implementation still requires authentication infrastructure, session management, authorization enforcement, and operational controls.
The specification is published under Apache 2.0, allowing developers and organizations to use and extend the implementation under an established open-source license.
··········
OAUTH, AGENT IDENTITY AND CRYPTOGRAPHIC TOKENS DEFINE WHO CAN ACT FOR A CUSTOMER.
Poppy distinguishes the identity of the personal agent from the identity of the customer and uses permission-scoped credentials to control access to business systems.
A conventional login establishes that an account holder has authenticated, but an autonomous workflow introduces another participant: the software agent acting on that person's behalf.
If an agent simply logs in using the customer's ordinary credentials, the business may struggle to distinguish the agent's activity from the customer's direct actions. It may also have limited ability to restrict the agent without restricting the account holder.
Poppy introduces an identifiable agent client alongside the customer account.
Each personal agent publishes metadata at an HTTPS address identifying the software and providing the public keys used to verify its signed assertions. A participating business can inspect this information and decide whether it accepts the agent.
The business can also maintain allowlists, blocklists, registration requirements, and request limits, giving it control over which agents may use its interfaces.
For session creation, the personal agent supplies a stable, opaque identifier for the customer. The identifier is specific to the business and must not contain or be derived from personal information such as an email address or telephone number.
This design allows a business to recognize the same user across sessions while reducing the ability of unrelated businesses to correlate that user's activities through a shared identifier.
The draft distinguishes Session Tokens from Account Tokens.
A Session Token is short-lived and authorizes requests associated with a particular session. An Account Token is a longer-lived credential obtained after sign-in that allows the personal agent to establish future authenticated sessions without requiring the customer to repeat the complete authorization process.
The specification supports three sign-in approaches: direct authentication on the company's website, device-based authentication using a separate approval flow, and mediated sign-in in which the agent submits credentials to an explicitly designated company endpoint.
The mediated option introduces additional risk because the agent handles customer authentication information. The draft therefore requires protections around secret fields and imposes obligations on businesses offering mediated authentication, including request limits and additional verification where appropriate.
For supported operations, permissions are represented through OAuth scopes. The standard defines broad read and write scopes:
poppy:read — Access account information.
poppy:write — Make permitted changes to account-related resources.
Companies may introduce narrower scopes, and the specification allows organizations to use their own permissions instead of granting broad account access.
A read or write scope is still a relatively coarse authorization mechanism. A company may need additional controls to distinguish changing a delivery address from submitting a financial transaction, approving a loan application, or cancelling a high-value order.
The underlying implementation must enforce those distinctions rather than relying on the agent's interpretation of its instructions.
A security distinction within the protocol
For ordinary API calls and conversations, Poppy uses a mechanism known as Demonstrating Proof of Possession, or DPoP.
This binds an access token to a cryptographic key controlled by the personal agent. Each request includes proof that the agent possesses the corresponding private key, making a stolen token substantially less useful to an attacker who cannot reproduce the required proof.
However, the current specification makes an explicit exception for MCP integrations.
Because MCP authorization uses bearer tokens, Poppy allows an agent to obtain a bearer token restricted to the particular MCP server it intends to access. These tokens lack the same cryptographic proof-of-possession protection, so the protocol limits where they can be accepted.
The distinction matters operationally. Supporting Poppy does not automatically give every integration identical token-theft resistance, and organizations must apply appropriate controls to their individual access methods.
Companies must also validate the relationship between an organization's discovery document and its OAuth authorization server. This prevents a malicious website from simply claiming to represent an unrelated company's authentication system.
The resulting design provides a structured foundation for identity and delegated access, but security still depends on correct implementation, token storage, endpoint verification, logging, and revocation procedures.
··········
PERSONAL AGENTS CAN USE WEBSITES, DIRECT APIS OR CONVERSATIONS WITH COMPANY AGENTS.
Poppy deliberately supports different interaction methods because the most efficient interface depends on the task, the company's existing systems, and the need for human participation.
Many activities performed by autonomous agents involve structured operations that are already available through internal or public APIs.
Retrieving a flight itinerary, checking an account balance, or identifying an available replacement product may require relatively little conversational interaction. If a business exposes suitable APIs, a personal agent can invoke those interfaces directly using the credentials granted through Poppy.
Other activities are better handled through existing websites. A retailer may already have a comprehensive returns process with customer-facing explanations, eligibility checks, and options for selecting a replacement item.
Rather than requiring a separate machine-only implementation, Poppy allows an agent to navigate the website within its authorized session while the business continues enforcing the customer's permissions.
A third approach involves conversations between the personal agent and the company's own agent. This is appropriate when a task requires negotiation, information gathering, clarification, or decisions that cannot be represented through a single API call.
The protocol defines mechanisms for identifying whether a conversational participant is a human or an AI system. It also supports ongoing interactions in which responses can be streamed and requests can remain open while work is completed.
A particularly important feature is the ability to involve a human without losing the context of the existing conversation. The customer may be required to provide additional information or approve a decision, while the company may escalate the interaction to a human employee.
The Rocket mortgage demonstration
At Sierra Summit on October 6, Rocket demonstrated a workflow involving Meta's personal agent Muse and Rocket's company-operated AI agent.
The user asked Muse to obtain mortgage pre-approval. Muse discovered the relevant company interface, requested permission to connect, and directed the customer through authentication so that the required financial information could be shared.
The agents then exchanged information concerning the purchase price, down payment, and interest rate, eventually producing a pre-approval letter during the demonstration.
The workflow illustrates how a personal agent could coordinate a customer-facing financial process without requiring the customer to manually navigate every interface.
It does not establish that mortgage approvals are universally available through Poppy or that the demonstrated integration is operating as a broadly accessible production service.
Financial products also involve legal and regulatory obligations that a communication protocol cannot eliminate. Identity verification, credit assessment, consumer disclosures, data protection, record retention, and lending requirements remain the responsibility of the relevant regulated institutions.
Poppy may simplify how the participants exchange information and obtain permissions, but the protocol does not replace the substantive financial controls governing the transaction.
The same principle applies to airline bookings, insurance claims, subscription cancellations, and retail purchases. Standardized agent connectivity can reduce integration friction while leaving each business responsible for the conditions under which an action is permitted.
··········
THE OPERATIONS EXTENSION INTRODUCES EXACT-TERM APPROVAL AND PROTECTION AGAINST DUPLICATE ACTIONS.
An optional component of the draft addresses one of the most consequential problems in autonomous workflows: distinguishing an action proposed by an agent from an action that has actually been authorized and executed.
Poppy's core specification provides mechanisms for identity, authentication, and communication. Its separate Operations extension, currently defined as version 1 within the draft, introduces a structured process for confirming business actions.
Consider an agent instructed to exchange a jacket for a more expensive model.
The retailer may determine that the exchange is possible, but processing it immediately could be inappropriate if the replacement carries an additional charge or materially different conditions.
Under the Operations extension, the business first creates a proposed operation describing the precise action and its terms. The operation includes a unique identifier, a revision number, a human-readable summary, and optional structured data representing quantities, prices, products, dates, or other relevant conditions.
The personal agent presents these terms to the customer or determines whether an existing authorization covers them. Only after obtaining the required approval does it confirm the operation through the designated endpoint.
This separates negotiation and preparation from execution.
........
Operation state | Meaning |
Proposed | Terms are available but the action has not been executed |
In progress | The approved operation is being processed |
Succeeded | The action has been completed |
Failed | The action could not be completed; the result describes any effects |
Cancelled | The operation was declined or a cancellation was processed |
Expired | The proposal was not confirmed before its deadline |
........
The extension also addresses changes to transaction terms.
If the customer selects a different replacement product or the price changes, the business issues a new revision. Approval for an earlier revision does not automatically authorize materially different terms.
This protects against scenarios in which an agent obtains approval for one action but subsequently executes another because the surrounding conversation or business conditions have changed.
A separate safeguard concerns retries.
Distributed systems frequently experience network interruptions or timeouts, making it difficult for an agent to determine whether a request succeeded. Blindly resubmitting a transaction can lead to duplicate orders, multiple cancellations, or repeated charges.
The Operations extension uses the operation identifier to implement at-most-once execution for a confirmed action. Repeating a confirmation request for the same operation should not execute the action again.
If the outcome is temporarily unknown, the business retains the operation in an in-progress state until it establishes whether the action took effect. The agent can then retrieve the result rather than creating an independent duplicate transaction.
These rules are especially relevant to commerce, bookings, subscriptions, and financial processes, where uncertain completion states can create substantial operational costs.
The extension nevertheless has an important security limitation.
A confirmation records that a particular agent declared that the user approved a specific set of terms. It does not cryptographically prove that the user actually viewed or approved those terms, because the company cannot independently inspect the agent's user interface.
Where stronger assurance is required, the business may need direct customer confirmation through its own authenticated interface.
Furthermore, the Operations extension is optional. Its protections should not be attributed automatically to every implementation of the core Poppy protocol.
··········
PAYMENTS REMAIN OUTSIDE THE CURRENT SPECIFICATION DESPITE THE PARTICIPATION OF VISA, MASTERCARD AND PAYPAL.
The inclusion of major payment networks and financial institutions reflects the potential importance of agent-driven transactions, but the current draft does not define a complete interoperable payment mechanism.
An AI agent arranging a purchase needs more than permission to communicate with a merchant. It may also require an authorized payment instrument, an approved spending limit, confirmation of the purchase amount, and a process for handling declines, refunds, disputes, and exceptions.
Poppy's current specification establishes how the agent identifies itself, obtains account permissions, and interacts with business systems. Its optional Operations extension can structure approval and execution of a proposed action.
However, these mechanisms do not by themselves establish how a payment credential should be issued, tokenized, transmitted, or settled.
The protocol explicitly identifies payments as an area for future development, alongside push notifications and message attachments.
This is an important limitation because participation by companies such as Visa, Mastercard, PayPal, Adyen, and Plaid could otherwise create the impression that universal autonomous payment execution is already available.
Their involvement may help shape extensions compatible with existing payment infrastructure, but the October 9 announcement does not specify a common payment-token format or a completed interoperability framework covering all the participating organizations.
The distinction also concerns authorization.
A customer's permission to let an agent modify an order is not necessarily permission to charge an unrestricted amount to a payment card. Similarly, permission to review account information does not authorize transferring funds or establishing a new financial obligation.
A production payment system must reconcile user intent with merchant rules, payment-provider requirements, and applicable financial regulations.
Poppy could eventually provide a standardized identity and session layer beneath such systems, allowing specialized commerce and payment protocols to handle the financial transaction itself.
This architectural separation may help explain why companies from different sectors can participate in the same design initiative without agreeing to identical business processes.
A hotel booking, an insurance renewal, a clothing purchase, and a mortgage application all require authenticated interactions between customers and businesses. Their payment and contractual requirements, however, differ considerably.
The current draft attempts to standardize the shared interaction layer, leaving sector-specific transaction mechanics to existing systems and future extensions.
··········
POPPY COMPLEMENTS MCP, A2A AND UNIVERSAL COMMERCE PROTOCOL RATHER THAN REPLACING THEM.
The emerging agent-protocol ecosystem contains several standards solving different integration problems, and Poppy focuses on the customer-to-business relationship rather than every form of agent communication or transaction execution.
The Model Context Protocol provides a standardized mechanism through which AI systems can access tools, data sources, and external services. An agent might use MCP to search a database, retrieve account information, or invoke a booking tool.
Agent2Agent, or A2A, addresses interoperability among autonomous agents, allowing independent systems to discover capabilities, exchange messages, delegate tasks, and coordinate work.
The Universal Commerce Protocol, or UCP, focuses on commercial interactions such as shopping and checkout, with specific mechanisms governing merchant and platform responsibilities.
Poppy operates at a different boundary. It defines how a personal agent representing a customer discovers a business, identifies itself, establishes an authorized session, and continues working across available interfaces.
Rather than replacing MCP, Poppy can advertise an MCP endpoint within the business's discovery document and supply a session-bound authorization context for accessing it.
Similarly, a business may offer its own conversational agent through Poppy without abandoning other agent-to-agent communication standards.
........
Protocol | Primary purpose | Typical application |
Personal Agent Protocol (Poppy) | Identity, customer authorization and interaction with businesses | Personal agent managing an order or account |
Model Context Protocol (MCP) | Connecting AI systems to tools and data | Agent retrieving booking information through a tool |
Agent2Agent (A2A) | Communication and task delegation between agents | Independent agents coordinating a multi-step task |
Universal Commerce Protocol (UCP) | Commerce-specific interaction and checkout workflows | Shopping and purchase completion |
........
The technologies can potentially operate within the same workflow.
A personal agent might discover an airline through Poppy, receive customer authorization, invoke flight-management tools through MCP, and coordinate with a specialized company agent to resolve an unusual booking problem.
If the workflow requires a purchase, a commerce-specific protocol could manage the checkout while the identity and authorization context continues to be maintained through the broader interaction framework.
Such combinations require compatible implementations and careful security design. They are architectural possibilities rather than evidence that all these standards already interoperate seamlessly in production.
The development of multiple protocols also creates a practical challenge for software vendors.
Each standard introduces discovery rules, authentication requirements, data structures, versioning policies, and operational expectations. An enterprise may need to support several of them while maintaining consistent authorization and audit controls.
Poppy's adoption prospects will therefore depend partly on whether developers can integrate it into existing identity platforms and application interfaces without creating another expensive layer of custom infrastructure.
Its explicit reliance on OAuth, HTTPS, OpenAPI, and MCP is intended to reduce that burden, but real implementation costs cannot be established from the specification alone.
··········
ENTERPRISE ADOPTION WILL DEPEND ON SECURITY, STANDARDIZATION AND MEASURABLE WORKFLOW BENEFITS.
The draft creates a possible common interface for customer-authorized AI agents, but widespread adoption requires agreement on permissions, operational reliability, and responsibilities when automated actions produce mistakes.
For businesses, one potential benefit is reducing the need to support personal agents through unofficial browser automation.
When an agent accesses an ordinary website without identifying itself, the company may have difficulty applying appropriate controls or distinguishing legitimate automation from suspicious traffic. A standardized session can provide a clearer connection between the agent, the represented customer, and the requested operation.
The benefit is not limited to security. Businesses may be able to expose more efficient APIs or conversational interfaces while preserving visibility over the customer's activity across those channels.
For agent developers, a common discovery and authorization model could reduce integration maintenance. Instead of implementing different authentication and account-access procedures for every retailer, airline, insurer, or financial institution, developers could reuse shared protocol components where supported.
However, these advantages are conditional on adoption by both sides.
A protocol cannot eliminate the need for custom integrations if the relevant businesses do not implement it, nor can it guarantee successful task completion when the underlying company systems are unavailable, incomplete, or inconsistent.
The draft's permission model also requires careful implementation. Broad read and write access may be insufficient for regulated activities, and sensitive operations may require narrower scopes, direct customer confirmation, transaction limits, or additional identity verification.
A particularly important risk concerns agent authorization drift: an agent may begin with a legitimate customer instruction but interpret subsequent information or intermediate tool results in ways that lead it to propose actions outside the customer's original intent.
Poppy's authentication framework cannot independently determine whether the agent has understood the customer's request correctly. Its Operations extension can introduce explicit confirmations, but those controls depend on how the personal agent and business apply them.
Organizations considering the standard should therefore evaluate several operational measures rather than focusing exclusively on successful technical connections.
These include the proportion of tasks completed without intervention, authentication success rates, unnecessary authorization requests, errors prevented by approval checks, duplicated operations avoided, user-visible confirmation accuracy, and the time required to detect and resolve incidents.
The economic argument can also be tested through workflow costs.
A customer-service interaction currently requiring several browser operations, multiple API calls, and human intervention might become less expensive if the personal agent can connect directly to a business's authorized interface.
Conversely, implementing additional authentication services, session management, monitoring, and approval mechanisms may increase operational expenditure before transaction volumes become large enough to justify the investment.
For smaller businesses, adoption may depend heavily on whether existing e-commerce platforms, customer-service vendors, or identity providers implement Poppy on their behalf.
The participation of Shopify, Genesys, Okta, Stripe, and related infrastructure companies is therefore potentially important, although inclusion in the design initiative does not establish future product integrations or implementation timelines.
What happens after the October 9 draft
Sierra has stated that design workshops will take place during the following month, alongside development of a reference implementation intended to help organizations begin experimenting with the specification.
The currently published document is draft 0.1, and its maintainers explicitly warn that any part may change before a stable release, including changes that are not backward compatible.
Payments, asynchronous push notifications, and attachments remain unfinished areas. More detailed permissions and broader extension support will also require coordination among implementers.
No common production-adoption statistics, certified compliance program, or independently verified transaction-performance benchmarks accompanied the draft release.
Consequently, the number of design partners should be treated as evidence of industry interest rather than a substitute for operational deployment data.
For Meta, Sierra, OpenAI, and the wider partner group, the longer-term opportunity is a market in which personal AI agents become a routine interface to businesses. Customers could initiate tasks through the assistant of their choice, while companies retain a consistent mechanism for identifying the agent, obtaining authorization, and enforcing their own commercial policies.
Such a model could reduce dependence on individual websites as the primary customer interface, but it would also create new questions concerning customer ownership, commercial visibility, platform competition, and accountability when an autonomous workflow fails.
Poppy's October 9 release provides a concrete technical proposal for connecting personal AI agents with business infrastructure under delegated customer permissions. Its discovery mechanism, OAuth sessions, cross-channel continuity, and optional transaction-confirmation framework address problems that increasingly capable browser agents cannot solve through model intelligence alone.
Whether it becomes a widely adopted standard will depend on the quality of the reference implementation, the interoperability achieved among participating companies, and the ability to support financially consequential operations without sacrificing customer control or security.
··········
FOLLOW US FOR MORE.
DATA STUDIOS
datastudios.org
