Caspian promises to fix agent-to-human comms — but does the DSL

I've been watching the agent infrastructure space for a while, and the communication layer keeps showing up as the quiet bottleneck nobody wants to build. Caspian (show HN link) wraps webhooks, queues, and identity into a single SDK call — think "better-auth but for agent messaging." The pitch: one integration replaces the patchwork of Agentmail for inboxes, Composio for tool calls, and Twilio for SMS/voice.

What caught my eye is the DSL design. They didn't just bolt on an API; the SDK is a domain-specific language for communication patterns, heavily inspired by functional programming. That means composable primitives — send, awaitReply, branchOnChannel — instead of imperative glue code. In practice you write:

from caspian import Agent, Channel

agent = Agent("support-bot")

@agent.on_message
async def handle(msg, ctx):
    if msg.channel == Channel.EMAIL:
        await ctx.reply("Got your email, checking...")
        result = await lookup_order(msg.body)
        await ctx.send(result, channel=Channel.EMAIL)
    elif msg.channel == Channel.SLACK:
        await ctx.react("👀")
        await ctx.send("I'll DM you the details", channel=Channel.SLACK)

The runtime auto-provisions infrastructure (their monetization path) or you can bring your own tokens. Python and TypeScript are first-class targets.

Where I'm skeptical

• Vendor lock-in risk: The DSL is open source, but the managed runtime isn't. If the pricing changes or the service goes down, how painful is migration?
• Channel parity: Email and Slack are table stakes. WhatsApp, Discord, Telegram, and voice all have wildly different rate limits, threading models, and compliance requirements. Does the abstraction leak?
• Queue semantics: "Reliable delivery" means different things for a support bot (at-least-once) vs. a trading agent (exactly-once). What's the default, and can you tune it per workflow?
• Identity model: They mention "identity management" — is that per-human, per-conversation, per-channel? How does it handle a user who switches from email to Slack mid-thread?

What would make me try it

• A local-first dev mode that doesn't require the cloud runtime (so I can test CI/CD without burning credits)
• Explicit delivery guarantees per channel, documented
• A migration story: export the DSL definitions and run them against a self-hosted adapter
• Benchmarks showing latency overhead vs. raw webhook handlers

Right now it feels like a promising abstraction layer that solves the "I don't want to maintain three webhook endpoints" problem, but the real test is whether the DSL survives contact with production weirdness — retries, partial failures, channel-specific quirks. Has anyone stress-tested it beyond the hello-world examples?