GASP

Agentic SaaS Operations

Ask two agents for Net Revenue Retention (NRR) and each will give a fluent answer from whatever definition it picked up. When both read the GASP Standard, they use the same definitions, trace the same relationships and reference the same data sources, so their answers can be compared and checked.

The Multi-Agent Consistency Problem

Without a standard
  • Agent A computes NRR from a billing system export using a formula it inferred from context. Returns 108%.
  • Agent B computes NRR from a CRM rollup table using a different formula. Returns 112%.
  • Coordinator agent receives two conflicting numbers. Has no way to determine which is correct, which definition was used or which data source is authoritative.
  • Result Someone has to rebuild both calculations by hand before either number can go in front of anyone.
With GASP
  • Every agent reads the same canonical NRR definition from the GASP twin, so they all run one formula against the data source the adapter maps.
  • Coordinator agent can verify that each specialist used the governed definition and trace the answer back to specific warehouse columns.
  • When answers differ the coordinator knows the difference is in the data, which narrows the search to the tables and columns the adapter names.
  • Result The coordinator reports one NRR figure and can show the definition and columns behind it.

How Agents Use the Twin

The GASP digital twin gives agents three things they cannot get from raw warehouse access: a vocabulary (canonical definitions), a map (the relationship graph) and a directory (the adapter mapping).

Vocabulary

What does this metric mean?

An agent asked to analyse NRR calls lookup_metric and gets the canonical definition, the canonical formula in the GASP grammar, the Operating and Market forms, the Adjusted variant, the declared breakdowns, benchmarks, signal type, sensitivity tier and access scope. It works from that definition instead of one guessed from training data.

Map

What drives this metric?

The agent calls get_relationships and gets the upstream dependency chain: NRR is computed from Monthly Recurring Revenue (MRR), Expansion MRR, Contraction MRR and Churned MRR. Each of those traces to specific entities (Customer, Subscription) and data fields. The agent follows those edges to find a root cause.

Directory

Where is the data?

The agent calls generate_query with the metric name and the team's adapter mapping. It gets SQL in the dialect of the adapter's warehouse (Postgres, Snowflake, BigQuery or Databricks) that references the exact schema.table.column paths for this business.

Multi-Agent Patterns

Three worked examples of a coordinator agent handing work to specialists that all read the GASP twin. None of them depends on how the agents talk to each other, whether that is A2A, OSSA, MCP tool calls or direct API invocations.

Pattern 1

Retention Diagnostic

"Why did NRR drop from 115% to 108% this quarter?"

1
Coordinator receives the question and calls infer_drivers for NRR. The formula components come back first (MRR, Expansion MRR, Contraction MRR and Churned MRR). MRR is only the starting baseline, so the walk stops at it. Behind the three movements come Logo Churn Rate, Customer Health Score, QBR Completion Rate, Product Qualified Accounts and Net Promoter Score (NPS).
2
Coordinator spins up a Retention Specialist and a Product Engagement Specialist. Both read from the same twin.
3
Retention Specialist calls generate_query for Churned MRR and Contraction MRR with the by_segment breakdown, one row per customer segment. Finds contraction concentrated in mid-market accounts.
4
Product Engagement Specialist calls generate_query for Customer Health Score with the by_segment breakdown and for DAU/MAU Ratio, then narrows the usage query to the mid-market accounts itself. Finds usage dropped 30% before contraction events.
5
Coordinator synthesises: "NRR dropped because mid-market contraction increased. Product usage in this segment declined 30% in the 90 days before contraction events. Customer Health Score is the leading indicator." Both specialists used the same NRR definition, the same adapter and the same relationship graph.
Pattern 2

Board Deck Audit

"Verify every metric in our board deck against the GASP Standard."

1
Coordinator extracts metric names from the board deck (ARR, NRR, GRR, CAC Payback, LTV:CAC, Rule of 40, Gross Margin).
2
For each metric the coordinator calls lookup_metric to get the canonical formula, then generate_query to get the governed SQL.
3
Coordinator compares the deck's stated values against the governed SQL output and flags deviations. It then calls validate_adapter, whose report lists the covered metrics with no owner declared, and names each owner from the adapter's metricOwners.
4
Output "6 of 7 board metrics match the GASP Standard. The deck computes Gross Revenue Retention (GRR) per customer (the cohort method), which reads equal to or higher than the canonical formula method. GRR has no owner declared in the adapter; add one."
Pattern 3

Source Migration Impact

"We are migrating from Chargebee to Stripe. What breaks?"

