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
- 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.
- 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).
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.
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.
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.
Retention Diagnostic
"Why did NRR drop from 115% to 108% this quarter?"
get_relationships for NRR. Gets the dependency tree: Expansion MRR, Churned MRR, Contraction MRR, Health Score, Feature Adoption. generate_query for Churned MRR and Contraction MRR. Runs cohort analysis. Finds contraction concentrated in mid-market accounts. generate_query for Feature Adoption and DAU/MAU for the same mid-market cohort. Finds usage dropped 30% before contraction events. Board Deck Audit
"Verify every metric in our board deck against the GASP standard."
lookup_metric to get the canonical formula, then generate_query to get the governed SQL. Source Migration Impact
"We are migrating from Chargebee to Stripe. What breaks?"
validate_adapter to get the current field coverage. Identifies all fields sourced from Billing (the adapter's source category for Chargebee). get_data_requirements. Finds 26 metrics across 5 departments that use Billing-sourced fields. 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:
- 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. - Build your adapter to connect the standard to your warehouse. See the adapter guide.
- Build the twin to give agents the full context: definitions, relationships, data lineage and ownership. See the digital twin guide.
- 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.