Having spent years working with PubNub's platform, I've had a front-row seat to what it takes to build and operate mission-critical, real-time systems at global scale. What excites me about Blocks.ai is that it applies those same principles to what we (at PubNub) believe is the next major enterprise infrastructure challenge: operating AI agents.
The industry has made incredible progress building agents. What's been missing is the operational layer that lets organizations securely connect, govern, discover, route, observe, and manage agents across different models, frameworks, clouds, business units, and environments without locking themselves into a single AI ecosystem.
That vendor-neutral approach is what stands out. Rather than replacing existing AI investments, Blocks.ai provides a common control plane that helps enterprises bring them together with the governance, visibility, and operational controls they'll ultimately need as AI moves from experimentation into production.
I also appreciate that the team isn't building from scratch. It's built on infrastructure that's been trusted in production for more than 15 years, which gives me confidence that the focus is on solving real operational problems, not just shipping another AI demo.
I think Blocks.ai is tackling an infrastructure layer that's going to become increasingly important over the next few years, and I'm excited to see where the platform goes.
NINA
Interesting positioning. A lot of agent infrastructure focuses on orchestration after agents are deployed, while you're solving the connectivity layer first.
The outbound-only approach removes a lot of deployment friction, especially for teams behind strict firewalls. I'm curious how you handle identity and trust as the network grows. If one agent calls another, what mechanisms verify the caller's permissions and prevent an agent from impersonating another or accessing capabilities it shouldn't?
@varun1jan Great question. The Blocks Network allows you to create an org, under which you register your agents. Each agent gets an API token for access to the network, and each task between agents generates and distributes its own auth token that rotates to each task.
Org --> agent (API Token) --> task (per-task tokens)
When a task is submitted by a "caller" agent, the Blocks Network checks whether the caller has permission, and if so, relays the task to "provider" agent, and relays the per-task tokens to both the provider and caller. From that point forward, the caller and provider communicate directly (proxied via PubNub streaming using the per-task tokens). Subsequent tasks require re-authorization and new token generation (all handled automatically by Blocks Network).
The bottom line is that identity is proven per request, and the Blocks Network itself is responsible for verifying the callers permissions and validating the tokens (which can be instantly revoked if an agent needs to removed from the network).
There's a good whitepaper with tons more detail here: https://blocks.ai/architecture/security-whitepaper
Blocks solves a major problem in the industry (which is awesome), but it seems a bit daunting for non-developers. As someone in marketing, how easy is it for me to make an agent and utilize it in my day-to-day?
@oliverc It's easier than you'd think! Blocks.ai makes building and connecting a simple agent easier than you'd expect. If you have a vibe coding tool like Claude or Codex, or you just have some knowledge of coding (I see you digital marketers keeping websites alive!), our guides can get you connected fast.
Calling an agent to use in your day to day can be even simpler - you can call them from your web app, or via an MCP server.
Our quickstart guide is a great place to find more detailed instructions on how to connect and call: https://blocks.ai/docs/quickstart
Curious how pricing scales when you have dozens of agents talking across different frameworks — is it per agent, per message, or something else entirely?
@ferdif5tf For non-streaming public paid agents, pricing is set by the builder who owns the agent, and callers pay that amount per task. Blocks.ai handles the billing (through Stripe) and builders earn 85% of each task cost when their public paid agents are called.
the per-task token rotation makes sense for discrete tasks, but what about the long-lived streaming cases you mentioned above (live transcription, voice, video)? does a task token just live for the whole duration of an open stream, or does it get silently re-issued on a timer mid-stream without disrupting the connection? asking because re-auth mid-flight is usually where these systems either add a hiccup or get it invisibly right.
Startup Metrics Dashboard
@galdayan Hi Gal, good question about re-auth mid-flight. The auth is proactive before the stream task token expires. Your question was correct. The task token does not silently live for the whole stream. It's re-issued on a timer (proactive at 80% TTL) and applied on the live connection, so an open transcription/voice/video stream keeps flowing without a reconnect. Re-auth mid-flight is the the approach used. Hiccups avoided. Also with a reactive 401 fallback behind it. The one thing that will end a long stream is the independent server-side durationExpiresAtMs deadline. That is by design. Another stream end is a truly failed refresh that is surfaces loudly from auth refresh failed error / auth-denied / destroy. This will not degrading silently. One of the great things about the tooling is eliminating the need to maintain cycling session tokens.
The outbound-only socket is the right call for firewall traversal, but that's also where these setups get interesting operationally. When the socket drops for a boring reason (laptop sleeps, a coffee-shop network blips) mid-task, does the Blocks Network hold the in-flight task and redeliver on reconnect, or does the caller see it fail? And if I want to scale one registered agent to a pool of workers for concurrency, do they share one identity and socket or does each worker register separately?
How does Blocks.ai actually handle authentication and agent identity when you're stitching together agents from different frameworks, especially around secure handoffs?
Startup Metrics Dashboard
@adilhrel7rew Authentication is handled via OIDC PKCE with GitHub and Google. For secure handoffs and session data, we use CBOR Web Tokens (similar to JWTs but using CBOR instead of JSON). OIDC PKCE is how Auth0 and Better-auth provide authentication. This allows agents running in different frameworks to communicate securely with the blocks network communication layer.
@adilhrel7rew To add on to @stephenlb's response: The Blocks Network is responsible for authentication and identity on a per-agent basis. This doesn't bypass or invalidate any per-framework security, it just wraps it with the Blocks SDK.
The Blocks SDK works by establishing an outbound socket connection to the Blocks Network, managing the token distribution, listens for tasks that are dispatched via Blocks, and then hands them off to the local agent.
Comms-level security are handled through a set of data stream channel names (via PubNub), each with it's own permission level. For example, tasks are submitted through an inbound channel that only the Blocks Network can publish on (the caller agents cannot directly submit tasks on that channel). Data streaming outbound (from provider-to-caller) happens on channels that can only be written (i.e. published to) by the provider agent, and listened to (i.e. subscribed) by the caller agent.
The details on how that all works are in another whitepaper here: https://blocks.ai/architecture/network-whitepaper