1
Coordinator calls validate_adapter to get the metrics the current adapter fully covers and the field and dataset pairs each partially covered metric still misses.
2
For each covered metric the coordinator calls get_data_requirements to list the field and dataset pairs its formula reads and the metric's source system, keeping the metrics sourced from Billing. For an adapter like the Acme example, all of its fully covered metrics come from Billing.
3
Coordinator generates a migration checklist: field-by-field mapping from Chargebee schema to Stripe schema, grouped by metric impact. Each metric carries the owner declared in the adapter's metricOwners.
4
Output "Every fully covered metric reads Billing fields, so each needs its mapping checked against the Stripe schema. Highest priority: mrr, mrr_change and customer_id, the fields NRR reads (owner: Finance). Definitions and formulas stay as they are and only the adapter needs updating."

Implementation Examples

Here is how a retention analyst like the one in Pattern 1 would be defined using two emerging agent interoperability standards: A2A (Agent-to-Agent protocol, a Linux Foundation project) for inter-agent communication and OSSA (Open Standard Agents) for portable agent definitions.

A2A: Agent Card

In A2A each agent publishes a discoverable Agent Card that describes its skills. A GASP retention analyst would advertise its capabilities like this: 

// Published at https://agents.acme.com/.well-known/agent-card.json
{
  "name": "GASP Retention Analyst",
  "description": "Diagnoses retention trends using the GASP Standard knowledge graph. Traces NRR, GRR, churn and expansion through upstream drivers to root causes.",
  "version": "1.0.0",
  "provider": {
    "organization": "Acme SaaS",
    "url": "https://acme.com"
  },
  "capabilities": {
    "streaming": true,
    "pushNotifications": false
  },
  "defaultInputModes": ["text/plain", "application/json"],
  "defaultOutputModes": ["text/plain", "application/json"],
  "skills": [
    {
      "id": "nrr_diagnostic",
      "name": "NRR Diagnostic",
      "description": "Trace an NRR change to its root cause using the GASP relationship graph and adapter mapping.",
      "tags": ["retention", "nrr", "churn", "gasp"],
      "examples": [
        "Why did NRR drop from 115% to 108% this quarter?",
        "Which cohort is driving the contraction increase?"
      ]
    },
    {
      "id": "churn_cohort_analysis",
      "name": "Churn Cohort Analysis",
      "description": "Segment churned customers by acquisition cohort and correlate with product usage metrics.",
      "tags": ["churn", "cohort", "product-usage", "gasp"],
      "examples": [
        "Compare churn rates across Q1 and Q2 acquisition cohorts"
      ]
    },
    {
      "id": "revenue_quality",
      "name": "Revenue Quality Assessment",
      "description": "Compute Adjusted NRR using CEL change_nature to separate permanent movements from temporary ones.",
      "tags": ["nrr", "revenue-quality", "change-nature", "gasp"],
      "examples": [
        "What is our Adjusted NRR excluding temporary upgrades?"
      ]
    }
  ],
  "supportedInterfaces": [
    {
      "url": "https://agents.acme.com/retention",
      "protocolBinding": "JSONRPC",
      "protocolVersion": "1.0"
    }
  ]
}

A2A: Sending a Task

A coordinator agent sends a diagnostic request to the retention analyst using A2A's JSON-RPC protocol: 

// Coordinator → Retention Analyst (POST https://agents.acme.com/retention)
{
  "jsonrpc": "2.0",
  "id": "req-001",
  "method": "SendMessage",
  "params": {
    "message": {
      "messageId": "msg-coord-001",
      "role": "ROLE_USER",
      "parts": [
        {
          "text": "NRR dropped from 115% to 108% in Q1. Diagnose the root cause. Use the GASP relationship graph to trace upstream drivers and generate SQL from the adapter."
        }
      ]
    },
    "configuration": {
      "acceptedOutputModes": ["application/json"],
      "returnImmediately": false
    }
  }
}

// Response
{
  "jsonrpc": "2.0",
  "id": "req-001",
  "result": {
    "task": {
      "id": "task-ret-001",
      "contextId": "ctx-ret-001",
      "status": { "state": "TASK_STATE_COMPLETED" },
      "artifacts": [
        {
          "artifactId": "art-nrr-001",
          "name": "nrr_diagnostic",
          "parts": [{
            "data": {
              "finding": "Contraction concentrated in mid-market segment",
              "driver": "Usage (DAU/MAU) dropped 30% in the 90 days before contraction",
              "metrics_traced": ["nrr", "contraction_mrr", "churned_mrr", "health_score"],
              "metric_owner": "Finance",
              "sql_generated": true,
              "adapter_fields_used": ["customer_id", "mrr_start", "mrr_end", "usage_count"]
            },
            "mediaType": "application/json"
          }]
        }
      ]
    }
  }
}

