Enabling Blocks Network inside a conservative enterprise — the plumbing before an agent network is allowed

The easy version of "adopt an agent network" is a demo on a laptop. The hard version is the one that pays: getting that network approved, piloted and scaled inside a big, conservative company that has a lot to lose.

Picture the archetype. A vertically integrated manufacturer-retailer: its own factories, its own warehouses and trucks, its own stores, its own contact centre. The IT estate is mature but heavy — an ERP at the core, a patchwork of line-of-business systems around it, home-grown glue holding the seams together. There is a security function with veto power, a procurement function that owns the contract, and a culture whose first instinct is "prove this won't break sales during peak season."

This is a playbook for that company. Not the marketing pitch — the actual sequence of questions you get asked, in the order you get asked them, and the honest answer to each. I'll keep the vendor's claims, the things I verified in a build, and the things that are spec-only strictly separate, because in a room like this, blurring them is how you lose the room.

The thing we're actually proposing

Blocks Network (from PubNub) is a substrate for agent-to-agent (A2A) communication: discovery, routing, presence and an economy layer so an agent built by one team can be found, called and governed by another without everyone rebuilding the same plumbing. The hands-on field report from the build itself is in Building on Blocks Network.

To make it concrete I built two small agents and ran a live A2A call between them:

delivery_slot_estimator — a deterministic specialist. Region, parcel weight, service tier in; a delivery window out. No LLM, so same input, same output.
order_intake — an orchestrator that validates an order, derives region and weight, then calls delivery_slot_estimator over the network and folds the window into a confirmed order.

For the archetype company, read that as: "when will the order actually be built, shipped and installed?" — today a chain of phone calls and spreadsheet exports between production, warehouse, logistics and the install crews. That's the shape of the first win, and I'll come back to why it's the right pilot.

The questions you will be asked — and the answers

1. "Where do our data physically go?"

This is the first question and the one that decides everything. PubNub is an external network, and this company has personal data and commercial secrets. So the honest framing is a table with three columns — claim, and basis:

Verified in the build: agents can be registered private, and providers are started on demand. There is no requirement to expose anything on a public marketplace.
Vendor documentation: encryption in transit/at rest and the compliance posture — cite the doc, label it as the vendor's claim, do not present it as something you tested.
Spec-only: anything described in the spec but not exercised in the pilot stays flagged as such.

How we clear it: put this table on slide one, not slide ten. Security respects "here is what I proved, here is what the vendor asserts, here is what neither of us has tested yet" far more than a confident blanket "it's secure." Then scope the pilot so it touches no personal data at all (see the pilot choice below), which lets the data-residency review proceed in parallel instead of blocking.

2. "Will we be exposed on a public agent marketplace?"

How we clear it: this one is already answered by the build. Both agents are registered private + free; providers come up on demand. The "we'll be listed in someone's public directory" fear is false, and you can demonstrate that, not just assert it.

3. "What happens if PubNub raises the price, changes terms, or disappears?" (vendor lock-in)

The procurement function's job is to assume the vendor is temporary.

How we clear it:

The agent contract is portable. agent-card.json is just a typed IO contract — identity, task kinds, input/output schemas, runtime limits. The business logic lives in your handler code, which is ordinary TypeScript you own.
Point at the Enterprise deployment path (self-hosted installation) as the escape hatch from the public network, and be clear about which capabilities are verified there versus assumed.
Keep a documented fallback: because the specialist agent is deterministic and its logic is yours, it can be lifted off the network and run in-process if you ever have to.

4. "Will this fall over during peak season?" (reliability / SLA)

A conservative operator cares more about uptime than features. "Novel" is a negative word here.

How we clear it: don't put the network on a critical, revenue-bearing path in the pilot. Choose a process where a failure degrades gracefully to today's manual fallback. Define the SLA conversation explicitly — latency, timeout behaviour, what the orchestrator does when a called agent doesn't answer in time — and show the timeout/terminal-wait handling in the handler so it's visibly engineered, not hoped for.

5. "How is this governed? Who can call what?"

