Velane

Cloud for your AI Agent's tools and functions

Developer Tools

Artificial Intelligence

GitHub

Tech

Visit WebsiteSee on Product HuntGithub ⧉Twitter ⧉

The 0-cold-start sandbox plus real dev/staging/prod is the combination I'd actually commit to — most agent tool setups give you the sandbox and then hand-wave the deployment step. Curious how integration setup actually works on first use: when an agent needs to call one of the 800+ integrations, does it pull the tool spec and configure it autonomously, or do I still need to manually set up auth credentials before the agent can call it? That onboarding path for OAuth or API key integrations is usually where agent tooling bogs down for me.

the PCI/HIPAA background showing up in the isolation answers is a good sign, most infra-for-agents launches don't think that far ahead. curious about the cost side of the 0 cold start sandbox claim - keeping something warm enough to avoid cold starts usually isn't free on your end, so how does that show up in pricing? is it a flat rate regardless of how many tools/agents a customer keeps warm simultaneously, or does cost scale with concurrent warm sandboxes, since that's usually where 0-cold-start promises get expensive fast at any real scale

Hosting tools separately from the agent is the right split, and it makes versioning the interesting problem: when a function's signature changes, does the agent find out at call time or do you surface the diff beforehand? Tool drift has broken more of my agent runs than bad prompts ever have.

@abhishekraj that background is reassuring, PCI/HIPAA-grade isolation is a much higher bar than most infra-for-agents startups even think about at launch. did that mean per-tenant sandboxing at the VM/container level, or something stricter like separate execution environments entirely per customer?

Congrats on the launch, the 800+ integrations positioned as an iPaaS replacement really stands out. For a given integration, does each function get its own scoped OAuth grant, or is it one shared connection token that every function using that integration draws from?

The 0-cold-start sandbox plus real dev/staging/prod is the combination I'd actually use — most agent-tool setups give you the sandbox and then hand-wave the environments.

The question I keep coming back to with anything agent-controlled: if the agent controls the functions and the promotion between environments, what sits between "works in dev" and "live in prod"? I run a fleet with real tool access, and the thing that keeps it safe isn't the sandbox — it's that a human, not the agent, owns the prod gate. A confidently-wrong agent promotes a broken tool to prod exactly as smoothly as a good one, and staging doesn't catch a mistake the agent is sure about. Is promotion something the agent can do end to end, or can I require a human checkpoint on the last hop?

Either way, agent-first tooling with real environments is the right shape. Congrats on the launch.

that's a smart approach. how does it handle secrets when agents push functions across environments?

the pitch of hosting tools/functions for other people's agents means you're sitting in the middle of a lot of different customers' agent traffic on shared infra. how strict is the tenant isolation - could one customer's misbehaving or compromised agent end up seeing or affecting another customer's functions, or is that ruled out at the architecture level rather than just policy?