GASP

Agentic SaaS Operations

AI agents are only as good as the model they read from. Without a governed metric layer, agents produce fluent answers from inconsistent definitions. The GASP Standard provides the canonical model that makes multi-agent SaaS operations reliable: every agent reads the same definitions, traces the same relationships and references the same data sources.

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 The agents are fluent but ungoverned. Confidence is high. Accuracy is unknown.
With GASP
  • Every agent reads the same canonical NRR definition from the GASP twin. One formula. One data source (via the adapter). One answer.
  • 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, not the definition. That is a diagnosable problem.
  • Result Agents are governed. Answers are auditable. Disagreements have root causes.

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 analyze NRR calls lookup_metric and gets the canonical definition, formula variants (cohort and formula method), benchmarks, signal type and the named owner. It does not infer a definition from context or training data.

Map

What drives this metric?

The agent calls get_relationships and gets the upstream dependency chain: NRR depends on Expansion MRR, Churned MRR and Contraction MRR. Each of those traces to specific entities (Customer, Subscription) and data fields. The agent can walk the graph to find root causes without guessing.

Directory

Where is the data?

The agent calls generate_query with the metric name and the team's adapter mapping. It gets warehouse-specific SQL that references the exact schema.table.column paths for this business. No table scanning. No schema guessing.

Multi-Agent Patterns

These patterns illustrate how a coordinator agent can orchestrate specialists against the GASP twin. The patterns are protocol-agnostic. They work whether agents communicate via A2A, OSSA, MCP tool calls or direct API invocations. The value is in the shared model, not the transport.

Pattern 1

Retention Diagnostic

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

1
Coordinator receives the question. Calls get_relationships for NRR. Gets the dependency tree: Expansion MRR, Churned MRR, Contraction MRR, Health Score, Feature Adoption.
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. Runs cohort analysis. Finds contraction concentrated in mid-market accounts.
4
Product Specialist calls generate_query for Feature Adoption and DAU/MAU for the same mid-market cohort. Finds usage dropped 30% before contraction events.
5
Coordinator synthesizes: "NRR dropped because mid-market contraction increased. Product usage in this segment declined 30% in the 90 days before contraction events. Feature Adoption 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. Flags deviations with the metric owner from the adapter.
4
Output "6 of 7 board metrics match the GASP standard. GRR is calculated using a simple formula; GASP recommends cohort method. Owner: Finance (jane@acme.com)."
Pattern 3

Source Migration Impact

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

1
Coordinator calls validate_adapter to get the current field coverage. Identifies all fields sourced from Billing (the adapter's source category for Chargebee).
2
For each affected field the coordinator traces which metrics depend on it using get_data_requirements. Finds 26 metrics across 5 departments that use Billing-sourced fields.
3
Coordinator generates a migration checklist: field-by-field mapping from Chargebee schema to Stripe schema, grouped by metric impact. Each field has a pipeline owner from the adapter.
4
Output "26 metrics affected. 18 fields need remapping. Highest priority: mrr, subscription_id, contract_start (owner: Data Engineering). Definitions and formulas are unchanged. Only the adapter needs updating."

Implementation Examples

The patterns above are protocol-agnostic. Below are concrete examples showing how GASP-powered agents would be defined using two emerging agent interoperability standards: A2A (Agent-to-Agent, by Google) 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": "0.3"
    }
  ]
}

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 /message:send)
{
  "jsonrpc": "2.0",
  "id": "req-001",
  "method": "SendMessage",
  "params": {
    "message": {
      "messageId": "msg-coord-001",
      "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"],
      "blocking": true
    }
  }
}

// Response
{
  "jsonrpc": "2.0",
  "id": "req-001",
  "result": {
    "id": "task-ret-001",
    "status": { "state": "completed" },
    "artifacts": [
      {
        "name": "nrr_diagnostic",
        "parts": [{
          "data": {
            "finding": "Contraction concentrated in mid-market segment",
            "driver": "Feature Adoption dropped 30% in 90 days before contraction",
            "metrics_traced": ["nrr", "contraction_mrr", "health_score", "feature_adoption"],
            "metric_owner": "Finance (jane@acme.com)",
            "sql_generated": true,
            "adapter_fields_used": ["account_id", "mrr_start", "mrr_end", "usage_score"]
          },
          "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.0
kind: Agent
metadata:
  name: gasp-retention-analyst
  version: 1.0.0
  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: data-team@acme.com

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-4-20250514
    temperature: 0.2
    profile: deep
  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"]
        capabilities:
          tools: true
          resources: false
  a2a:
    version: "0.3"
    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    # call MCP server
      - database   # 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
        access: read
      - tool: validate_adapter
        access: read

Why GASP makes these protocols useful

A2A and OSSA solve agent discovery, communication and governance. They do not solve what agents say to each other or whether their answers are consistent. That is what the GASP twin provides: a shared, canonical model of metrics, relationships and data sources that every agent references regardless of which protocol carries the messages. The protocols are the plumbing. The standard is the water.

Why the Standard Matters for Agents

Auditability

Every agent answer traces back to a canonical definition, a structured formula, a named owner 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. Consistency is structural, not coincidental.

Composability

Specialist agents can be created, composed and torn down on demand because the shared model is durable. The twin persists across agent lifecycles. A new agent inherits the full context instantly by reading the twin.

Protocol Independence

The GASP twin works with any agent communication protocol: A2A, OSSA, MCP tool calls, direct API invocations or protocols that have not been invented yet. The value is in the governed model, not the transport layer.

Getting Started

The fastest path to governed agents is three steps:

  1. Install the MCP server to give your agents 11 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.

The agents layer on top. Whether you start with a single Claude Code session or a fleet of orchestrated specialists, the twin ensures they all speak the same language.

Try searching for:

navigateselect