OSSA: Agent Manifest

OSSA defines a portable agent manifest that describes what an agent is, what tools it uses and what governance constraints apply. A GASP-powered retention analyst would be defined like this: 

# gasp-retention-analyst.ossa.yaml
apiVersion: ossa/v0.5.6
kind: Agent
metadata:
  name: gasp-retention-analyst
  version: 1.0.0
  agentKind: analyst
  description: >
    Diagnoses retention trends using the GASP Standard knowledge
    graph. Traces NRR through upstream drivers to root causes
    and generates warehouse-specific SQL via the adapter.
  labels:
    domain: saas-metrics
    team: finance
  identity:
    namespace: acme/analytics
    agent_id: retention-analyst-v1
    publisher:
      name: Acme SaaS
      email: [email protected]

spec:
  role: |
    You are a SaaS retention analyst. You use the GASP Standard
    to diagnose retention trends. Always trace metrics through
    the relationship graph before generating SQL. Reference
    canonical definitions, not inferred ones.
  llm:
    provider: anthropic
    model: claude-sonnet-5-5
    temperature: 0.2
    max_tokens: 8192
  tools:
    - type: mcp
      name: gasp-standard
      description: GASP Standard metrics, relationships, formulas

protocols:
  mcp:
    version: "1.0.0"
    role: client
    servers:
      - name: gasp-standard
        transport: stdio
        command: npx
        args: ["-y", "gasp-standard-mcp"]
        tools: [lookup_metric, get_formula, infer_drivers, explain_path, generate_query]
    capabilities:
      tools: true
      resources: false
  a2a:
    version: "1.0.0"
    endpoint: https://agents.acme.com/retention
    agent_card:
      name: GASP Retention Analyst
      description: NRR diagnostics powered by the GASP Standard
      skills:
        - id: nrr_diagnostic
          name: NRR Diagnostic
          tags: [retention, nrr, churn, gasp]
        - id: churn_cohort_analysis
          name: Churn Cohort Analysis
          tags: [churn, cohort, gasp]
        - id: revenue_quality
          name: Revenue Quality Assessment
          tags: [nrr, revenue-quality, gasp]
    capabilities:
      streaming: true

security:
  tier: tier_1_read
  data_classification: internal
  capabilities:
    required:
      - network-outbound   # call the MCP server
      - database-read      # read-only warehouse access
  audit:
    log_tool_calls: true
    retention_days: 90

governance:
  compliance:
    frameworks: [SOC2]
    audit_logging_required: true
  authorization:
    tool_permissions:
      - tool: generate_query
        risk_level: low
        requires_approval: false
      - tool: validate_adapter
        risk_level: low
        requires_approval: false

Why GASP makes these protocols useful

A2A and OSSA handle agent discovery, communication and governance. What goes inside the messages is left to the agents, so two agents can exchange well-formed messages and still mean different things by NRR. The GASP twin supplies that content: one canonical model of metrics, relationships and data sources that every agent references, whichever protocol carries the messages.

Why the Standard Matters for Agents

Auditability

Every agent answer traces back to a canonical definition, a structured formula, a sensitivity tier and a specific warehouse column. When an agent says "NRR is 108%" you can verify the definition it used, the SQL it ran and the data it read.

Consistency

Ten agents running simultaneously all reference the same twin. The retention agent and the pipeline agent produce compatible numbers because they share the same definitions and the same adapter mapping.

Composability

You can start a specialist for one task and shut it down afterwards, because the model it worked from lives in the twin rather than in the agent. The next agent picks up the full context by reading the twin again.

Protocol Independence

The GASP twin works with A2A, OSSA, MCP tool calls, direct API invocations or whatever comes next, since swapping the transport leaves the model the agents read untouched.

Getting Started

Four steps get you to governed agents:

  1. Install the MCP server to give your agents 23 tools over the GASP Standard: definition lookups, formula decomposition, root-cause traversal (infer_drivers), path explanation, coverage audits and warehouse SQL generation. One command.
  2. Build your adapter to connect the standard to your warehouse. See the adapter guide.
  3. Build the twin to give agents the full context: definitions, relationships, data lineage and ownership. See the digital twin guide.
  4. Scope user and agent permissions so each caller sees only what they should. See the governance framework.

Your agents sit on top of what those steps build. A single Claude Code session and a fleet of orchestrated specialists read the same twin, so they work from the same definitions.

Try searching for:

↑↓navigate↵select