Policy-safe trace relay for AI vendors in customer VPCs, exporting redacted support evidence without raw-data exfiltration.

1. AI telemetry volumes are making legacy per-byte observability pricing structurally uneconomic for agent workloads.
2. Enterprise buyers now require telemetry and prompts to stay inside their own cloud accounts, creating a new tooling gap for vendors.
3. Debugging modern agents now requires prompt-level traces, confidence scores, and call graphs, not just logs and metrics.
4. Named customers and six-figure contracts prove there is already budget for premium BYOC AI reliability infrastructure.

Catalyst. Tsuga's traction shows enterprises now insist on in-cloud AI observability because AI traces are both too sensitive and too voluminous for legacy SaaS observability patterns.

The product deploys a lightweight collector and policy engine into each customer tenant where the AI vendor already runs its application. It records complete agent traces, prompt lineage, confidence scores, and call graphs locally, then automatically generates redacted incident bundles, regression diffs, and benchmark snapshots that the vendor can access centrally. Customers control what fields can leave the account, how long evidence is retained, and whether replay artifacts are exportable. Vendors get cross-tenant fleet health, release-quality comparisons, and much faster incident resolution without asking customers to open broad observability access.

What's different. Traditional observability vendors want the customer to buy another backend; this startup sells the vendor a support-specific relay purpose-built for fleets of isolated customer-cloud deployments. The core IP is policy-aware evidence packaging: full traces stay local, while only approved summaries, diffs, and redacted artifacts leave the tenant. That makes the product useful even when the customer already has Datadog, Grafana, or CloudWatch, because it solves the vendor's cross-tenant debugging and release-support problem rather than replacing the customer's tooling.

Jobs to be done

flowchart LR
  Buyer[BYOC AI vendor] --> Pain[Blind support inside customer clouds]
  Pain --> Product[In-tenant trace relay and policy engine]
  Product --> Outcome[Faster MTTR with safe cross-tenant insight]

Executive takeaways

• The wedge is real but narrow: the pain is not generic monitoring, it is vendor-side support for AI products running inside customer-controlled clouds.
• Private connectivity, masking, retention controls, and auditability are table stakes for this category, not premium add-ons.
• Budget exists when the pain is acute, but the earliest spend is concentrated in AI vendors with multiple live BYOC tenants and recurring Sev-1 support load.
• Go-to-market risk is more about security-review friction and install complexity than about whether the underlying telemetry stack can be built.

Market definition

A vendor-support and reliability layer for AI software companies that deploy inside customer clouds, sitting between generic observability tooling and managed support operations.

Customer and buyer

Economic buyers are usually CTOs or VPs of Engineering facing enterprise BYOC renewals, while day-to-day champions are reliability, platform, and senior solutions engineers who currently coordinate customer-run log pulls and dashboard access.

Buying triggers

• A new or renewed enterprise account requires private-cloud deployment, making direct vendor access impossible without a support-safe relay. [2][29][31]
• AI telemetry bills or sampling gaps make legacy SaaS observability economically and operationally painful for agent workloads. [2][3][21][26]
• A bad release or repeated incident across isolated tenants exposes the cost of manual evidence gathering and weak fleet comparison. [4][11][24]
• Governance work forces automatic logging, masking, and audit trails into the production checklist before more regulated customers can go live. [8][18][32][36][38]

Willingness to pay

Premium spend is plausible when pain is acute: Tech Funding News reports Tsuga at several million ARR with six-figure average contracts, while Langfuse, LangSmith, and groundcover show that paid tiers concentrate around retention, auditability, support, and enterprise controls rather than raw tracing alone. [2][9][15][23]

Category dynamics

Growth signal 16% CAGR (observability market 2024-2034, as cited in Tech Funding News coverage).

Validation signals