Central IT will ask who authorises an agent-to-agent call and how it's audited. For the broader shape of bounded autonomy and policy gates, see Agentic AI Governance.

How we clear it: lean on private registration plus ownership — a call carries the owner identity, and discovery is scoped, not open. Be honest about the boundary between what's enforced by the platform today and what you'd wrap with your own policy layer. Name the gaps; don't paper over them.

6. "How much of the 'typed, structured' story is real?"

If you oversell the developer ergonomics, a technical reviewer will catch it and then distrust everything else you said.

How we clear it — by being straight about the friction I hit in the build:

The card declares application/json IO with a JSON Schema, but in code the SDK part helpers are textPart / filePart only — there is no jsonPart. Structured IO is really a JSON string you stringify and parse yourself.
The card's input schema is a restricted subset of JSON Schema; a valid "pattern" keyword was rejected by blocks check, and the allowed-keyword list isn't documented — you find the edge by hitting it.
On the plus side, a handler is a plain function you can unit-test offline with a mock task — no auth, no network. That's a real governance win: logic can be reviewed and tested outside the network entirely.

Telling the reviewer the rough edges before they find them is the single highest-trust move in this whole process.

The internal estate you're really integrating with

Advocacy talks about "the company." Enablement talks about the systems, because that's where an A2A call either lands or dies. Here's a realistic inventory for the archetype — a vertically integrated sleep-products manufacturer-retailer. Yours will differ in the names, not the shapes:

ERP core (SAP S/4HANA or similar) — finance, procurement, master data. The system of record and the one nobody touches lightly.
MES — manufacturing execution on the factory floor; schedules lines, tracks work orders, lives in the OT segment.
APS / supply-chain planning — demand and production planning, the thing that decides when an order can even be built.
WMS — warehouse management; stock, locations, picking.
TMS — transport management for the owned fleet; routing, load planning, delivery slots.
Field-service / install-crew scheduling — the assembly teams that finish the customer promise.
1C — accounting, payroll, HR (the regional reality around the SAP core).
CRM — customer records across retail and online.
E-commerce platform — the web/app storefront and its order pipeline.
Retail POS — in-store cash and order capture.
PIM / product catalog — product data, configurations, options.
Contact-centre / omnichannel telephony — calls, chat, call recordings.
Loyalty platform — points, tiers, customer identifiers.
BI / DWH — the data warehouse and reporting layer.
IAM / Active Directory — identity, SSO, the gate in front of all of the above.

A delivery-window agent doesn't live in a vacuum — to give a credible install date it conceptually crosses APS (can it be built?), WMS (is it in stock?), TMS (when can we route it?) and field-service (when's a crew free?). That's exactly why it's a good showcase: it's a natural orchestration seam. But it also means the enablement question is real.

The two or three you won't crack first

Not every box is equally hard. Three of them will fight you, and it's worth naming why so nobody wastes six months pushing on the wrong one:

The ERP core (SAP). It's the system of record, it's under change-freeze windows, it's wrapped in segregation-of-duties controls, and it's usually owned by an external integrator whose contract makes every change slow and expensive. It speaks BAPI/RFC/OData, not "agents." You do not integrate an agent network into SAP early — you integrate alongside it, read-only, through a façade.
MES / the factory floor (OT). This is operational technology, not IT. Different network segment, often air-gapped, real-time and safety-adjacent, governed by plant engineering rather than the CISO. An outbound call to a public cloud network from the OT zone is close to a non-starter in year one — and rightly so.
The contact-centre / telephony stack. Tempting because the orchestration value is obvious, but it's saturated with personal data and regulated call recordings, and it's real-time with hard latency expectations. The data-governance review alone will outlast your pilot.

The move is not to attack these. It's to pick a process that reads reference data derived from them without touching them live — and that's where enablement comes in.

Technical enablers: what has to exist before you can even try

This is the part advocacy skips and enablement owns. Between "the demo runs on my laptop" and "a regulated enterprise can run a pilot" sits a backlog of plumbing that has nothing to do with agents and everything to do with whether agents are allowed.

Here's the sequence I'd stand up, roughly in dependency order:

