ObservaAgent — Collaborative AI Agents for Network Telemetry Fault Detection

Concept

Modern SRE teams are buried in telemetry noise. ObservaAgent is an API-first SaaS that applies a collaborative Agent + Critic pattern to network telemetry data to dramatically reduce Mean-Time-To-Resolution (MTTR).

Instead of a single AI model making fault judgments, ObservaAgent employs two cooperating agents:

Role	Responsibility
Detection Agent	Scans incoming metric streams for threshold violations, anomaly patterns (CPU spikes, latency surges, packet loss, error-rate elevation)
Critic Agent	Cross-validates agent findings, correlates related anomalies (e.g. CPU + memory co-occurrence), eliminates false positives, assigns confidence scores

The Critic's output determines the final severity (LOW → CRITICAL) and the structured root-cause narrative that SRE engineers act on.

---

Architecture

┌─────────────────────────────────────────────────────────────────────┐
│                           ObservaAgent API                          │
│                                                                     │
│  POST /v1/telemetry                                                 │
│       │                                                             │
│       ▼                                                             │
│  IngestionController ──► AnalysisService.createPendingReport()      │
│       │                          │ (synchronous, returns incidentId)│
│       │                          ▼                                  │
│       │               IncidentReportRepository.save()               │
│       │                                                             │
│       └──────────────► AnalysisService.processAsync()  ◄─────────┐ │
│                                │  (@Async / Virtual Thread)       │ │
│                                ▼                                  │ │
│                        ┌───────────────┐                          │ │
│                        │  Agent Phase  │ threshold scan            │ │
│                        └──────┬────────┘                          │ │
│                               ▼                                   │ │
│                        ┌───────────────┐                          │ │
│                        │ Critic Phase  │ correlation + confidence  │ │
│                        └──────┬────────┘                          │ │
│                               ▼                                   │ │
│                        ┌───────────────┐                          │ │
│                        │  Persistence  │ UPDATE incident report ──┘ │
│                        └───────────────┘                            │
│                                                                     │
│  GET  /v1/reports/{incidentId}  ◄── poll until status = RESOLVED   │
│  GET  /v1/reports               ◄── list all incidents for owner   │
│                                                                     │
│  POST /v1/api-keys              ◄── public (bootstrap)             │
│  GET  /v1/api-keys              ◄── list own keys (masked)         │
│  DELETE /v1/api-keys/{id}       ◄── revoke key                     │
└─────────────────────────────────────────────────────────────────────┘

Key Design Decisions

• Stateless JWT-free auth — every request carries an X-API-Key header validated

by ApiKeyAuthFilter against the database. Simple, auditable, revocable.

• Virtual Threads (Java 25) — the async executor in AsyncConfig uses

Thread.ofVirtual(), allowing thousands of concurrent analysis tasks at minimal heap cost compared to platform threads.

• Records for all DTOs — %%INLINE4%%, %%INLINE5%%, IngestionResponse,

%%INLINE7%%, %%INLINE8%% are all immutable Java Records, guaranteeing thread safety across the pipeline.

• JPA entities for persistence — %%INLINE9%% and %%INLINE10%% are standard

Jakarta Persistence entities stored in PostgreSQL.

• Constructor injection throughout — all Spring beans use constructor injection;

no @Autowired field injection.

Package Layout