• Tsuga already reports several million dollars of ARR, six-figure average contracts, and named customers in this architectural neighborhood.
• Adjacent observability vendors now package BYOC, on-prem, and air-gapped deployment models as first-class offers.
• Major clouds have normalized private connectivity and tighter data-boundary controls for AI services, lowering technical feasibility risk.
• The telemetry layer is standardizing around OTel-style semantics, which reduces connector risk for a new vendor.

Regulatory & technical constraints

• Private networking and no-public-egress patterns are often mandatory for accessing models and moving telemetry in regulated environments.
• Prompt and log masking, deletion, and auditability must be first-class product features, not post-processing steps.
• Zero-retention claims are cloud- and feature-specific; some provider workflows still retain prompts or responses for monitoring.
• EU AI Act-style requirements push automatic event logging, post-market monitoring, and incident evidence deeper into the runtime stack.

The space is crowded at the infrastructure layer but still fragmented at the vendor-support workflow layer. Most products optimize for application teams or centralized backends; fewer are built around exporting policy-safe evidence from many isolated customer tenants back to the vendor’s support organization.

Why incumbents do not win by default

• Cloud platforms. AWS, Azure, and Google Cloud now provide the private networking and data-boundary primitives a buyer expects, but they stop at infrastructure primitives and do not solve cross-tenant vendor support workflows.
• Generic observability suites. Datadog-class platforms can unify AI and infrastructure telemetry, yet they still assume enough data can be centralized into the observability backend and paid for under a modular platform contract.
• Open-source and self-hosted stacks. Self-hosted tools such as Langfuse and Helicone give local control, but buyers still have to assemble export policy, support bundles, and fleet-level comparison flows themselves.
• Agent lifecycle platforms. LangSmith and Arize reach deeper into deployment, evals, and private connectivity, but their center of gravity is application-team engineering productivity rather than vendor-safe remote support across customer clouds.

BYOC agent support relay is a vendor-support infrastructure company for AI software vendors that deploy agents inside customer-owned cloud accounts. The beachhead is Series A-C vendors with 5-20 live BYOC tenants in regulated sectors where weekly escalations still depend on customer-run log pulls and ad hoc scripts. The first product is not a broad observability suite; it is an AWS-first in-tenant trace relay and policy engine that produces redacted incident bundles, release-regression diffs, and fleet health signals without exporting raw prompts or traces by default. That wedge matches the researched buying trigger of a new enterprise BYOC win, renewal, or bad release that overwhelms the vendor's reliability team. Pricing should start with a paid pilot and then convert to per-live-tenant annual subscriptions because value scales with isolated deployments, not seats. The sequencing is intentionally narrow: prove one support workflow, one cloud, and one export-approval model before expanding into multi-cloud coverage, SLA proof, or billing analytics. The strongest reasons to engage are clear pain, premium budget precedent, and a differentiated workflow relative to generic observability tools. The biggest disconfirming risk is that security teams refuse any outbound artifact egress or that the true count of vendors with enough live BYOC tenants is smaller than assumed. Research also does not resolve the dominant private-cloud agent frameworks or the first budget owner, so the first six months must treat connector selection and budget ownership as explicit tests.

Problem

• AI vendors lose root-cause speed once their product runs inside customer VPCs and support teams depend on customer-run log pulls, dashboards, and SSH sessions to diagnose incidents.
• Existing observability products either require sensitive telemetry to leave the tenant or price unsampled AI traces poorly, while manual workflows cannot compare incidents or regressions across isolated customer environments.

Solution

• Deploy an AWS-first in-tenant collector and policy engine that captures full agent traces locally and exports only approved redacted incident bundles, regression diffs, and fleet health summaries.
• Give vendor reliability teams a central cross-tenant support console for P1 triage, release comparison, and export approval without forcing the end customer to replace Datadog, Grafana, or CloudWatch.

Why we win

• The product serves the vendor's support and release-debugging workflow rather than asking the end customer to buy another observability backend, which avoids a head-on platform replacement sale.
• Reusable masking policies, export templates, and a growing corpus of redacted incident bundles and fixes across many tenants compound into faster diagnosis and a workflow moat.