A controlled egress path. A segmented corporate network does not let arbitrary outbound traffic to a public real-time cloud through by default. Enabler: a reviewed firewall/proxy allowlist to the PubNub/Blocks endpoints, with a decision on TLS inspection (the SDK uses a persistent connection, so document how it traverses the proxy). Without this, nothing else matters — the SDK simply can't reach the network.
An agent landing zone (DMZ / dedicated segment). Handlers need somewhere to run that is not the core. Enabler: a small isolated runtime environment (container platform or VM segment) with outbound-only access to Blocks and inbound access only to the façades below — never direct lines into SAP or OT.
An integration façade / anti-corruption layer. Agents must never call SAP, MES or the CRM directly. Enabler: thin read-only APIs (REST over OData/BAPI, or a read replica / materialised view) that expose just the reference data a pilot needs — e.g. a "production lead time by SKU/region" and "stock availability" endpoint. This is the single biggest enabler and the one that de-risks the ERP conversation entirely.
Service identity and secrets management. BLOCKS_API_KEY in a gitignored .env is fine for a build; it is not fine in production. Enabler: agent credentials issued as managed service identities, stored in a secrets vault (Vault / cloud KMS / SAP secure store), with rotation — and a hard rule that keys never live in code or images.
A data contract + DLP gate. The network can only carry what's classified as allowed to leave the perimeter. Enabler: a data-classification tag on every field an agent exposes, plus a DLP rule that blocks personal data from entering an A2A payload. For the delivery pilot this is easy to pass by design — it carries region, weight and tier, no customer PII.
Observability into the SIEM. Security can't approve what it can't see. Enabler: structured logging and tracing of every agent-to-agent call (who called what, when, with what task id, terminal state) shipped to the existing SIEM, so an A2A call is as auditable as any internal API call.
A governed delivery pipeline for agent code. Enabler: blocks check wired into CI, code review on handlers, dependency/SBOM scanning, and promotion from a masked non-prod environment to the landing zone — so agent code goes through the same change gate as everything else.
A masked non-prod environment. Enabler: a sandbox fed with masked/synthetic data mirroring the façade APIs, so the pilot can be built and demoed without a single production record leaving anywhere.

Read that list top to bottom and the real insight falls out: the hardest part of adopting an agent network isn't the agents. It's egress, identity, a read-only façade and an audit trail — the same enablers any serious external integration needs. Blocks Network doesn't exempt you from them; the value is that once those enablers exist, adding the next agent is cheap, because the plumbing is already paid for.

That reframes the pitch for the enablement audience: you're not asking for a leap of faith on AI. You're asking to stand up four pieces of boring, reusable infrastructure — and the first agent is simply the thing that proves they work.

How we actually get in the door

You do not walk into central IT and ask to adopt a network. You find one hungry department with a real pain and its own budget — logistics or the contact centre — and solve one thing.

Pick the lowest-risk high-value process. The delivery-window estimate is ideal: it's deterministic and LLM-free, so the security review is dramatically smaller; it touches reference data, not personal data; and the business value ("tell the customer a credible install date") is obvious to a non-technical sponsor.
Pilot private, free, on-demand. Exactly the posture the build already uses — nothing public, nothing always-on.
Instrument it. Capture concrete before/after metrics: time-to-quote a delivery window, error rate versus the manual process, number of cross-department handoffs removed.
Run the security review in parallel, scoped to the pilot. Because there's no personal data in play, residency and compliance review the architecture, not a live data flow.
Only then propose scale. With a working pilot, real numbers and a security team that was told the truth from day one, the second use case (contact-centre orchestration, availability + delivery + claims status) is an expansion, not a fresh fight.

The one principle underneath all of it

A conservative enterprise doesn't buy capability — it buys the absence of unpleasant surprises. Every answer above works for the same reason: it separates what was proven from what was claimed, picks a pilot where failure is cheap, and hands the veto-holders the bad news before they have to dig for it.

That's not a weaker pitch. In a room like this, it's the only one that survives contact with the second meeting.

Enabling Blocks Network inside a conservative enterprise — the plumbing you have to build before an agent network is even allowed