com.forge.solutions.observaagentapi
├── config/
│   ├── AsyncConfig.java          — virtual-thread @Async executor + @EnableAsync
│   ├── JacksonConfig.java        — tools.jackson.* JsonMapper bean (pre-written)
│   └── SecurityConfig.java       — Spring Security 7 API-key filter chain
├── controller/
│   ├── ApiKeyController.java     — /v1/api-keys CRUD
│   ├── IngestionController.java  — POST /v1/telemetry
│   └── ReportController.java     — GET /v1/reports
├── dto/
│   ├── ApiKeyResponse.java       — Record
│   ├── CreateApiKeyRequest.java  — Record
│   ├── IngestionResponse.java    — Record
│   ├── MetricDataPoint.java      — Record (nested within TelemetryPayload)
│   ├── ReportResponse.java       — Record
│   └── TelemetryPayload.java     — Record
├── model/
│   ├── ApiKey.java               — JPA Entity
│   ├── IncidentReport.java       — JPA Entity
│   └── Severity.java             — Enum (LOW | MEDIUM | HIGH | CRITICAL)
├── repository/
│   ├── ApiKeyRepository.java     — Spring Data JPA
│   └── IncidentReportRepository.java
├── security/
│   └── ApiKeyAuthFilter.java     — OncePerRequestFilter for X-API-Key
└── service/
    ├── AnalysisService.java      — Agent + Critic pipeline (@Async)
    └── ApiKeyService.java        — Key generation & revocation

---

API Endpoints

API Key Management

POST /v1/api-keys — Create a new API key (public)

POST /v1/api-keys
Content-Type: application/json

{
  "ownerId": "acme-corp",
  "description": "Production SRE pipeline"
}

Response 201 Created:

{
  "id": "550e8400-e29b-41d4-a716-446655440000",
  "keyValue": "oa-abc123XYZ...",
  "ownerId": "acme-corp",
  "description": "Production SRE pipeline",
  "createdAt": "2026-04-07T10:00:00",
  "active": true
}

⚠️ keyValue is only shown once at creation time. Store it securely.

---

GET /v1/api-keys — List keys (requires X-API-Key)

GET /v1/api-keys
X-API-Key: oa-abc123XYZ...

Response 200 OK: (key values masked)

[
  {
    "id": "550e8400-...",
    "keyValue": "oa-abc123***",
    "ownerId": "acme-corp",
    "active": true
  }
]

---

DELETE /v1/api-keys/{id} — Revoke a key (requires X-API-Key)

DELETE /v1/api-keys/550e8400-e29b-41d4-a716-446655440000
X-API-Key: oa-abc123XYZ...

Response: 204 No Content

---

Telemetry Ingestion

POST /v1/telemetry — Ingest telemetry snapshot (requires X-API-Key)

POST /v1/telemetry
Content-Type: application/json
X-API-Key: oa-abc123XYZ...

{
  "resourceId": "node-prod-42",
  "serviceId": "payment-gateway",
  "environment": "production",
  "resourceType": "k8s.pod",
  "attributes": {
    "cluster": "us-east-1",
    "namespace": "payments"
  },
  "metrics": [
    { "name": "cpu.utilization",     "value": 94.5, "unit": "%",   "labels": {} },
    { "name": "memory.utilization",  "value": 88.2, "unit": "%",   "labels": {} },
    { "name": "http.request.latency","value": 1540,  "unit": "ms",  "labels": {} },
    { "name": "error_rate",          "value": 7.1,  "unit": "%",   "labels": {} }
  ],
  "collectedAt": "2026-04-07T10:00:00Z"
}

Response 202 Accepted:

{
  "incidentId": "INC-A3F2B1C0",
  "status": "PENDING",
  "message": "Telemetry accepted. Analysis pipeline started. Poll GET /v1/reports/INC-A3F2B1C0",
  "receivedAt": "2026-04-07T10:00:00.123Z"
}

---

Incident Reports

GET /v1/reports/{incidentId} — Get report (requires X-API-Key)

GET /v1/reports/INC-A3F2B1C0
X-API-Key: oa-abc123XYZ...

Response 200 OK (after analysis completes):

{
  "incidentId": "INC-A3F2B1C0",
  "serviceId": "payment-gateway",
  "environment": "production",
  "severity": "CRITICAL",
  "status": "RESOLVED",
  "affectedComponents": "payment-gateway, node-prod-42, k8s.pod, env:production",
  "rootCauseAnalysis": "Root Cause Analysis for Service: payment-gateway\n...",
  "agentFindings": "Agent Analysis — 4 anomalies detected...",
  "criticValidation": "Critic Validation:\n• Confirmed: Resource exhaustion pattern...",
  "detectedAt": "2026-04-07T10:00:00",
  "resolvedAt": "2026-04-07T10:00:01"
}

