A small contract.
A checkable result.

01 / One action, three operations.

A profile points to a submission operation, an authoritative request-status operation, and a resource read. The first binding supports one POST and two GET operations from an OpenAPI 3.1 document.

Agentic builds on existing techniques. Its proposed contribution is a consistent, testable set of rules that multiple clients can implement. It is not a new transport, a permission grant, or an exactly-once guarantee.

02 / The file.

Publish agentic.json or provide its URL directly to a supporting client. Use ordinary JSON and the versioned schema. Agents do not automatically discover or support this filename.

{
  "$schema": "https://ruagentic.org/schemas/agentic-0.1.schema.json",
  "agentic": "0.1.0-draft",
  "origin": "https://support.example",
  "actions": [
    {
      "id": "create-ticket",
      "description": "Create a support ticket and verify the original result.",
      "openapi": "/openapi.json",
      "submit": "createTicket",
      "status": "getRequestStatus",
      "verify": "getTicket",
      "request": {
        "header": "Idempotency-Key",
        "scope": "principal-action",
        "retentionSeconds": 86400
      },
      "bindings": {
        "statusRequestId": "requestId",
        "verifyResourceId": "ticketId"
      },
      "evidence": {
        "resourceIdPointer": "/id",
        "requestIdPointer": "/request_id",
        "statePointer": "/status",
        "successValues": [
          "open",
          "closed"
        ],
        "inputBindings": [
          {
            "inputPointer": "/subject",
            "resourcePointer": "/subject"
          }
        ]
      },
      "recovery": {
        "maxChecks": 3,
        "checkDelayMs": 100,
        "timeoutMs": 3000,
        "retry": "never-automatically"
      }
    }
  ]
}

Check this example in the validator →

03 / The action lifecycle.

1. Authorize the requested action using the host’s existing policy.
2. Save the request ID and bind it to the origin, action, input, and profile snapshot before sending.
3. Submit once. A lost response leaves the outcome unknown.
4. Look up the original request. Use its resource ID to read the resulting record.
5. Verify the resource ID, request ID, state, and required input evidence.
6. Save a receipt. Preserve pending or unknown when completion cannot be verified.

After restart, the saved request is reconciled without automatically submitting another write. Expired tracking requires a handoff.

04 / Keep the evidence.

A receipt records the request, action, origin, outcome, observation time, and resulting resource. Successful receipts include the evidence source and checks performed.

Receipts belong in the authorized client’s storage. They can contain sensitive information and do not belong in the public manifest. A receipt records an observation; it is not a signature or a guarantee that the service is honest.

05 / Explicit boundaries.

The service must actually implement atomic request tracking and deduplication. The client must enforce authorization, approved destinations, account isolation, timeouts, and response limits. The file cannot provide those controls on its own.

This draft supports a narrow same-origin OpenAPI binding. General workflow programming, cross-origin execution, payments, identity, and automatic mutation retries are outside its scope.

Operational limits · Relationship to existing work

06 / A proposal to test.

The repository includes Node and Python reference clients, a loopback HTTP/SQLite service, and failure tests. Both clients share project authorship. Independent implementation and production adoption remain open goals.

This page is a reading guide. The normative draft and versioned schemas define the actual requirements.