# Open Operating Spec Execution Provider Extension

Updated 12 October 2026. Core draft v0.3.1 remains the current Operating Specification draft. The optional execution-provider.v1alpha1 extension makes execution portability part of the open ecosystem while preserving Signal → COR → Decision → Governance → Execution → Outcome + Evidence.

## Four execution binding protocols

| Binding | execution_protocol | Meaning |
| --- | --- | --- |
| Aegora Native | aegora_native | Default execution through Aegora Runtime |
| A2A | a2a | Eligible autonomous agent exposing A2A |
| Native vendor adapter/API | vendor_api | Approved proprietary invocation interface |
| MCP | mcp | Tool capability, including optional long-running Tasks |

Native remains the default for unconfigured paths. A2A is preferred when an external agent supports it, never mandatory. Tenant policy, exact versions, residency and control coverage determine eligibility. Explicit binding choices are honored or rejected. An invocation failure never causes an automatic protocol or provider switch.

Execution mode is separate: native and delegated are implemented in the current Runtime; compiled is an SDK contract for future implementation. Long-running MCP tools remain tools; task lifecycle support does not grant agent semantics or decision authority.

## Portable extension and tenant bindings

The portable Operating Spec may carry the following top-level extension fragment:

```json
{
  "x-execution-provider": {
    "schema_version": "execution-provider.v1alpha1",
    "capability_contract_refs": ["capability.example@1.0.0"],
    "execution_policy_ref": "policy.example.execution@1.0.0"
  }
}
```

The references are illustrative; author and resolve real versioned contracts before release. Tenant deployment settings separately hold bindings, routes, installed provider manifests and connections. Each binding identifies the actual execution protocol, capability kind, provider and adapter release, implementation reference, input/output contracts, authentication profile, environment, timeout and retry policy. Tenant endpoints and secret references must not be embedded in portable specs.

The extension and binding schemas are provided in the downloadable addendum. Core v0.3.1 permits `x-` extensions; validating the core alone does not validate this extension's content. Validate execution-provider.v1alpha1 against its dedicated schemas and runtime compatibility rules as well. This addendum is an opt-in draft extension, not a newly ratified core standard or certification.

## Implemented product scopes

Installed transports cover A2A, Microsoft Foundry, ServiceNow Virtual Agent, Salesforce Agentforce, AWS AgentCore with JWT inbound authorization, Google Agent Engine custom query and MCP Streamable HTTP. Product scopes are deliberately explicit. Microsoft provides response polling/cancellation; ServiceNow requires authenticated callback routing; Salesforce uses its synchronous message interface. AWS and Google require the reviewed application result envelope. AWS IAM/SigV4 and classic Bedrock Agents, Google ADK streaming and asynchronous query jobs require separate adapters.

MCP 2026-07-28 and 2025-11-25 are separate pinned adapter generations. Modern optional Tasks support includes lifecycle reconciliation and final-result inspection; task completion with a tool error is not successful execution. Advertised status and cancellation operations determine which lifecycle operations may be invoked.

Configure settings through the dedicated Execution Provider Studio. The Aegora problem-to-path plugin can prepare and validate tenant settings alongside Operating Path drafts. Draft submission does not activate or execute a path; tenant review and activation remain distinct steps.

## Governance and acceptance

Each effect requires authoritative COR context, an explicit decision and governance resolution, including human approval where required. Temporal orchestrates durable execution and activities perform effects. The journal preserves tenant, path/spec, COR, decision, governance/approval, provider release, execution and external IDs, and evidence references. Duplicate requests do not repeat effects; unknown results require reconciliation and human fallback. Provider completion is not proof of the business outcome.

Local unit, contract, workflow and persistence tests establish bounded implementation behavior. Production deployment, live provider credentials, callback routing and tenant-specific end-to-end acceptance remain separate delivery gates. No adapter listing constitutes use-case completion or certification.

## Partner ecosystem

Execution adapters, spec compilers and deployment providers are independent open contribution interfaces. The intended Marketplace model will allow partners to publish certified provider packages. Certification, trust/revocation, publication, installation and tenant execution permission are distinct controls. Provider Marketplace publishing, partner certification verification, compilers and deployment providers remain future capabilities; certification never grants tenant authority.