Milestones

flowchart LR
  Wedge[BYOC support relay] --> MVP[AWS-first incident bundle MVP]
  MVP --> Proof[Faster triage and paid pilot conversion]
  Proof --> Expansion[More tenants plus release validation and SLA evidence]

Founding team

Experiment roadmap

Risk assessment

What must be true

• At least one target segment has enough vendors with 5 or more live BYOC tenants to support efficient founder-led pipeline generation now.
• Security teams will approve a predefined redacted export schema often enough that the relay can operate without full manual bespoke review every time.
• The relay reduces time to first actionable root-cause packet and overall MTTR enough that buyers fund it from an existing reliability or support budget.
• An AWS-first deployment can be packaged tightly enough that pilots do not become custom services projects.
• Incumbent observability and self-hosted tooling do not solve cross-tenant vendor support workflows well enough to erase the wedge before expansion.

Open diligence questions

• How many live BYOC tenants do the best initial prospects actually run today, not merely pilot?
• What exact fields and approvals must be present before a security team allows outbound incident bundles?
• Which cloud and agent-framework combinations dominate the first 20 prospects and therefore define the connector roadmap?
• Where did comparable buyers fund adjacent tools: reliability, support operations, or security architecture?
• What measurable MTTR delta would make a prospect convert from pilot to a six-figure annual contract?

Model sanity

• Revenue engine. The base case is driven by growing from 2 production vendors at Y1 end to 28 by Q4Y3 at a $130K blended ACV, with most value coming from repeatable AWS deployments and tenant expansion.
• Must go right. Security reviews have to approve a standard redacted-bundle workflow often enough that partner-assisted pilots can convert into 14 production customers by Q4Y2.
• Model breaks if. If sales cycles stretch toward 8-9 months or gross margin stalls below 67%, the downside case keeps EBITDA deeply negative and shrinks the cash floor to roughly $0.6M.
• Next-round proof. A seed-ready story appears once the company can show 14-20 production customers, partner-assisted installs, and release-regression upsell without losing the path to 70% gross margin.

Scenarios

Sensitivity

flowchart LR
  Leads[Qualified BYOC vendors] --> Pilots[Paid pilots]
  CACSpend[CAC spend] --> Pilots
  Pilots --> Customers[Production customers]
  Customers --> Tenants[More live tenants]
  Tenants --> Revenue[Annual subscription revenue]
  Revenue --> GrossProfit[Gross profit]
  GrossProfit --> EBITDA[EBITDA]
  EBITDA --> Cash[Ending cash]
  Churn[Churn and security friction] --> Customers

Flags: The model assumes enough target accounts will approve outbound redacted incident bundles to reach 14 production customers by month 24, but research still leaves budget ownership and export-policy pass rates unresolved. · Gross margin only reaches the 70% business-plan target if deployment work stays near the plan threshold of under two engineer-weeks per customer; otherwise solutions work will push the funding need higher. · Revenue excludes paid pilots and onboarding fees, which keeps ARR conservative but means the cash path may diverge if the company leans harder into services to win early deals.

• Slow security reviews. Each customer tenant may require a separate security and procurement review before the relay can be installed. Mitigation: Start with vendors already selling BYOC into regulated accounts and provide opinionated reference architectures, redaction defaults, and audit artifacts.
• Incumbent observability overlap. Customers may argue their existing Datadog, Grafana, or CloudWatch stack should already solve the problem. Mitigation: Position the product as vendor-side support infrastructure that works on top of customer-owned tools and focuses on cross-tenant evidence packaging rather than replacing the stack.
• Beachhead too narrow. The number of vendors with enough live BYOC tenants could be smaller than expected in the first year. Mitigation: Land in BYOC support first, then expand to release validation, SLA proof, and billing evidence for the broader private-deployment software market.