Adding a new OASF extension to support Agent Spec deployment manifest

[paul-cayet]

Hi team,

I wanted to share with you a proposal that was discussed in last week's community meeting.

Problem Statement

Below we will use:

• Assistant developer = Person that will develop assistant, and publish agent records to the AGNTCY dir
• User = person that may want to use the agent (can be a developer as well)

Currently developers can use the AGNTCY Dir to store metadata for agents, including some data about how a user could connect to the given agent e.g., using the A2A extension to inform about an existing agent endpoint where the model is hosted.

But what if the agent is not currently hosted anywhere but the user still want to try the assistant (e.g. spin up a simple agent server to have their team to try the assistant)? Previously, developers could use the ACP deployment extension in OASF records, today developers can use the Agent Spec extension to provide an agent blueprint (also called Agent Spec configuration). But this information is incomplete:

• Is there a preferred agent protocol to serve my agent? (e.g. A2A, OpenAI Responses API, other?)
• What are the required environment variables to run the agent?
• Future: Can I swap parts of the assistant to include my own components/tools/...

→ We would be interested in introducing a new component to be able to provide this information.

Proposal

We would be interested in adding a new Agent Spec Deployment Manifest extension to OASF to enable assistant developers to provide and store information about how an agent can be instantiated or consumed (including what are the preferred runtime framework / serving protocol and required environment variables to run the agent).

{ 
  "name": "ManagerWorkersAgent", 
  "version": "1.0.0", 
  "schema_version": "0.3.1", 
  "description": "ManagerWorkers Agent that can do ...", 
  "authors": [...], 
  "locators": [...], 
  "skills": [...], 
  "extensions": [ 
// ↓ below is the new Agent Spec Deployment Manifest data ↓ 
    { 
        "name": "schema.oasf.agntcy.org/features/runtime/manifest", 
        "version": "v1.0.0", 
        "data": { 
            "agent_data": { 
                "config": "path/to/partial_managerworkers_agentspec_config.json", 
                "runtime_deps": [...] 
            }, 
            "deployment_options": [ 
                { 
                    "name": "wayflow_with_a2a", 
                    "protocol": {"protocol_type": "a2a",  "url": "url/to/agent"}, 
                    "framework": "wayflowcore@25.4.1" 
                } 
            ], 
            "env_vars": [{"name": "openai api key", "value": "OPENAI_API_KEY"}] 
        } 
    } 
// ↑ end of the Agent Spec Deployment Manifest data ↑ 
  ] 
} 

This OASF Record can then be stored in a metadata store (e.g. AGNTCY Agent Directory Service). When required, the record can be fetched.

• For the OASF/ADS perspective, this expands the possible uses by enabling developers to instantiate agents from a stored agent metadata (either local or remote when using ADS).
• From our side, having this self-contained agent+serving information would make it extra easy for users to try agents e.g., locally it would be as easy as running a command wayflow serve --oasf_manifest=manifest.json -e env_vars.yaml (note: WayFlow is the reference runtime for Agent Spec).

References

• OASF Agent Spec extension: https://schema.oasf.outshift.com/0.8.0/modules/agentspec
• Agent Spec: https://github.com/oracle/agent-spec
• WayFlow: https://github.com/oracle/wayflow

Thank you for reading this, please tell me if you have any questions!

[muscariello]

@paul-cayet thanks for the proposal. It looks interesting and I'd like to test it. I would propose to turn this discussion post into an epic and add it to the OASF roadmap plan online.

[lgecse]

Epic created: #352