Lifecycle statuses: %%INLINE19%% → %%INLINE20%% (or FAILED)

---

GET /v1/reports — List all reports for the authenticated owner

GET /v1/reports
X-API-Key: oa-abc123XYZ...

Response 200 OK: Array of ReportResponse objects, newest first.

---

Business Analysis

Dimension	Assessment
Target Market	SRE / DevOps teams at companies with ≥$10M ARR and 24/7 uptime SLAs
Monetization	API-first SaaS — tiered by ingestion volume (events/month) + premium for advanced AI tiers
Moat	Agent + Critic reduces false-positive rate vs. threshold-only alerting; proprietary training data grows with usage
ROI Signal	1 hour of downtime for a mid-size e-commerce = $100K+ loss; MTTR reduction from 60 min → 10 min yields clear ROI
Competition	Datadog, Dynatrace (expensive, monolithic), PagerDuty (alerting only, no root cause) — ObservaAgent is lightweight & API-native
Risk	AI hallucinations in root-cause; cold-start accuracy problem without training data
Mitigation	Critic agent provides a second opinion; confidence scores flag low-certainty reports

---

How to Run

Prerequisites

• Java 25+
• Maven 3.9+
• PostgreSQL 16+ running locally (or update application.yml)

1. Configure the Database

Add database credentials to src/main/resources/application.yml (or export as env vars):

spring:
  datasource:
    url: jdbc:postgresql://localhost:5432/observa_agent
    username: postgres
    password: yourpassword
  jpa:
    hibernate:
      ddl-auto: create-drop   # use 'validate' in production
    show-sql: false

2. Build and Run

cd solutions/2026-04-07-observa-agent-api

# Compile only
mvn clean compile

# Package
mvn clean package -DskipTests

# Run
java -jar target/observa-agent-api-0.0.1-SNAPSHOT.jar

3. Quick Test with curl

# Step 1 — Create an API key (public endpoint)
curl -s -X POST http://localhost:8080/v1/api-keys \
  -H "Content-Type: application/json" \
  -d '{"ownerId":"acme","description":"dev key"}' | jq .

# Copy the keyValue from the response, e.g. oa-xyz...
export API_KEY="oa-xyz..."

# Step 2 — Ingest telemetry
curl -s -X POST http://localhost:8080/v1/telemetry \
  -H "Content-Type: application/json" \
  -H "X-API-Key: $API_KEY" \
  -d '{
    "resourceId":"node-01","serviceId":"payments","environment":"production",
    "metrics":[
      {"name":"cpu.utilization","value":95,"unit":"%","labels":{}},
      {"name":"error_rate","value":8,"unit":"%","labels":{}}
    ],
    "collectedAt":"2026-04-07T10:00:00Z"
  }' | jq .

# Copy incidentId from response, e.g. INC-ABCD1234
export INCIDENT_ID="INC-ABCD1234"

# Step 3 — Poll for the report (wait ~1 second for async analysis)
sleep 1
curl -s http://localhost:8080/v1/reports/$INCIDENT_ID \
  -H "X-API-Key: $API_KEY" | jq .

# Step 4 — List all reports
curl -s http://localhost:8080/v1/reports \
  -H "X-API-Key: $API_KEY" | jq .

# Step 5 — Health check (no key required)
curl -s http://localhost:8080/actuator/health | jq .

---

References

• Primary Research Paper: Collaborative AI Agents for Network Fault Detection
• OpenTelemetry Specification
• Spring Boot 4.0 Reference
• Java 25 Virtual Threads (JEP 491)
• Jakarta Persistence 3.2

---

FinOps Analysis para ObservaAgent

Resumen de Costos y Rentabilidad

El modelo de micro-startup ObservaAgent opera con una estructura de costos operativos inicial muy ajustada, lo que se traduce en un margen de beneficio excepcionalmente alto, incluso con un número limitado de clientes. Esto es característico de las soluciones SaaS API-first con un fuerte apalancamiento en servicios de IA de bajo costo.

