2 of 24

H2 2025

H1 2024

Jan

Feb

Mar

May

Apr

Jun

Jul

Aug

Sep

Nov

Oct

Dec

Core protocol research, design & specification started

Core protocol specification & documentation published with early reference implementations

Protocol idea based on own initial pains building agentic services

Initial interest from the community and potential adopters started

UIM’s HISTORY

CURRENT STATUS

Apple Intelligence announced

It all started at the start of Q2 last year. I was working on a separate project that involved building an AI-enabled data pipeline.

The task was to scrape content from real estate websites, leveraging generative AI to redefine and augment property ads. We also built a virtual broker assistant that users could interact with in order to search for properties and book showings for the properties they liked. That’s where I (as an AI agent builder) started to experience some major pain points that I’ll go into soon. That whole experience resulted in me sitting down and designing something that I felt had potential to improve massively how we build agentic services. I wanted to build AI agents and assistants that could interact with all existing services out there, but that was easier said than done.

Around summer last year I started going deep into the core of the protocol, did a lot of research and hands on trial and error. Talked with other researchers and reviewed research papers and github repos day and night trying to see the current state of things. I didn’t find anything I could use out of the box, so I started specifying some requirements and explored some ideas.

When Apple announced Apple Intelligence in June I started reading up on their App Intents framework that allowed apps to make their actions and content discoverable and its functionality available outside of the app itself, triggered by both Siri and Apple Intelligence. That inspired the idea of using the intent concept on a digital service level.

By September I had the first draft version of the protocol ready, had written a lot trying to document everything and then I decided to opensource and publish it. There were a lot of buzz in some circles on Linkedin, some tech news and newsletters wrote about it, but then I kind of started moving on with other projects. Being a lone person, maintaining and promoting an open source project in my spare time meant that the project didn’t get the attention it deserved.

But by the end of the year I started to receive some inquiries about the protocol from several people. Cut to today and now I’m happy to say that interest has started to peak compared to last year. So hopefully we’ll start seeing some adoption and contributions this year.

This will hopefully be a good enough introduction to the concepts in the protocol, but for the un-initiated in the world of AI agents, this may seem a bit complex. I’ve written a lot more digestible articles about it on the protocol’s website if this goes over your head. If the opposite occur, take a deep dive into the github repo. You’ll see a wall of text and detailed specifications that should suit you better.

Before we dive into the solution, let's understand the challenge I was seeing a bit better...

3 of 24

THE CHALLENGE

THE AI INTEGRATION MAZE

Inefficient Methods:

Web crawling & scraping limitations
Simulated browsing overhead
Inconsistent data format and extraction
Every service requires custom integrations

Technical Issues:

High latency
Frequent errors
Poor scalability
Multiple authentication systems

Business Impact:

Increased costs & maintenance overhead
Reduced reliability
Limited functionality
Legal & Ethical concerns

Today's AI agents face a complex maze when trying to interact with web services, creating significant challenges across multiple dimensions. Let me break down these challenges and their impacts.

The current landscape relies heavily on brittle approaches:

Web scraping that breaks with any HTML changes.

Resource-intensive and slow browser simulations.

Inconsistent data extraction that requires constant monitoring and maintenance.

Custom integrations needed for every single service, multiplying development effort.

These approaches leads to serious technical limitations:

High latency that degrades the user experience.

Frequent errors requiring constant monitoring.

Poor scalability that limits the growth potential of an AI assistant or service.

Multiple authentication systems increasing security risks and operational requirements.

The real cost to organizations includes:

Significantly increased development and maintenance costs.

Reduced service reliability affecting user trust in agentic services.

Limited access to more advanced functionality from web services.

Growing legal and ethical risks around data access and usage.

As we'll see in the next slide, these challenges have very real implications for both developers and end users. Let's look at a practical example that illustrates how these issues affect everyday AI applications.

The key takeaway is this: "The current state of AI-service integration is unsustainable as AI becomes more prevalent. We need a standardized approach that addresses these fundamental challenges while providing a path forward for scalable, secure AI interactions."

4 of 24

REAL-WORLD IMPACT

EACH REQUIRING: DIFFERENT APIS | UNIQUE AUTHENTICATION | CUSTOM DATA HANDLING

A DAY IN THE LIFE OF AN AI ASSISTANT

“Hey, I’m planning a trip to New York next month. Can you find me flights from San Francisco on any airline and compare a few hotel options under $200 a night? Also, let me know what the weather is likely to be while I’m there, and see if you can book a dinner reservation at a good Italian restaurant near the hotel on the second night of my stay.”

Breakdown of the Intent

1) Booking Flights:

“Can you find me flights from San Francisco on any airline?”
The user wants departure flights from San Francisco (and potentially return flights, depending on context) across multiple airlines.

2) Comparing Hotel Prices:

“Compare a few hotel options under $200 a night.”
The user wants to see multiple hotels within a specified budget.

3) Checking Weather Forecasts:

“Let me know what the weather is likely to be while I’m there.”
The AI assistant retrieves weather forecasts for the desired dates in New York.

4) Managing Restaurant Reservations:

“See if you can book a dinner reservation at a good Italian restaurant near the hotel on the second night of my stay.”
The user wants the AI to find a restaurant near the chosen hotel and secure a reservation.

Here's a real-world example that perfectly illustrates the complexity of AI-service interactions. Let's imagine a seemingly simple user request that actually requires orchestrating multiple services, each with their own unique challenges.

Consider this user request:

Planning a trip to New York. At first glance, it might seem straightforward, but let's break down what the AI assistant actually needs to accomplish:

First challenge is finding flights across multiple airlines. This requires:

- Interfacing with numerous airline booking systems.

- Handling different pricing structures.

- Managing various availability formats.

- Dealing with real-time data changes.

Next: Hotel comparison within budget constraints. This involves:

- Querying multiple hotel booking platforms.

- Normalizing pricing data across services.

