AIdeas: Tethyr.cloud
Tethyr is a B2B agent federation platform that gives publishers a commercial trust layer — subscription management, usage metering, and billing attribution — while keeping agent payloads sovereign. Built on AWS Amplify Gen 2 and the open-tethyr SDK, it enables SaaS platforms and enterprise vendors to monetise agent capabilities with zero vendor lock-in.
App Category: Commercial Solutions
Team: Tethyr
Team Members: walmsles@
My Vision
The B2B agent economy is emerging fast, but the commercial infrastructure to support it doesn't exist yet. Developers can expose agent capabilities and others can discover them — but there's no trusted layer to handle subscriptions, access control, rate limiting, or usage tracking between organisations. That gap is what Tethyr solves.
Tethyr is a federation platform for B2B agent commerce. It consists of two parts: open-tethyr, an open-source TypeScript SDK that implements the Agent Exchange protocol, and tethyr.cloud, a commercial SaaS portal that adds the commercial trust layer on top of it.
Publishers register agent capabilities on tethyr.cloud and define access tiers — free, partner, enterprise — with quota limits per tier. Subscribers discover capabilities through the public catalogue, request access, and once approved, integrate directly via the open-tethyr SDK.
Tethyr provides usage metering and quota tracking. Publishers see who is using their capabilities and how much. Subscribers see their consumption against their tier limits. The analytics dashboard gives publishers visibility across their entire capability portfolio. Enforcement is delegated to the publisher's endpoint — they own the experience and control the implementation.
Agent payloads never touch tethyr.cloud infrastructure. The model is deliberate: open SDK drives adoption, the commercial platform captures monetisation value, and publishers retain full ownership of their agent infrastructure — zero vendor lock-in.
Why This Matters
Three groups are directly unlocked by this platform.
SaaS platforms can monetise agent capabilities through tiered access without building subscription infrastructure from scratch. A CRM vendor can offer free contact lookup to anyone while restricting enrichment APIs to paid partners — with Tethyr handling subscriptions, rate limiting, and usage tracking automatically.
Industry networks can create members-only agent exchanges with controlled discovery. Only approved organisations can see and access capabilities, enabling trusted data sharing within a vertical without exposing infrastructure publicly.
Enterprise vendors can scale API-as-agent partnerships. Publishers define commercial terms; Tethyr enforces policies and tracks usage for billing.
The gap Tethyr fills is real. The GitHub MCP Registry offers discovery but has no commerce layer. Private deployments can't scale across organisations. Tethyr provides the missing layer: trusted B2B exchange with federation architecture. Publishers keep all their agent value. Tethyr charges for infrastructure.
How I Built This
Architecture Overview
Tethyr is an AWS Amplify Gen 2 application. The React dashboard (publisher and subscriber views with role-based navigation) is hosted via Amplify. The
amplify/ directory defines all backend resources using Amplify constructs, with custom CDK only where Amplify Gen 2 cannot natively express the requirement.
API boundary separation is a core architectural principle:
- AppSync handles all dashboard API interactions — authenticated, real-time capable GraphQL
- API Gateway REST handles the external/SDK-facing API — required for custom JWT authoriser flexibility that Amplify's HTTP API construct cannot provide
The open-tethyr SDK lives in
packages/open-tethyr/ as a separately versioned npm package, decoupled from the tethyr.cloud release cycle.Token Model
Each subscription generates a unique OAuth token scoped to a specific subscriber + capability + tier combination. A subscriber with access to three capabilities holds three tokens. The token carries full attribution context in its claims — no additional lookup required at validation or billing time. This is what makes usage metering accurate and publisher revenue attribution clean.
Call Flow
Every agent interaction follows the same pattern.
- Subscriber calls the open-tethyr SDK, presenting their subscription token (scoped to subscriber + capability + tier)
- SDK generates a
X-Tethyr-Correlation-IDheader (UUID) and invokes the publisher agent endpoint directly
- Publisher agent validates the token with Tethyr.cloud — verifies claims and confirms the subscription is active
- If invalid, Tethyr.cloud rejects and logs the security failure
- If valid, the publisher agent executes
- Publisher agent reports usage to Tethyr.cloud in-band (correlation ID, execution time, tier) — Tethyr records spend against the subscriber and revenue against the publisher
- Response returned to the subscriber — payload never touches Tethyr.cloud infrastructure
AWS Services
Service | Role | Justification |
|---|---|---|
AWS Amplify Gen 2 | App hosting + backend orchestration | Serverless-first; eliminates infrastructure boilerplate |
Amazon Cognito | Authentication | Managed identity; native Amplify integration |
AWS AppSync + DynamoDB | Dashboard API + primary storage | Real-time GraphQL for dashboard; DynamoDB for ~15 data model types |
API Gateway REST (custom CDK) | External/SDK API | Custom JWT validation; <200ms p95 token validation target |
AWS Lambda | All business logic | ~8 functions: token validate/refresh/JWKS, rate limiter, analytics aggregator, notification sender, subscription auto-approve, public catalogue |
Amazon S3 | Usage metering exports | Billing data export for pay-per-use subscribers |
Amazon EventBridge | Scheduled aggregation | Triggers analytics aggregator on 5-minute schedule |
Running Costs
Every service in Tethyr is selected to operate within the AWS Free Tier. At current traffic levels the platform runs at effectively $0/month.
Service | Free Tier Allowance | Tethyr Usage |
|---|---|---|
AWS Amplify | 1,000 build mins/month, 15GB hosting/month | Minimal — static React app |
Amazon Cognito | 50,000 MAUs free | <100 users at this stage |
AWS AppSync | 250,000 query/mutation/subscription minutes/month | Dashboard only — low volume |
Amazon DynamoDB | 25GB storage, 25 WCU/RCU | On-demand billing; negligible at this scale |
AWS Lambda | 1M requests/month, 400,000 GB-seconds/month | ~8 functions, low invocation rate |
API Gateway REST | 1M API calls/month | Token validation calls only |
Amazon S3 | 5GB storage, 20,000 GET, 2,000 PUT/month | Metering export files only |
Amazon SQS | 1M requests/month | Usage events — well within free tier |
Amazon EventBridge | 1M events/month | 5-min scheduled aggregation only |
At scale: As publisher and subscriber counts grow, costs scale linearly and predictably. Lambda and SQS usage remain the primary cost drivers, both of which scale per-invocation with no idle cost. DynamoDB on-demand means no over-provisioning. The architecture is designed to stay in Free Tier throughout the competition and early growth phases.
CI/CD with Amplify Hosting
Amplify hosting provides a built-in CI/CD pipeline with zero configuration. Every push to the main branch triggers an automatic build and deploy — frontend and backend together. The
amplify/ directory is the source of truth for all backend resources; Amplify detects changes and deploys only what has changed.This eliminated the need for a separate pipeline tool, deployment scripts, or infrastructure management overhead. For a 4-week build, having CI/CD working from day one meant focus stayed on features rather than DevOps.
Development Approach: Spec-Driven with Kiro
Kiro IDE was central to achieving a 4-week delivery target. The approach used spec-driven development with a multi-agent architecture inside Kiro — four specialised MCP sub-agents providing domain expertise while minimising context overhead per task:
- AWS Powertools MCP — Lambda observability patterns
- CDK MCP — Infrastructure constructs
- AWS Docs MCP — Current SDK methods and service APIs
- Serverless MCP — Architecture design patterns
Requirements were written in EARS notation per feature before any code was written. Kiro analysed requirements and generated architecture artefacts — API contracts, data models, event flows — then produced code, infrastructure, and tests in vertical slices.
Week 1 — Foundation: open-tethyr SDK with Agent Exchange protocol parser, AgentCore Gateway client, and OAuth token handler. Published as a TypeScript npm package.
Week 2 — Backend: Publisher and subscriber APIs, subscription workflows, OAuth token issuance, access control, rate limiting.
Week 3 — Integration: Publisher analytics, usage metering for billing, multi-gateway orchestration.
Week 4 — Dashboards: React publisher dashboard (manage capabilities, approve subscriptions), React subscriber portal (discover capabilities, request access, manage tokens), deployed via Amplify.
Demo
Homepage — Public Catalogue & Value Proposition
Public-facing homepage showing the platform value proposition and live metrics: 8 agent capabilities, 5 organisations, 16 access tiers, 14K+ API requests over 14 days.
Publisher — Capabilities Management
Publisher dashboard showing capability lifecycle management across Published, Draft, Unpublished, and Archived states. Publishers create and manage capabilities with access tier definitions from this view.
Publisher — Subscriptions & Revenue
Subscription management view showing active subscriber count, revenue tracking, and billing cycle under a pay-per-use model.
Publisher — Analytics
Analytics dashboard showing total requests, 14-day revenue, projected monthly revenue, and rate-limited request count. Includes daily request volume chart (successful vs rate-limited) and revenue breakdown by capability.
Subscriber — Discover Capabilities
Subscriber capability discovery view with search and category filtering. Subscribers browse the catalogue and request access to capabilities relevant to their use case.
Subscriber — My Subscriptions
Subscriber spend tracking view showing current period spend across all vendors and active subscriptions, with billing cycle visibility.
Subscriber — Access Tokens
Token management view where subscribers manage active OAuth tokens issued per approved subscription. Tokens authenticate peer-to-peer agent calls directly against publisher endpoints.
What I Learned
The most significant insight from this build was that Kiro's spec-driven approach improves architecture quality, not just delivery speed. Forcing requirements into EARS notation before touching code surfaced ambiguities that would otherwise have emerged as rework mid-build. Writing contracts — API contracts, data models, event flows — before implementation meant Kiro agents had tight, unambiguous context per task. That's where the speed came from: not code generation speed, but the elimination of rework.
The peer-to-peer data sovereignty constraint required sustained architectural discipline. The natural pull in any SaaS platform is to centralise data flows for observability and debugging. Holding the line that Tethyr validates tokens but never sees payloads meant every design decision around logging, metering, and analytics had to be re-examined. Usage records contain only metadata. The constraint made the architecture better — and more commercially differentiated.
The dual-API boundary (AppSync for the dashboard, API Gateway REST for the external SDK) initially appeared to be unnecessary complexity for an early-stage build. In practice, separating the contracts cleanly meant the SDK API could evolve independently of the dashboard, and the Lambda authoriser on the REST API provided the JWT validation flexibility that would have been difficult to achieve otherwise. The principle of Amplify constructs before CDK kept the custom infrastructure footprint small and justified.
Latency was the central engineering constraint. Every agent call passes through token validation, meaning any overhead directly impacts the subscriber experience. The target was <200ms p95 — achievable only if usage reporting was completely off the hot path.
The solution was a fire-and-forget pattern in the publisher SDK: after the agent executes and returns the response, the SDK makes an async non-blocking POST to API Gateway, which puts the usage event onto SQS. The agent call is already complete before that event is dispatched. The subscriber sees no additional latency. The stream buffers independently, handles retries, and the Lambda consumer reconciles out of band using the correlation ID.
The design decisions that kept the hot path fast:
- JWT validation is stateless — Cognito issues RS256 JWTs and publishes a JWKS endpoint automatically. The publisher SDK verifies the token cryptographically against cached public keys with no database lookup and no round trip to Tethyr on every call.
- Subscribers authenticate using OAuth2 client credentials (client ID + secret), which is the standard machine-to-machine flow. Cognito handles token issuance natively via App Clients with client credentials flow enabled.
- Custom claims (subscriber ID, capability, tier) are injected into the access token via a Cognito Pre Token Generation Lambda trigger — fired once at token issuance, not on every call. This means full attribution data travels in the token itself.
- JWKS caching in Lambda memory means the public key fetch happens once per warm instance, not per invocation. Combined with stateless JWT verification, validation stays well under the latency budget.
- API Gateway as the async entry point decouples the publisher SDK from SQS directly, keeping the SDK dependency surface minimal.
- SQS absorbs traffic spikes without backpressure on the publisher agent, and the correlation ID ties every async usage event back to its originating token validation — so fire-and-forget does not mean unverifiable.
Finally, the open-source / commercial split — open-tethyr SDK plus tethyr.cloud — is as much a go-to-market decision as a technical one. The SDK removes the integration barrier for subscribers. The commercial platform captures the value. Building them as independent, separately versioned artefacts from day one made that boundary real rather than aspirational.
Enjoyed reading this content? Let the author know!
Your likes, comments, shares, and saves help creators reach more builders.
Loading recommendations
Loading article