• Ingresos Mensuales Estimados: $500 (basado en 5 clientes pagando $100/mes por un plan básico).
• Costos Operativos Mensuales Totales: $60

* Costos de LLM (API OpenAI): $15/mes (Estimado en ~15 millones de tokens mensuales, utilizando una mezcla de %%INLINE26%% y %%INLINE27%% para el motor de análisis de IA). * Costos de Infraestructura Cloud: $45/mes * Cómputo (EC2 t3.small o equivalente): $20/mes * Base de Datos (AWS RDS db.t3.micro PostgreSQL): $15/mes * Almacenamiento (EBS 20GB): $3/mes * Red y Transferencia de Datos: $2/mes * Monitoring (CloudWatch básico): $5/mes Margen de Beneficio: 88% (($500 - $60) / $500) 100)

Desglose Detallado de Costos

La mayor parte de los costos operativos recae en la infraestructura cloud base para la ejecución de la API de Spring Boot y la base de datos PostgreSQL. Los costos de LLM, aunque esenciales para la propuesta de valor, son sorprendentemente bajos gracias a la eficiencia de modelos como %%INLINE28%% y %%INLINE29%% a volúmenes de micro-startup.

Estrategias de Optimización FinOps

Para mantener este alto margen de beneficio y escalar de manera eficiente, ObservaAgent debe considerar las siguientes optimizaciones FinOps:

1. Optimización del Uso de LLM:

* Caching: Implementar un sistema de caché para las respuestas de LLM, especialmente para patrones de telemetría o tipos de incidentes recurrentes. Esto reducirá las llamadas redundantes a la API de LLM. * Prompt Engineering: Refinar continuamente los prompts para ser lo más concisos y eficientes posible en el uso de tokens, sin comprometer la calidad del análisis. * Modelos Híbridos: Utilizar modelos LLM de menor costo (como %%INLINE30%% o incluso modelos open-source auto-hospedados) para tareas de clasificación inicial o summarización, reservando modelos más potentes y costosos (como %%INLINE31%% o Claude 3 Sonnet) solo para la etapa crítica de análisis de causa raíz.

1. Optimización de Infraestructura Cloud:

* Serverless para Escalabilidad: Evaluar la migración a una arquitectura serverless (ej. AWS Lambda con API Gateway para el %%INLINE33%% y %%INLINE34%%, y SQS/SNS para activar el AnalysisService) para la API y el motor de análisis asíncrono. Esto permitiría escalar a cero cuando no hay tráfico, reduciendo drásticamente los costos fijos de cómputo. * Aprovechamiento de Niveles Gratuitos: Asegurarse de maximizar el uso de los niveles gratuitos de AWS/GCP/Azure durante el primer año. * Instancias Reservadas/Planes de Ahorro: Una vez que la carga de trabajo sea predecible, invertir en instancias reservadas o planes de ahorro para EC2 y RDS para obtener descuentos significativos. * Optimización de Base de Datos: Monitorear el rendimiento de PostgreSQL y optimizar índices y consultas. Si el volumen de datos es muy bajo al inicio, considerar hospedar PostgreSQL en la misma instancia EC2 para eliminar el costo de RDS dedicado (aunque con mayor riesgo de SPOF).

1. Monitoreo y Alertas de Costos:

* Implementar herramientas de monitoreo de costos (ej. AWS Cost Explorer, GCP Cost Management) con alertas para detectar cualquier anomalía o aumento inesperado en el gasto, especialmente en el uso de LLM y transferencia de datos.

Conclusión

ObservaAgent demuestra un modelo de negocio con una excelente economía unitaria para una micro-startup. La clave para mantener esta rentabilidad a medida que crece será la gestión proactiva de los costos de LLM y la optimización de la infraestructura cloud para escalar de manera eficiente y elástica, evitando el sobreaprovisionamiento y aprovechando las opciones de pago por uso.