- Filtering by location and amenities.

- Managing different booking systems.

Then: Weather forecasting, which requires:

- Accessing weather service APIs.

- Converting dates and time zones.

- Interpreting weather forecast data.

- Presenting it meaningfully back to the user.

Finally: Restaurant booking, combining:

- Location-based search.

- Looking up reviews and ratings.

- Checking availability.

- Reservation systems integration.

Notice how each of these tasks requires different APIs, unique authentication methods, and custom data handling. This is where the complexity multiplies - every service interaction adds another layer of integration challenges.

This complexity has real costs and impacts, which we'll explore in the next section.

5 of 24

THE COST OF COMPLEXITY

IMPACT ON AI AGENT DEVELOPMENT

IMPACT ON SERVICE PROVIDERS

Longer integration times
Continuous maintenance burden
Reliability challenges
Security vulnerabilities
Scaling difficulties
Limited access to deep functionality
Diverts resources from core feature development and innovation
Regulatory compliance risks

Inconsistent data requests
High operational costs
Terms of service violations (from web scraping)
Data privacy & copyright vulnerabilities
Compliance enforcement challenges
Complex authentication burden
Poor user experience
Performance degradation
Limited control over access

Building such experience with today's approach is extremely challenging. Let's examine how current integration challenges create a costly ripple effect across the entire ecosystem, impacting both AI developers and service providers in distinct but interconnected ways.

First, let's look at the developer perspective:

- Integration times have ballooned - what should take days often takes weeks or months.

- Teams are caught in endless maintenance cycles, constantly fixing broken integrations.

- Security becomes a major concern with each new integration adding potential vulnerabilities.

- Innovation suffers as resources are diverted to maintaining existing integrations instead of building new features or improving the user experience.

- Scaling becomes increasingly difficult as the number of service integrations grows.

On the service provider side, the challenges are equally significant:

- Their systems face unpredictable loads from inconsistent data requests from crawling or browser simulations.

- Operational costs spike trying to manage unauthorized access.

- Web scraping creates constant Terms of Service violations.

- They struggle to maintain control over their data and how it's accessed and used.

- Performance suffers for all users, not just the ones using these AI integrations.

What makes this particularly challenging is how these issues compound each other:

- Providers implement stricter security measures to protect their services, like adding captchas.

- This makes proper integration even more complex for developers.

- Which leads to more workarounds and unauthorized access attempts.

- Creating a vicious cycle of increasing complexity and cost for both parties.

Notice how the problems on both sides feed into each other, creating an unsustainable situation that gets worse as AI adoption grows.

This complex web of challenges clearly shows the need for a standardized approach that benefits both sides of the ecosystem. Let's look at how the UIM Protocol addresses these fundamental issues...

6 of 24

INTRODUCING UIM PROTOCOL

THE SOLUTION

Standardized Intent-Based Communication
Universal Policy Management
Automated Service Discovery
Built-in Security & Compliance
Flexible Architecture Options
Machine Readable (and AI understandable) Structured Data Formats

Let me introduce the Unified Intent Mediator Protocol - my proposed solution that fundamentally reimagines how AI agents and web services interact.

1. Standardized intent-based communication.

At its heart, UIM introduces 'intents' - standardized actions that web services can expose to AI agents. Think of this as creating a universal language that both sides can understand and use reliably.

2. Policy and security framework.

We've built in robust security and compliance from the ground up:

- Universal policy management ensures a consistent ruleset across services.

- Built-in security measures protect both providers and users.

- Automated compliance reduces legal risks.

3. Discovery and integration.

The protocol makes service discovery and integration seamless:

- Automated service discovery eliminates manual integration work.

- Flexible architecture options suit different deployment and operational needs.

- Machine-readable formats ensure AI agents can understand and process data efficiently.

Looking at the diagram on the right, you can see how these components work together:

- Scalability and reliability ensure robust performance.

- Intents and metadata provide clear communication structures.

- Security and efficiency optimize operations.

- Interoperability enables cross-platform integration through standardization of execution protocols.

What makes UIM powerful is not just what it does, but what it eliminates - the need for custom integrations, the security risks, the maintenance burden, and the scaling limitations.

Let's dive deeper into how each of these components works and the specific benefits they bring to both AI developers, service providers and in the end the actual users of an agentic application...

7 of 24

KEY BENEFITS AND VALUE PROPOSITION

TRANSFORMATIVE ADVANTAGES

For End Users

Experience Benefits:

Faster, more reliable AI services
Consistent behavior across services
Enhanced functionality
Better privacy controls

Integration Benefits:

Seamless service connections
Unified authentication
Consistent data handling
Cross-service capabilities

Security Benefits:

Protected data access
Transparent usage policies
Controlled permissions
Audit capabilities

For Service Providers

Technical Benefits:

Standardized AI integration layer
Robust access control
Real-time usage monitoring
Automated policy enforcement

Business Benefits:

New revenue streams
Wider AI ecosystem reach
Reduced integration support costs
Competitive advantage

Strategic Benefits:

Future-ready architecture
Data and service protection
Innovation enablement
Market leadership position

For AI Developers

Technical Benefits:

Reduction in integration time
Standardized, self-documenting interfaces
Automatic service discovery and versioning
Built-in security and compliance

Business Benefits:

Faster time to market
Lower development costs
Reduced maintenance overhead
Scalable integrations

Innovation Benefits:

Easy access to new services
Rapid prototyping capabilities
Future-proof implementations
Cross-service orchestration

The UIM Protocol creates transformative value across the entire ecosystem. Let me walk you through how it benefits each key stakeholder group in distinct but interconnected ways.

Let's start with AI developers, who see benefits across three critical dimensions:

Technically, they gain:

- Dramatically reduced integration times.

- Self-documenting interfaces that simplify development.

- Automated service discovery that eliminates manual integration work.

From a business perspective, this means:

- Getting to market faster.

