PubNub introduces Blocks.ai today, a control plane and global network to connect and control agents across all agent frameworks, providers, and APIs. Blocks Network supports all AI agent use cases without opening inbound ports, setting up tunnels, changing DNS, or modifying firewall rules. For more than a decade, PubNub has been the infrastructure and platform for real-time connectivity supporting billions of devices, now, PubNub delivers Blocks Network connecting the Internet of Agents.
How does the pricing actually work for higher message volumes, especially across multiple agent frameworks at once? Trying to figure out if it scales reasonably or gets painful fast.
@emirhan255440 Blocks is currently free for your project use. If you list your agents on the Blocks Network in "private/free" mode, only you and the people/agents you explicitly invite can access. If you list your agents in "public/paid" mode specify a per-task price, then your agents will be listed publicly on the Network tab (https://app.blocks.ai/agents) and Blocks takes 15% of the per-task revenue, you get 85%. (Note you can also list your agent as "private/paid" and Blocks takes 15% of the revenue, but your agent won't be listed in the Network tab.)
We will soon be launching an "enterprise" version that has a variety of compliance, auditing, added security, and other extensions that will have its own price tag.
The streaming part caught my eye. If my agent is doing live transcription, can multiple viewers watch the same output stream at once, or does each viewer trigger a separate task?
Startup Metrics Dashboard
@tobiasz_witalis Good catch! This is one of my favorite features too. For live transcription with an audience: declare the output stream as affinity: 'shared' on your agent card. Transcription runs once in the producer task and all viewers subscribe to the shared broadcast channel and are ref-counted. Late joiners get recent-history catch-up via replay. The stream stays alive until the last viewer leaves. You do not get a separate transcription task per viewer unless you explicitly choose 'dedicated' stream affinity.
How does pricing scale when connecting agents across multiple providers and frameworks, and is there a noticeable latency hit compared to running everything inside a single VPC?
@ali514664046464 Please see my comments on pricing above. Latency increase is generally not noticeable (especially for "pipe" tasks when you're communicating via pub/sub; that's generally adding ~20-30 ms over the WAN; your VPC can be ~5-10ms depending on physical distance, or even sometimes slower than Blocks-based latency since your VPC may extend across multiple data centers, firewalls, etc as well). Plus, there are other benefits within Blocks that make latency even lower:
Automatic compression and bundling of messages over configurable time windows.
Automatic least-loaded load balancing across multiple instances of an agent based on concurrent tasks/instance.
JWT-style signed tokens that auth in microseconds on a per-message basis.
For inference-based agents, 99+% of the latency will be within your agent as it does inference. For faster, deteministic agents that need low-latency streams and low-latency responses, Blocks is fast enough to route voice in real-time, stream video, etc, send telemetry and control signals fast enough to "feel" local with no perceived latency difference.
Nice to see PubNub finally tackling the agent connectivity mess. The no inbound ports, no tunnels angle is genuinely useful, that part of deploying agents has always been the worst.
@sabanl51707 Thanks for taking a look! We're just happy to reduce the headaches that come with connecting an agent out for builders and making it simple to use agents for callers.
How does this actually handle state sharing between agents on different frameworks, or is the focus purely on routing messages and triggering actions across them?
@demirsoyed52821 Hi Eda, great question: Blocks.ai has a few ways to maintain state:
Artifact store: Blocks has an artifact store: each agent can read/write artifacts, which can be any type of documents: text, JSON, image, video, etc. As long as agents are granted permissions, any collection of agents in a workflow can all access the artifact store.
i/o: Every agent allows for any number of required/optional fields required for invocation: session IDs, prompts, etc. This is a way to pass context between invocations of agents in a chain.
streams: these are (obviously) just another type of i/o, but defined separately because streams work differently. Agents can have any number of inbound, outbound, and bi-directional streams. So when agent-A calls agent-B, they can simply instantiate a bi-directional stream and then communicate together in real-time. The nice thing about Blocks is the mechanics of those streams (bundling, compression, binary/text, json, etc, permissions) are handled by the framework itself, so the agent code itself is super-simple.
AI agents are becoming increasingly interconnected, which also makes failures harder to diagnose. I’m curious whether Blocks.ai provides any visibility into agent behavior when something goes wrong across multiple services.
@amjad_shaik Absolutely. Our "enterprise" version of Blocks provides auditability and real-time visibility of what's being exchanged in between agents, and also allows for automatic threshold rules to be configured which trigger any automatic action to happen when these are triggered. Those actions could (a) alert someone, (b) cancel a task, (c) disable an agent, or more. Finally, Blocks also let's you upload custom JS code into our network to introspect, intercept, change, or "block" (no pun intended) agent invocation if the task parameters don't meet your expected thresholds.
A built-in cost dashboard per agent would be really useful, showing token spend and API call counts across providers in one place. Would make it way easier to keep an eye on which agents are driving up the bill and where to optimize.
@toprak967471 Makes sense...however Blocks is targeted at solving the agent accessibility, control, and scaling. We are agnostic to what happens inside the agent itself; we support agents that take hours to run, or ones that finish in milliseconds. So per-agent inference costs are probably out of scope for where we're taking the product in future.