You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
> 🚧 Please note that the [Agents](../interfaces/Document#agent) concept is still in development.
9
+
> 🚧 Please note that the [Agents](../interfaces/Document#agent) concept is still in development and contains <spanclassName="feature-status-beta">BETA</span> properties and will get further extended.
10
10
11
11
## Agents
12
12
13
-
ORD defines a generic **Agent** resource type that can model any autonomous software entity capable of task execution. While this resource type is designed to be flexible enough to describe various types of agents, it primarily aims to model **AI Agents**- intelligent agents distinguished by their integration with Large Language Models (LLMs).
13
+
> An [Agent](../interfaces/Document#agent) is an **autonomous software entity** capable of task execution, described through high quality **metadata**that can be accessed through a central catalog ([ORD Aggregator](../#ord-aggregator)).
14
14
15
-
AI agents can interpret natural language, reason about complex scenarios, and operate in conversational mode for human interaction or be system-triggered for automated workflows. They represent the most common and significant use case for the Agent resource type in ORD.
15
+
To understand how Agents fit into the ORD landscape, it is helpful to distinguish between their abstract definition and their technical realization.
16
16
17
-
## Relevant API Protocols
17
+
In ORD, an **Agent** is primarily a conceptual, "product-like" entity, similar to a [Data Product](./data-product.md).
18
+
It represents a distinct capability or functional unit that can be discovered, understood, and managed independent of its specific deployment or invocation mechanism.
18
19
19
-
### A2A (Agent-to-Agent) Protocol
20
+
### Key Characteristics
20
21
21
-
The [Agent2Agent (A2A) Protocol](https://a2a-protocol.org/latest/) is an open standard that enables seamless communication and collaboration between AI agents. Originally developed by Google and donated to the Linux Foundation, A2A provides a common language for agent interoperability through standardized agent card definitions and interfaces.
22
+
-**Generic vs. AI Agents:** ORD defines a generic Agent resource type representing any autonomous software entity capable of task execution.
23
+
An Agent in ORD is not necessarily an AI Agent; the concept is broad enough to cover rule-based automation, legacy bots, and other autonomous systems.
24
+
-**Primary Use Case:** The design focus is currently on **AI Agents**—intelligent systems often integrated with Large Language Models (LLMs) that can interpret natural language, reason about complex scenarios, and operate in conversational mode or automated workflows.
25
+
-**Metadata Focus:** The Agent resource focuses on high-level metadata: ownership, intended use cases (e.g., "Financial Dispute Resolution"), constraints, and capabilities.
26
+
-**Separation of Concerns:** A key design principle is the clear separation between agent planning or existence and API exposure / implementation.
27
+
This allows modeling agents that are currently planned, or exist and act within a system but may not expose an external API.
22
28
23
-
### MCP (Model Context Protocol)
29
+
### Technical Realization
24
30
25
-
The [Model Context Protocol (MCP)](https://modelcontextprotocol.io/docs/getting-started/intro) is an open-source standard for connecting AI applications to external systems. MCP enables AI applications to connect to data sources, tools, and workflows, allowing them to access information and perform tasks beyond their core capabilities.
31
+
From a technical perspective, an Agent is simply a specialized type of application logic running within a **[System](../index.md#system-instance)**.
26
32
27
-
## Architecture Overview
28
-
29
-
### Model
33
+
-**Deployment:** An Agent is deployed as a [system](../index.md#system-instance), or as part of a system.
34
+
A single system can host one or multiple agents.
35
+
-**Instantiation:** While the "Agent Resource" describes the *type* or *class* of the agent (Design Time), the running software represents an *instance* of that agent (Runtime).
36
+
-*See [System Landscape Model](./system-landscape-model.md) for more on the distinction between Systems, Tenants, and Resources.*
Agents are implemented as a dedicated ORD resource type that can model various autonomous software entities. When used for AI agents, they uniquely combine intelligent capabilities with system integration, exposing functionality through conversational interfaces while maintaining optional relationships to traditional API Resources. A key principle is the separation between agent existence as a resource and API exposure, allowing agents to be described and discovered even when they don't expose external APIs directly.
40
+
## Agent Example
41
+
42
+
The following example shows how an Agent is described in an ORD Document:
43
+
44
+
```json5
45
+
{
46
+
"agents": [
47
+
{
48
+
"ordId":"sap.foo:agent:disputeAgent:v1",
49
+
"title":"Dispute Resolution Agent",
50
+
"shortDescription":"AI agent specialized in financial dispute case resolution",
51
+
"description":"A longer description of this Agent with **markdown**...",
-**`ordId`**: A globally unique identifier for the agent
90
+
-**`exposedApiResources`**: Links to the API(s) through which the agent can be invoked (e.g., an A2A API)
91
+
-**`integrationDependencies`**: Declares what external resources the agent requires to function
92
+
-**`relatedEntityTypes`**: Documents which domain bjebusiness entities the agent operates on
93
+
-**`labels`**: Extensible key-value pairs for additional metadata like LLM models used
94
+
95
+
## Connectivity & Protocols
96
+
97
+
The ORD Agent resource acts as a central hub that connects to other ORD concepts to define how to interact with it and what it needs to function.
98
+
99
+
ORD supports the discovery of **AI-Native Protocols**.
100
+
These are API protocols specifically designed for simple consumption by LLMs and AI Agents, well-supported by the emerging AI ecosystem, and optimized for this use case.
Dep -.->|Generic| Other["Other Resources (APIs, Events, etc.)"]
120
+
```
121
+
122
+
### Exposing Capabilities (Interaction)
123
+
124
+
Once an agent is implemented, there must be a defined contract for interacting with it.
125
+
In ORD, this is modeled by linking the Agent to an **[API Resource](../interfaces/Document#api-resource)**.
126
+
127
+
-**A2A (Agent-to-Agent):** While ORD is protocol-agnostic, the [Agent2Agent (A2A) Protocol](https://a2a-protocol.org/latest/) is the primary AI-Native Protocol for this purpose.
128
+
It enables seamless communication and collaboration between AI agents through standardized agent card definitions.
129
+
-**Discovery:** This link allows consumers to find the technical interface (e.g., the A2A JSON schema or OpenAPI spec) required to send messages to the agent.
130
+
131
+
Here's an example of an A2A API Resource linked to an agent:
The `resourceDefinitions` with type `a2a-agent-card` points to the full A2A Agent Card, which contains detailed capability information like skills, input/output modes, and security schemes.
160
+
161
+
### Consuming Capabilities (Dependencies)
162
+
163
+
Agents rarely work in isolation.
164
+
They often need to access real-world data or invoke business functions.
165
+
This is modeled using **[Integration Dependencies](../interfaces/Document#integration-dependency)**.
166
+
167
+
-**MCP (Model Context Protocol):** A common pattern is for an Agent to depend on an [MCP Server](https://modelcontextprotocol.io/docs/getting-started/intro).
168
+
The Integration Dependency declares this requirement, allowing the runtime environment to provision the necessary connections to data sources and tools.
169
+
-**Other Resources:** Agents are not limited to AI-native protocols.
170
+
They can also depend on any other [ORD resource](../index.md#ord-resource), such as **[API Resources](../interfaces/Document#api-resource)** (REST, OData, GraphQL) or **[Event Resources](../interfaces/Document#event-resource)**, to interact with existing business systems.
171
+
-**Agent Chaining:** Agents can also have dependencies on other Agents, forming complex workflows.
172
+
173
+
Here's an example of an Integration Dependency for an agent:
Describing agents in ORD enables several key scenarios:
202
+
203
+
-**Dynamic Agent Discovery:** AI orchestrators can dynamically discover available agents in a system landscape to extend their capabilities.
204
+
-**Agent Catalogs:** Central catalogs can index and display agents, enabling users to find and understand available AI capabilities.
205
+
-**Landscape Planning:** Understand the agent landscape across systems, including which agents depend on which resources.
206
+
Supports static catalogs (what is offered) and dynamic landscapes (what is actually running and available).
207
+
-**Dependency Management:** Explicitly modeling what an agent requires (via Integration Dependencies) supports automatic provisioning and understanding of dependency relationships.
208
+
-**Code-Based Agent Discovery:** Developers building code-based agents can discover and consume other agents programmatically.
34
209
35
-
### Key Relationships
210
+
##Current Status
36
211
37
-
**Agent → API Resources:**
38
-
-`exposedApiResources` property links to A2A protocol APIs or other agent interfaces
39
-
- Optional relationship (agents can exist without external APIs)
212
+
The AI Agents concept in ORD is currently in **Beta status** and may undergo refinements based on community feedback.
40
213
41
-
**Agent → Integration Dependencies:**
42
-
-`integrationDependencies` property for external system requirements
43
-
- Models dependencies on LOB APIs, MCP Servers, and tools
214
+
### What's Included
44
215
45
-
**Agent → Entity Types:**
46
-
-`relatedEntityTypes` for business object relationships
- Relationships to API Resources via `exposedApiResources`
218
+
- Relationships to dependencies via `integrationDependencies`
219
+
- Links to related Entity Types via `relatedEntityTypes`
220
+
- Extensibility via `labels` and `tags` for evolving properties
47
221
48
-
## Current Status
222
+
### Extensibility Approach
223
+
224
+
Given the rapidly evolving AI ecosystem, ORD takes a conservative approach to adding new properties:
225
+
226
+
-**[Groups](./grouping-and-bundling.md#groups):** The recommended mechanism for adding taxonomy to agents.
227
+
Groups allow defining custom **Group Types** (e.g., "LLM Model", "Process Area") and assigning agents to specific groups.
228
+
This approach is more structured and governed than labels, supporting both global taxonomies and application-specific groupings.
229
+
For example, an agent could be assigned to an LLM model group like `sap.aicore:llmModel:sap.aicore:anthropic--claude-3.7-sonnet`.
230
+
-**Labels:** For simpler key-value metadata that is still being validated, labels can be used.
231
+
This allows for experimentation without committing to a stable schema.
232
+
-**Tags:** Free-form tags for folksonomy-style categorization (e.g., `["finance", "billing", "ai-agent"]`).
233
+
234
+
### Examples
49
235
50
-
The AI Agents concept in ORD is currently in **Beta status** and may undergo refinements based on community feedback. Example implementations are available in the ORD specification repository (see `examples/documents/document-agents.json` and `examples/definitions/DisputeResolutionAgentcard.json`).
236
+
Example implementations are available in the ORD specification repository:
237
+
-`examples/documents/document-agents.json` — Complete ORD document with agent definitions
238
+
-`examples/definitions/DisputeResolutionAgentcard.json` — A2A Agent Card example
0 commit comments