- Significantly lower development and maintenance costs.

- True scalability for their AI applications.

And for innovation, they can:

- Easily experiment with new services.

- Rapidly prototype new capabilities.

- Build future-proof solutions that can evolve over time.

Service providers receive equally compelling advantages:

On the technical side:

- A standardized layer for AI integration with their service.

- Granular control over access and usage.

- Real-time monitoring and automated policy enforcement.

The business impact includes:

- New revenue opportunities from AI integrations.

- Broader reach for their services across the AI ecosystem.

- Lower support costs for integrators by supporting a standardized protocol.

Strategically, they gain:

- A future-ready architecture.

- Better protection for their data and services.

- Clear competitive advantages in the AI era.

Ultimately, end users see the most tangible benefits:

In their experience:

- AI services become faster and more reliable.

- Behavior stays consistent across different services.

- They get enhanced functionality with better privacy controls.

The integration benefits mean:

- Seamless connections between services.

- Unified authentication - no more multiple logins.

- True cross-service capabilities.

And for security:

- Better protection of their data.

- Clear understanding of how their data is used.

- Controlled permissions with audit trails.

What's particularly powerful here is how these benefits reinforce each other - as developers build better integrations, service providers can offer better capabilities, leading to improved user experiences, creating a virtuous cycle of innovation.

This comprehensive set of benefits is made possible by the protocol's key concepts, which we'll explore in detail in the next sections. Understanding these concepts is crucial for realizing the full potential of the UIM protocol in your implementations.

8 of 24

UNDERSTANDING INTENTS

INTENTS: THE BUILDING BLOCKS

Standardized action definitions
Self-describing capabilities
Versioned interfaces
Clear parameter specifications
Consistent response formats
Built-in version control
Universal discoverability

Key Components:

Unique identifier (UID)
Input/output parameters
Metadata
Execution endpoint

