{"id":222,"date":"2026-10-30T12:51:42","date_gmt":"2026-10-30T12:51:42","guid":{"rendered":"https:\/\/www.dobryakov.net\/blog\/222\/"},"modified":"2026-10-30T12:51:42","modified_gmt":"2026-10-30T12:51:42","slug":"building-on-blocks-network","status":"publish","type":"post","link":"https:\/\/www.dobryakov.net\/blog\/222\/","title":{"rendered":"Building on Blocks Network \u2014 a hands-on field report on the “Internet of Agents”"},"content":{"rendered":"

Every team I work with is suddenly shipping AI agents. The agents are the easy part. The hard part \u2014 the part I spent years solving for ordinary services \u2014 is the layer underneath: how does an agent built by one team get discovered, called, and governed<\/strong> by another, without everyone rebuilding the same plumbing and without security signing off on a free-for-all?<\/p>\n

Blocks Network (from PubNub) pitches itself as exactly that substrate \u2014 a network for agent-to-agent communication with routing, discovery, presence and an economy layer. So instead of reading the marketing, I built on it. This is a field report from taking it from npm install<\/code> to a live two-agent call, written for the four people who actually have to approve this kind of thing: the developer, the DevOps\/platform engineer, the analyst\/architect, and the security reviewer.<\/p>\n

Everything below is what I observed on the real platform on a Linux box (Node v20.19.5, Blocks CLI 1.0.24). Where I couldn't verify something, I say so.<\/p>\n

<\/p>\n

What I built<\/h2>\n

Two small agents, deliberately scoped so the mechanics<\/em> are the subject, not the AI:<\/p>\n

    \n
  1. delivery_slot_estimator<\/code><\/strong> \u2014 a deterministic specialist. Given a region, parcel weight and service tier, it returns a delivery window. No LLM: same input, same output. That determinism is the point \u2014 it's the kind of agent another system can put in a critical path and trust.<\/li>\n
  2. order_intake<\/code><\/strong> \u2014 an orchestrator. It validates an incoming order, derives region and total weight from the line items, then calls delivery_slot_estimator<\/code> over the network<\/strong> and folds the delivery window into a confirmed order.<\/li>\n<\/ol>\n

    That second agent is the whole reason a network like this exists: order_intake<\/code> doesn't re-implement delivery logic \u2014 it discovers and reuses<\/em> a capability another team could own. If you want the broader map of how agent protocol layers stack, I wrote that separately in The AI Agent Protocol Stack<\/a>.<\/p>\n

    The developer view<\/h2>\n

    The scaffold is clean. blocks init <name> --yes --language node<\/code> produces three files \u2014 agent-card.json<\/code>, handler.ts<\/code>, trigger.ts<\/code> \u2014 plus a .env<\/code>. The agent card is the contract: identity, task kinds, typed IO, runtime limits.<\/p>\n

    A handler is just a function:<\/p>\n

    export default async function handler(task, ctx) {\n  const raw = task.requestParts?.[0]?.text;\n  const input = JSON.parse(raw ?? "{}");\n  \/\/ ...compute...\n  return { artifacts: [{ data: JSON.stringify(result), mimeType: "application\/json" }] };\n}<\/code><\/pre>\n
    Three things developers should know going in:<\/p>\n