For the best experience on desktop, install the Chrome extension to track your reading on news.ycombinator.com
Hacker Newsnew | past | comments | ask | show | jobs | submit | history | walmsles's commentsregister

The portal is the B2B component for agent monetisation platform I am building. We are also building free and open source agent discovery - boring federated infra servicekind of like DNS - to ensure Agent discovery is free from lock-in and available for everyone - this is the no Vendor Lock-in component. AWS was a choice and its for a hackathon run by AWS so - needed to.

No Vendor Lock-in is the discovery piece Tethyr.cloud is built on. Thats the killer bit that matters - so we all collectively own agent discovery.


I built Tethyr Cloud for the AWS AIdeas competition - it's a B2B agent federation platform addressing a problem I see emerging: agent discovery is fragmenting across proprietary registries with vendor lock-in. The architecture has two parts: open-tethyr (OSS): Agent discovery server implementing the Agent Exchange (AX) protocol draft by Aaron Sempf. Free, decentralized discovery that prevents corporate gatekeeping. Tethyr Cloud (commercial): Trust layer for B2B commerce - subscriptions, rate limiting, usage metering. Built on the discovery network but doesn't own the data. Key design decisions:

Peer-to-peer agent execution - payloads never touch Tethyr infrastructure Stateless JWT validation with <200ms p95 latency Fire-and-forget usage reporting off the hot path (SQS buffering) Dual-API boundary (AppSync for dashboard, API Gateway REST for SDK)

Built on AWS Amplify Gen 2 in 4 weeks. Running costs: $0/month in Free Tier. Full writeup: https://builder.aws.com/content/3Au66gquBesFWDxq83Luj1SzZOk/...

Top 300 projects advance based on article likes by March 20.

Feedback welcome.


I built a library that uses an LLM as an orchestrator to coordinate multiple agents at runtime. You define what each agent does in markdown files using RFC 2119 constraints (MUST, SHOULD, MAY), and the orchestrator figures out who to call and when based on the user's request.

This builds on AWS Strands Agent SOPs (markdown format for agent workflows released in November). The difference: instead of manually chaining agents or defining explicit flows, the orchestrator reads available agent capabilities and decides the execution path dynamically.

Add a new agent by dropping in a markdown file. No code changes to coordination logic.

The bet: LLMs are better at runtime orchestration than developers are at predicting workflows upfront, especially when requirements change. Natural language is more maintainable when both producers (agent authors) and consumers (orchestrator) are LLMs.

Built on AWS Strands SDK and Bedrock with Claude models. Using this in a technical bootcamp next week to teach students complex agent workflows without coordination code.

GitHub: https://github.com/serverless-dna/sop-agents npm: https://www.npmjs.com/package/@serverless-dna/sop-agents AWS Strands blog: https://aws.amazon.com/blogs/opensource/introducing-strands-...


Hi HN, I built this because MCP servers run with full user permissions — they can see your SSH keys, AWS credentials, everything.

Most people just copy configs from READMEs and hope for the best. I wanted container isolation without the Docker complexity.

One config change: "uvx" becomes "run-mcp", args: ["uvx", ...]. Full isolation, no Docker knowledge needed.

Blog post with more details: https://serverlessdna.com/strands/projects/introducing-run-m...

Happy to answer questions.


Consider applying for YC's Summer 2026 batch! Applications are open till May 4

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search:

HN For You