{

"intent_uid": "ecommerce.com:SearchProducts:v1",

"intent_name": "SearchProducts",

"description": "Search for products based on criteria",

"endpoint": "https://api.ecommerce.com/products/search",

"tags": ["e-commerce", "search", "products"],

"input_parameters": [

{"name": "query", "type": "string", "required": true, "description": "Search term"},

{"name": "category", "type": "string", "required": false, "description": "Product category"},

{"name": "price_range", "type": "string", "required": false, "description": "Price range filter"},

{"name": "sort_by", "type": "string", "required": false, "description": "Sorting criteria"}

"output_parameters": [

{"name": "products", "type": "array", "description": "List of products"},

{"name": "total_results", "type": "integer", "description": "Total number of results"}

]

}

Intents are the fundamental building blocks of the UIM Protocol—like modular “action definitions” that any AI agent can discover and invoke. Each intent is self-describing, specifying its purpose, the parameters it needs, and the results it produces. This eliminates guesswork for developers: you know exactly what data to provide and what to expect in return.

• Standardized action definitions ensure uniformity across different services.

• Metadata fields (like name, description, category, and tags) make each intent easy to discover and infer through natural language.

• Versioned interfaces (for example, “SearchProducts:v1”) prevent breaking changes and allow for smooth upgrades. Built-in version control means you can evolve your intents without disrupting existing usage.

• Input and output parameters have explicit types and requirements, so there’s no ambiguity when building or calling an intent.

• Consistent response formats reduce integration overhead—everyone is speaking the same “language.”

• Universal discoverability means AI agents can find and use these intents dynamically, without manual wiring.

We’ll see in later slides how policies layer on top of these core definitions—ensuring only authorized usage, regulating access, and maintaining accountability.

Once the fundamentals of intents are in place, policies help bring robust governance to the entire system.

9 of 24

POLICY MANAGEMENT

COMPREHENSIVE POLICY CONTROL

Policy Adherence Tokens (PATs):

Secure authentication
Usage permissions
Rate limiting
Billing integration
Compliance terms

Compliance Adherence:

Open Digital Rights Language (ODRL) policies
UIM Licence scheme
Machine readable
Usage constraints
Billing terms

Policy management is woven into the UIM Protocol to ensure that each intent call follows the right rules—covering everything from secure authentication to billing.

At the heart of this system are Policy Adherence Tokens, which give services a standardized way to define:

• Usage permissions (who can do what)

• Rate limiting (how many calls over a given period)

• Billing integration (what fees or subscription tiers are enforced)

• Compliance terms (e.g., data privacy constraints or audit requirements)

By bundling these rules into a machine-readable token, the UIM Protocol offloads the heavy lifting from both AI developers and service providers.

AI agents simply present the appropriate PAT token, and the policy framework verifies whether the request meets the allowed criteria. If so, the call proceeds; if not, it’s gracefully denied or redirected.

For more advanced governance needs, we can rely on Open Digital Rights Language policies or the simpler built-in UIM License scheme, ensuring that policy definitions, obligations, and prohibitions are clear and enforceable.

The goal is to enable automated sharing, agreement and enforcement of these policies, decreasing the burden from both AI developers and service providers in terms of compliance, limits and billing.

By handling all these details automatically, the UIM Protocol empowers AI agents to operate within well-defined boundaries.

Next, we’ll look at service discovery, which shows how agents find the right intents and apply these policies seamlessly.

10 of 24

SERVICE DISCOVERY

AUTOMATED DISCOVERY MECHANISM

Service Discovery:

Decentralized lookup process

DNS TXT records
agents.json files

Centralized lookup process

Intent discovery endpoints

Discovery Components:

Service metadata
Available intents
Policy information
Authentication requirements
Update propagation

Service discovery in UIM Protocol ensures that AI agents can automatically locate and integrate with new services—without constant manual reconfiguration.

This mechanism operates in two main ways:

1. Decentralized discovery

• Services can publish key lookup entrypoints (like the location of an agents.json file, discovery endpoints, and policy URLs) as DNS text records. This is a lightweight, widely adopted approach that any DNS system can handle.

• An agents.json file hosted at a known location describes the service’s available intents, policies, and usage constraints. AI agents simply fetch this file to understand what’s on offer.

2. Centralized discovery

• A single or multiple well-defined APIs store and update service metadata. AI agents query this “central repository” to discover which intents are available, who owns them, and how to call them.

Discovery components typically include:

• Service metadata (name, category, versioning)

• Available intents (the actions supported by the service, input parameters, expected outputs)

• Policy information (permissions, licensing, usage limits)

• Authentication requirements (like keys, tokens, etc)

• Update propagation (how and when new or updated intents get published)

The goal is dynamic integration: AI agents can discover new services, parse their capabilities, and seamlessly invoke their intents—all without burdensome manual setup.

The protocol’s discovery feature is flexible: you can adopt a fully decentralized model, a central repository, or a hybrid approach—whatever best fits your organization’s scale and governance needs.

Now that we’ve covered how discovery works, let’s explore the different ways to implement UIM in real-world scenarios.

11 of 24

THREE IMPLEMENTATION APPROACHES

ARCHITECTURE OPTIONS

Hybrid Architecture

Components:

Centralized discovery
Decentralized execution
Mixed policy management

Benefits:

Balanced approach
Flexible scaling
Optimized performance
Quality of service

Challenges:

Implementation complexity
Coordination overhead
System boundaries

Decentralized Architecture

Components:

Distributed service discovery
Local intent caching
Distributed policy management

Benefits:

Higher scalability
Higher resilience
Service autonomy

Challenges:

Complex discovery
Policy coordination
Consistency management

Centralized Architecture

Components:

Central intent repository
Unified discovery service
Policy management system

Benefits:

Simplified discovery
Consistent policies
Centralized monitoring
Coordinated security

Challenges:

Single point of failure
Scalability concerns
Higher latency

There are three different ways to implement the UIM Protocol—Centralized, Decentralized, and Hybrid architecture alternatives.

Each approach addresses discovery, policy management, and performance in a unique way. Let’s walk through their key characteristics, along with the benefits and challenges you’d typically encounter.

1. Centralized architecture.

A central intent repository, unified discovery service, and a centralized policy management system.

Benefits are:

Simplified discovery provides everything in one place, making it straightforward for AI agents to find available intents.

With a single control plane, you can apply uniform governance across all services with consistent policies.

Centralized monitoring makes it easier to track usage metrics, audit logs, and operational events.

Through coordinated security, patches and updates can be rolled out centrally.

The challenges are:

Potential single point of failure: If the repository goes down, the entire system can grind to a halt.

A central hub must handle all requests, which can become a bottleneck as usage grows.

Potential higher latency as every request to discover or execute an intent might need an extra round-trip to the central system.

This model often suits organizations that want strict governance and unified oversight—like large enterprises that need consistent security and compliance.

2. Decentralized architecture.

Provides distributed service discovery, optional local intent caching, and a distributed policy management framework.

Benefits are:

Higher scalability as each service and agent can operate more independently, reducing bottlenecks.

Higher resilience since there’s no single point of failure—services can continue operating even if part of the network goes down.

Service autonomy as each service can publish and manage its own intents and policies without a monolithic controller.

However the challenges are:

More complex discovery since AI agents need more sophisticated logic to find and cache available services.

Ensuring consistent policy coordination and enforcement across many independent services can be tricky.

Updates to intents or policies must propagate to all relevant nodes, which can be slower than in a central hub.

This approach works best when you need robust fault tolerance or want to support a diverse ecosystem of services that must keep running despite network partitions or outages.

3. The hybrid architecture.

That’s where we employ a centralized discovery mechanism combined with decentralized execution and mixed policy management.

Benefits are:

A balanced approach as you gain some simplicity from central discovery while keeping the autonomy of decentralized execution.

Only the discovery layer is centralized; actual service calls can remain peer-to-peer. Giving you a more optimized performance as agents can quickly find services from a central index but still interact with them directly, reducing extra hops.

Certain policies or monitoring can be centralized, while others remain local, potentially improving quality of service.

The challenges with this approach is:

Implementation complexity as you’re effectively running both models—some aspects centralized, some decentralized.

Coordination overhead: The central hub and peer services must stay in sync, which requires robust design and implementation.

Hybrid setups often provide the best of both worlds—they let you maintain simpler discovery while still benefiting from decentralized resilience and autonomy.

Your choice of architecture depends on organizational goals, scale, and tolerance for complexity. Centralized models are often simpler to start with, decentralized models excel in resilience and autonomy, and hybrid approaches can strike a comfortable balance between the two. Let's compare these approaches side by side...

12 of 24

ARCHITECTURE COMPARISON

KEY FACTORS

	Centralized	Decentralized	Hybrid
Scalability	Throughput: Limited by central capacity�Cost: Higher at scale	Throughput: Highly scalable Cost: Linear scaling	Throughput: Good balance Cost: Moderate at scale
Complexity	Implementation: Simple Management: Centralized control Integration: Straightforward	Implementation: Complex Management: Distributed Integration: More effort	Implementation: Moderate Management: Mixed Integration: Balanced
Security	Control: Centralized Monitoring: Unified view Risk: Single point of failure	Control: Distributed Monitoring: Fragmented Risk: Distributed risks	Control: Layered Monitoring: Comprehensive Risk: Balanced protection
Maintenance	Updates: Simple rollout Monitoring: Unified Troubleshooting: Centralized	Updates: Complex coordination Monitoring: Distributed Troubleshooting: Challenging	Updates: Coordinated Monitoring: Mixed Troubleshooting: Moderate
Resilience	Failures: Single point Recovery: Simple but critical Redundancy: Limited	Failures: Isolated Recovery: Self-healing Redundancy: Natural	Failures: Partial impact Recovery: Tiered Redundancy: Strategic
Flexibility	Changes: Easy to implement Customization: Limited Evolution: Controlled	Changes: Highly adaptable Customization: Extensive Evolution: Independent	Changes: Balanced Customization: Moderate Evolution: Coordinated

Let’s do a quick side-by-side comparison of how Centralized, Decentralized, and Hybrid architectures stack up across these core dimensions:

1. Scalability

• Centralized solutions often depend on a single infrastructure hub, which can become a bottleneck as usage grows.

• Decentralized architectures scale naturally since each node or service can handle its own load.

• Hybrid models provide a middle ground: a central layer for certain tasks, but decentralized operations to avoid bottlenecks.

2. Complexity

• Centralized setups are typically the easiest to implement and maintain, thanks to a unified control plane.

• Decentralized approaches can get quite intricate due to multiple moving parts and the need for advanced coordination among services.

• Hybrid approaches hit that sweet spot—some complexity from decentralization, but still a central point to simplify discovery or policy management.

3. Security

• Centralized systems benefit from a uniform security model, but they create a single point of failure—if the central system is compromised, everything’s at risk.

• Decentralized environments distribute that risk: compromise in one segment doesn’t necessarily affect the entire network. However, the surface area for attacks can be larger.

• Hybrid designs combine layered defenses from a central authority with local protections, striking a balance between unified oversight and distributed responsibility.

4. Maintenance

• Centralized platforms are simpler to patch and update because there’s only one core system to manage.

• Decentralized solutions require orchestrating updates across multiple nodes, which can be challenging and time-consuming.

• Hybrid implementations land somewhere in between—some updates can be managed centrally, while others require localized coordination.

5. Resilience

• Centralized architectures can suffer major outages if the central node goes down.

• Decentralized setups are inherently more resilient: if one node fails, others can continue operating.

• Hybrid environments maintain partial resilience through distributed execution, yet can rely on a central fallback or coordination layer in emergencies.

6. Flexibility

• Centralized models are generally more restrictive but allow tight governance and consistent standards.

• Decentralized ones let you adapt quickly at the service level—great for fast-moving environments, though it can be harder to maintain uniform standards.

• Hybrid solutions blend these advantages: enough flexibility for individual services, with central guidance to keep everything aligned.

Overall, the architecture you choose should reflect your top priorities—whether that’s maximizing resilience, simplifying maintenance, or balancing control with agility.

Of course, this comparison only covers the essentials: in practice, you can blend techniques and add mitigations to address any specific shortcomings.

13 of 24

INTENT SYSTEM DEEP DIVE

INTENT STRUCTURE

EXECUTION FLOW

Unique Intent Identifier (UID) Format:

namespace:intent_name:version

Examples:

intent_uid: “booking.com:SearchHotels:v1”
intent_uid: “weather.com:GetForecast:v2”

Natural language friendly metadata & parameters:

endpoint
rate_limit
price
intent_name
description
tags
input_parameters:

name, description, type, required

output_parameters:

name, description, type

Input Validation:

Ensuring all required parameters are present and correctly formatted.

Authentication:

Verifying the AI agent's identity and PAT.

Authorization:

Ensuring the AI agent has the necessary permissions as per the PAT and policies.

Execution:

Performing the action defined by the intent.

Response Formatting:

Standardizing the response for consistent interpretation by AI agents.

Error Handling:

Managing exceptions and providing error messages & resolution suggestions.

Let’s go into how an intent in the UIM Protocol is structured and how it’s executed:

Each intent is uniquely identified by a Unique identifier in the format namespace:intent_name:version. For example:

• booking.com:SearchHotels:v1

• weather.com:GetForecast:v2

This UID makes each intent globally identifiable and helps avoid confusion between different versions or different providers offering similar functionality.

Below the hood, each intent includes metadata to help AI agents (and developers) understand exactly how to use it:

• endpoint: The URL or method where the service is accessed.

• rate_limit: Specifies any throttling constraints.

• price: If applicable, indicates cost or billing details.

• intent_name and description: Plain-text fields that make it easy to infer what the intent actually does.

• tags: For categorizing or grouping intents (like “travel,” “weather,” or “analytics”).

• input_parameters: Each parameter is described by its name, type, whether it’s required, and a short description.

• output_parameters: Explains the format of the results this intent returns.

Using natural language friendly fields ensures that both humans and AI agents can quickly grasp what the intent does and what data it needs or provides.

The protocol also defines a strict intent execution flow:

1. Input Validation: The first step is verifying that the AI agent included all required parameters in the correct format. Missing or malformed inputs typically lead to an immediate error.

2. Authentication: The protocol checks the AI agent’s identity and associated credentials (like a Policy Adherence Token) to confirm it’s a trusted caller.

3. Authorization: The system ensures that the agent is allowed to use this particular intent under the current policies—for instance, verifying usage rights or rate limits.

4. Execution: Once cleared, the service performs the requested action—whether it’s fetching a hotel list, retrieving a weather forecast, or something else.

5. Response Formatting: The output is then standardized to match the specified output parameters, so agents can interpret the data consistently across services.

6. Error Handling: If something goes wrong (like the request containing invalid data, external system failures, etc), the system responds with meaningful error messages, guiding the AI agent on what to do next (like retry, fix input, or escalate).

By standardizing each of these steps, UIM Protocol ensures a consistent, transparent experience—both for service providers offering new intents and for AI agents consuming them. Next, we’ll look at discovery mechanisms and see how agents actually find these intents in the first place.

14 of 24

DISCOVERY MECHANISMS

DISCOVERY OPTIONS

Discovery Through Centralized Endpoint

Purpose:

Unified service discovery
Standardized search capabilities
Managed intent registry
Advanced filtering
Real-time updates

Intent discovery endpoint:

Endpoint: /api/intents/search
Search parameters:

query (natural language search term)
service_name
intent_name
uid
namespace
description
tags

Discovery Through agents.json Lookup

Purpose:

Complete service and intent description
Self-documenting & structured
Machine readable

JSON File structure:

service-info

name
description
service_url
service_terms_of_service_url
service_privacy_policy_url

intents: array of all provided intents
uim-public-key
uim-policy-file
uim-api-discovery
uim-compliance
uim-license

Discovery Through DNS TXT Records

Purpose:

Quick resolution, decentralized service discovery
Lightweight entry point to detailed information
Built on existing internet infrastructure

UIM Records:

uim-agents-file:

URL of the agents.json file.

uim-api-discovery:

URL of the API discovery endpoint.

uim-policy-file:

URL of the ODRL policy file.

uim-license:

The UIM license for the service.

There are three core ways for AI agents to discover services that support the UIM protocol, each tailored to different needs:

Discovery through DNS text records lookup:

• Leverages existing Internet infrastructure, making this the most lightweight and straightforward discovery method.

• These TXT records can point to further details—like the URL of an agents.json file or a centralized discovery endpoint.

Discovery by looking up a agents json file in a well known location at the service provider:

• Offers a rich, self-documenting format that describes the entire service: name, description, terms, available intents, policy files, and more.

• Because it’s version-controllable and machine-readable, it’s well-suited for scenarios where you need a cached local reference that can be updated with minimal overhead.

Discovery through a centralized discovery API endpoint:

• A central repository provides a managed intent registry through API endpoints for unified service discovery and advanced search and filtering.

• Particularly powerful if you have many services or frequently add new intents, since you can do real-time searches by name, tags, or other attributes.

One can also combine these methods—using DNS records to guide agents to an agents json file or a central endpoint, then relying on the central registry for in-depth queries.

This hybrid approach boosts flexibility and redundancy: if the central endpoint is unavailable, services can still be found via agents.json, and vice versa.

A central repository can also maintain an intent registry based on periodic discovery using the DNS and agents.json methods. Serving as an "intent search engine" for AI agents.

Now that we’ve explored these discovery mechanisms, we’ll turn our attention to the security aspects—how UIM ensures safe and authorized interactions between AI agents and services.

15 of 24

PAT ISSUANCE WORKFLOW

PRACTICAL SECURITY

The flow relies primarily on basic public key cryptography and policy agreement, with some notable characteristics

Simplicity:

Easy to implement
Quick to deploy
Lower development overhead
Fewer moving parts to maintain
No complex PKI infrastructure

Flexibility:

Works with different architectures
Adaptable to various use cases
Easy to modify/extend
Low barrier to entry

Performance:

Minimal cryptographic overhead
Fast single-step verification process
Reduced network traffic
Quick request processing

Policy adherence tokens power the security model in the protocol.

Essentially, a PAT is a cryptographically signed token that includes metadata about permissions, billing, and compliance.

The sequence on the right shows how an AI agent and service negotiate and exchange these tokens:

The agent requests agents json file which contains the service’s public key and a link to the relevant policy or license.

The agent then fetches the policy from the policy store or a designated URL, which provides the conditions for usage, rate limits, billing requirements, etc.

The agent signs the policy using its private key, proving intent to comply with the service’s rules.

It then sends the signed policy (plus its own public key) to the service. The service uses its own private key to generate a token that confirms the agent is authorized under the stated policy.

The agent receives the signed PAT and can invoke the service’s intents, presenting this PAT as proof of authorization and compliance each time it makes a request.

This design aims to be simple and flexible, relying on basic public-key cryptography rather than a full-blown Public Key Infrastructure setup.

However, there are some limitations and operational considerations to keep in mind when using this simple approach:

The current model provides only basic identity verification—more robust checks might be required depending on your threat model. Key rotation and revocation aren’t built in, so you’ll need additional workflows if keys are compromised or policies change.

Large-scale deployments need to consider key distribution latency—how quickly updated keys and revocations propagate across regions. Compliance verification may get tricky at scale, especially if you handle complex rules or integrate multiple policy stores.

Recovery from compromised keys can become complex without an automated process.

Establishing a robust root of trust across multiple organizations or cloud environments may require additional trust anchors or a reputation system.

Despite these caveats, policy adherence tokens deliver a straightforward and low-overhead method for controlling who can do what under the UIM Protocol.

While this model is easy to deploy and maintain— it’s worth conducting a comprehensive security audit and implementing enhancements to fit your exact use cases.

16 of 24

SUMMARY

01-03

DNS TXT RECORDS AND AGENTS.JSON

INTENTS

Innovative methods for discovery, allowing AI agents to find and authenticate API endpoints using familiar internet protocols.

Structured actions that service providers can expose to AI, defining specific tasks such as searching products, placing orders, or retrieving data.

17 of 24

SUMMARY

02-03

POLICY ADHERENCE TOKENS

DISCOVERY & EXECUTION APIS

Digitally signed tokens issued by service providers that encapsulate permissions, billing, and compliance rules.

AI agents can query discovery APIs to find available intents and use execution APIs to perform authenticated actions.

18 of 24

SUMMARY

03-03

UIM LICENSING SCHEME

INTEGRATION WITH OPEN DIGITAL RIGHTS LANGUAGE

Define the permissions, conditions, and prohibitions for how data returned by service providers can be used by AI agents. Inspired by Creative Commons (CC) & Responsible AI Licenses (RAIL).

Provides a structured approach to managing permissions, prohibitions, and obligations, ensuring clear and enforceable rules between AI agents and web services.

And lastly, support for both complex and simple compliance mechanisms depending on the use case.

1. Integration with Open Digital Rights Language

It’s a widely recognized framework for expressing permissions, prohibitions, and obligations—perfect for structuring agreements between AI agents and web services.

By embedding ODRL policies, we create clear usage guidelines that can be programmatically enforced. This covers things like “no redistribution,” “must attribute the original source,” or “usage limited to certain geographic regions.”

Both service providers and AI agents can see precisely what’s allowed or disallowed, reducing confusion and legal ambiguity.

2. The UIM Licensing Scheme

A simpler scheme inspired by Creative Commons licenses and Responsible AI Licenses. The UIM licensing scheme defines how data returned by a service can be used, shared, or modified by AI agents.

This scheme spells out Permissions, Conditions, Prohibitions, for example, whether the agent can store data long-term, run training on it, or pass it along to third parties. Any usage outside these terms is considered a violation.

Service providers can tailor the license to their needs—like requiring attribution or restricting commercial usage. AI agents, in turn, can easily check if they meet those conditions before invoking an intent.

By applying ODRL or the flexible licensing scheme, the UIM Protocol ensures that any data or service invocation respects the provider’s terms and ethical guidelines. And it is up to them to choose which to use based on their needs.

This fosters a more transparent and trustworthy ecosystem for everyone involved.

19 of 24

THANK YOU

UIM-BY-NC-v1.0

Here are some key ways you can get involved:

Review and provide feedback
Contribute code & ideas
Conduct research
Develop use cases
Participate in discussions

https://www.uimprotocol.com

https://www.linkedin.com/in/danielbentes/

20 of 24

"If you want to go fast, go alone; if you want to go far, go together." — African Proverb

BACKUP SLIDES

UIM PROTOCOL

21 of 24

THE PAST 3 MONTHS

RECENT AGENTIC AI DEVELOPMENTS

Nvidia’s Agentic Blueprints�Agentic AI blueprints enable custom agents to perform tasks (e.g., converting PDFs to podcasts)

OpenAI’s Operator�Autonomous browser agent capable of handling repetitive tasks (form-filling, ordering groceries). Early step toward a digital workforce executing multi-step, web-based tasks

Enterprise Adoption Trends (Deloitte survey)�26% of Australian companies testing agentic AI for autonomous task execution. Most interest in agentic AI (52%) and multiagent systems (45%), signaling a shift from generative output to action-oriented AI in businesses

General Industry Trends

Transition from content generation (generative AI) to autonomous decision-making (agentic AI).
DeepSeek shook the industry by its cost-efficient approach, open-source model and technological innovations - pushing the AI industry towards greater efficiency, accessibility and reasoning

“In the last three months, we’ve seen groundbreaking progress in the realm of agentic AI. Nvidia’s Cosmos platform and its agentic AI blueprints mark a significant push toward physical AI—where autonomous systems are stepping out of the data center and into real-world applications like autonomous vehicles and robotics.”

“Meanwhile, OpenAI’s recent release of Operator demonstrates early but promising capabilities for digital agents to perform everyday web tasks without human intervention. Although still in its experimental phase, it signals the future of a digital workforce.”

“Additionally, a recent Deloitte survey shows that 26% of Australian companies are already testing these autonomous systems, reflecting an industry-wide shift from generative AI—which focuses on content creation—to systems that actively execute tasks. This trend underscores the growing need for standardized integration frameworks.”

“These developments collectively set the stage for our discussion on the UIM Protocol, which is designed to bridge the current gap between these powerful, autonomous agents and web services.”

22 of 24

THE PAST 3 MONTHS

IMPLICATIONS FOR THE UIM PROTOCOL

Standardized Communication Needs�Agentic AI’s autonomous decision-making calls for uniform, intent-based communication standards between AI agents and web services.

Enhanced Policy & Security Management�With agents acting independently, robust policy adherence tokens and compliance frameworks are critical to secure interactions.

Flexible Integration Architectures�UIM Protocol’s centralized, decentralized, and hybrid architecture options are designed to support diverse agentic AI deployments.

Real-World Business Impact

Autonomous agents promise major efficiency gains, reduced integration complexity, and new revenue streams
Simultaneously, they pose challenges around interoperability, cybersecurity, and legal risks.

“These recent agentic AI innovations emphasize why a standardized framework is essential. As agents transition from merely generating content to autonomously executing tasks, there’s a clear need for a uniform language that allows AI agents and web services to communicate effectively.”

“Our UIM Protocol addresses these challenges by integrating standardized intent definitions, policy adherence tokens, and automated discovery mechanisms that ensure secure, compliant interactions.”

“The protocol’s flexibility—with centralized, decentralized, and hybrid deployment options—aligns perfectly with the dynamic and varied nature of agentic AI systems emerging in the market.”

“From a business perspective, the adoption of autonomous agents is set to drastically reduce integration costs and maintenance burdens, while driving new efficiency gains. However, these benefits come with challenges such as ensuring cybersecurity and managing legal risks. The UIM Protocol is designed to mitigate these issues, offering a future-proof solution in this rapidly evolving landscape.”

23 of 24

A COMPARATIVE OVERVIEW

OPERATOR VS. UIM PROTOCOL

UIM Protocol (Standardized Intent-Based Communication)

Developers:

Requires implementation of standard interfaces and structured “intents” for communication.
Provides robust, scalable, and error-resilient integration across multiple services.

Web Services:

Offers a secure, machine-readable format with built-in policy and compliance mechanisms.
Involves some initial development effort for adoption but ensures long-term stability and consistency.

End Users:

Delivers more reliable, secure, and consistent interactions between AI agents and web services.
Results in a more dependable and seamless AI-driven service experience.

OpenAI’s Operator (Browser-Controlling Agent):

Developers:

Rapid deployment without backend changes by mimicking human UI interactions.
Fragile and slow, requiring human interventions.
Occasional hallucinations or misinterpretation of commands

Web Services:

Operates without requiring dedicated APIs.
Relies on scraping or UI simulation, which can lead to inconsistent data retrieval and security vulnerabilities.

End Users:

Capable of automating everyday tasks (e.g., booking travel, filling forms) with minimal manual input.
Performance can be hit-or-miss; users may encounter errors or slower responses

Introduction:�“Let’s compare two distinct approaches for enabling AI to interact with web services. On one side, we have OpenAI’s Operator—a browser-controlling agent that automates tasks directly via the user interface.”

Developers’ Perspective on Operator:�“For developers, Operator is appealing because it can be implemented quickly without modifying the backend. However, its method of simulating human actions—typing, clicking, and scrolling—makes it inherently fragile and slower than using direct API requests. Even a minor change in a webpage’s layout can disrupt its functionality, leading to significant maintenance challenges.”��Web Services Perspective on Operator:�“From the web service side, Operator works right out-of-the-box since it doesn’t require additional API integration. But there’s a trade-off: because it scrapes and simulates user interactions, data capture can be inconsistent, and it may introduce security issues, especially since it doesn’t adhere to a standardized protocol.”��End Users’ Experience with Operator:�“For end users, while Operator can handle everyday tasks—like booking travel or ordering groceries—it often delivers a hit-or-miss experience. If the underlying webpage changes, you might see errors or slower performance, making the overall experience less reliable.”

Contrast with UIM Protocol:�“In contrast, the UIM Protocol provides a standardized, intent-based communication framework. Developers get a clear and structured way to define and exchange intents with web services. Although this requires an upfront investment, the benefit is a system that is far more robust, secure, and maintainable.”�“Web services, when adopting the UIM Protocol, expose their capabilities through well-defined interfaces enhanced by built-in security and compliance. This not only reduces errors but also improves data consistency.” “For end users, this translates into smoother, more secure interactions. Automated discovery and robust error handling make the overall AI-driven service much more dependable.”

Summary:�“To summarize, while Operator offers rapid deployment with minimal changes to existing systems, its reliance on UI simulation makes it fragile and inconsistent. The UIM Protocol, on the other hand, although requiring some initial integration effort, promises long-term stability, security, and scalability—a key argument in favor of standardizing how AI interacts with web services.”

24 of 24

A COMPARATIVE OVERVIEW

MODEL CONTEXT PROTOCOL

Anthropic’s Model Context Protocol (MCP):

Purpose: Standardizes how applications provide context to large language models (LLMs).

Key Features:

Works like a “USB-C port” for AI—enabling plug-and-play integration with data sources and tools.
Emphasizes a client-server architecture (hosts, clients, servers, and local/remote data sources).
Offers pre-built integrations, flexibility to switch LLM providers, and best practices for data security.

Target Use Cases:

Building agents and complex workflows on top of LLMs by providing consistent, rich contextual data.

Integration Focus:�MCP standardizes data context for LLMs; UIM standardizes action communication between AI agents and services.

Architectural Approach:�MCP uses a client-server model for connecting data sources; UIM provides architectural flexibility to match different deployment needs.

Security & Flexibility:�MCP emphasizes secure, plug-and-play integrations with switching capability across LLM vendors; UIM emphasizes built-in security and policy controls to ensure consistent and compliant interactions.

Stakeholder Impact:

Developers: �MCP offers rapid integration with various data sources, UIM requires upfront work but yields robust and maintainable service connections.
Web Services: �MCP lets services expose context-rich data; UIM offers secure, standardized interfaces to automate tasks reliably.
End Users: �MCP can enhance AI's contextual understanding, while UIM provides smoother, more reliable interactions with web services.

Introduction:�“Both Anthropic’s MCP and the UIM Protocol serve to standardize AI interactions, but they target different layers of the AI ecosystem.”

Anthropic’s MCP Overview:�“MCP is designed to provide a standardized way for applications to supply context to LLMs—think of it as a USB-C port for AI. Its client-server architecture connects various data sources and tools directly to an AI model, enabling seamless integration. This protocol is particularly valuable for building complex workflows and agents that require rich contextual information, and it emphasizes flexibility in switching between different LLM providers, along with robust data security measures.”

UIM Protocol Overview:�“In contrast, the UIM Protocol focuses on how AI agents communicate with web services using standardized ‘intents.’ It defines structured interfaces, complete with versioning and automated service discovery, to enable secure and scalable interactions. Its design incorporates built-in security measures such as Policy Adherence Tokens and flexible architectures that can adapt to different organizational needs—whether centralized, decentralized, or hybrid.”

Comparative Analysis:�“When comparing these two, note that MCP is all about providing context—ensuring that LLMs receive accurate, standardized data from a variety of sources. On the other hand, the UIM Protocol is about actions—ensuring that AI agents can reliably and securely trigger and manage tasks across web services.” “For developers, MCP offers rapid plug-and-play integration with rich data, whereas UIM requires some initial effort but results in a more robust and maintainable system for controlling actions.” “Web services benefit from MCP by exposing their data in a standardized format, while UIM allows them to securely expose their capabilities and manage policies. End users, ultimately, see these efforts translate into either enhanced AI understanding (via MCP) or smoother, more reliable service interactions (via UIM).”

Conclusion:�“In summary, while both protocols aim to standardize AI interactions, MCP is more data-context oriented, and UIM is focused on enabling secure, action-driven communication between AI agents and web services. Each offers unique benefits and challenges, and choosing between them depends on whether your focus is on enhancing contextual input for LLMs or on standardizing the execution of web services.”�

In fact the two can work together to form a comprehensive AI integration framework that I like to call The ‘Sense and Act’ Cycle:

“When we integrate these protocols, we enable a full ‘sense and act’ cycle. MCP provides the ‘sense’ part by feeding context-rich data to the AI. Then, UIM takes over for the ‘act’ part by converting high-level intents into standardized, secure commands that interact with web services.”
“For example, imagine an AI agent that needs to schedule a meeting: MCP could deliver up-to-date calendar data, while UIM ensures the meeting is booked correctly through the service’s API.”
By combining MCP and the UIM Protocol, an AI agent can first use MCP to understand the “intent landscape” of a web service—what actions are possible, under what conditions, and with what parameters. It then leverages UIM to perform those actions in a structured, error-resistant manner. This synergy ultimately leads to a more robust and context-aware system, benefiting developers, web services, and end users alike.