Launched this week
Velane
Cloud for your AI Agent's tools and functions
80 followers
Cloud for your AI Agent's tools and functions
80 followers
Velane is the one platform for your AI Agent's tools and function. It is agent first, and fully controlled by your AI Agent (Claude, Codex, Cursor,..) It has: 1. Code Sandbox (with 0 cold start) 2. Version Control 3. Enviroments (dev, staging, prod) 4. 800+ Integrations (it replaces your iPaaS)
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.
Velane
Great question @mystoryland, the environment promotion is controlled by your agent and our MCP and CLI harness is built in a way, your agent will always ask for your approval before environment promotion.
If you would like, we can make the API key have more granular access like controlling the env promotions
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?
Velane
@omri_ben_shoham1
At the infra level, tenant’s are completely isolated.
I come from building multi tenant software for PCI and HIPPA compliance, so I designed the complete architecture for those compliance.
Btw great question.
that's a smart approach. how does it handle secrets when agents push functions across environments?
Velane
Hi @dhiraj_patel5 , thanks for bringing this up! At the moment, we support a global secrets store that’s shared across all your workflows. We’re planning to add support for separate secrets stores for each workflow in a future release.
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?
Velane
Hi @vollos, a single integration is shared across workflows, however you can create multiple integration for same app using different alias, then use that alias for different integration. As Velane is agent first, so your coding agent will prompt you if it encounters multiple integration for an app.
@abskrj Once two workflows point at the same shared integration, what scope does that connection end up carrying, the narrowest permission either one needs, or the union of everything either has asked for over time?
@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?
Velane
Thanks for the appreciation @omri_ben_shoham1, we do per-execution sandboxing at the pod/VM level. We are still talking to our pilot customers and we may soon support separate execution environments entirely per customer, which will give better security + protection againt downtime due to a rogue customer
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
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.