How we clear it:<\/strong> lean on private registration plus ownership \u2014 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.<\/p>\n6. "How much of the 'typed, structured' story is real?"<\/h3>\n If you oversell the developer ergonomics, a technical reviewer will catch it and then distrust everything else you said.<\/p>\n
How we clear it \u2014 by being straight about the friction I hit in the build:<\/strong><\/p>\n\nThe card declares application\/json<\/code> IO with a JSON Schema, but in code the SDK part helpers are textPart<\/code> \/ filePart<\/code> only \u2014 there is no jsonPart<\/code><\/strong>. Structured IO is really a JSON string you stringify<\/code> and parse<\/code> yourself.<\/li>\nThe card's input schema is a restricted subset of JSON Schema<\/strong>; a valid "pattern"<\/code> keyword was rejected by blocks check<\/code>, and the allowed-keyword list isn't documented \u2014 you find the edge by hitting it.<\/li>\nOn the plus side, a handler is a plain function you can unit-test offline<\/strong> with a mock task \u2014 no auth, no network. That's a real governance win: logic can be reviewed and tested outside the network entirely.<\/li>\n<\/ul>\nTelling the reviewer the rough edges before<\/em> they find them is the single highest-trust move in this whole process.<\/p>\nThe internal estate you're really integrating with<\/h2>\n Advocacy talks about "the company." Enablement talks about the systems<\/em>, because that's where an A2A call either lands or dies. Here's a realistic inventory for the archetype \u2014 a vertically integrated sleep-products manufacturer-retailer. Yours will differ in the names, not the shapes:<\/p>\n\nERP core<\/strong> (SAP S\/4HANA or similar) \u2014 finance, procurement, master data. The system of record and the one nobody touches lightly.<\/li>\nMES<\/strong> \u2014 manufacturing execution on the factory floor; schedules lines, tracks work orders, lives in the OT segment.<\/li>\nAPS \/ supply-chain planning<\/strong> \u2014 demand and production planning, the thing that decides when<\/em> an order can even be built.<\/li>\nWMS<\/strong> \u2014 warehouse management; stock, locations, picking.<\/li>\nTMS<\/strong> \u2014 transport management for the owned fleet; routing, load planning, delivery slots.<\/li>\nField-service \/ install-crew scheduling<\/strong> \u2014 the assembly teams that finish the customer promise.<\/li>\n1C<\/strong> \u2014 accounting, payroll, HR (the regional reality around the SAP core).<\/li>\nCRM<\/strong> \u2014 customer records across retail and online.<\/li>\nE-commerce platform<\/strong> \u2014 the web\/app storefront and its order pipeline.<\/li>\nRetail POS<\/strong> \u2014 in-store cash and order capture.<\/li>\nPIM \/ product catalog<\/strong> \u2014 product data, configurations, options.<\/li>\nContact-centre \/ omnichannel telephony<\/strong> \u2014 calls, chat, call recordings.<\/li>\nLoyalty platform<\/strong> \u2014 points, tiers, customer identifiers.<\/li>\nBI \/ DWH<\/strong> \u2014 the data warehouse and reporting layer.<\/li>\nIAM \/ Active Directory<\/strong> \u2014 identity, SSO, the gate in front of all of the above.<\/li>\n<\/ol>\nA delivery-window agent doesn't live in a vacuum \u2014 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.<\/p>\n
The two or three you won't crack first<\/h2>\n Not every box is equally hard. Three of them will fight you, and it's worth naming why<\/em> so nobody wastes six months pushing on the wrong one:<\/p>\n\nThe ERP core (SAP).<\/strong> 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<\/em> SAP early \u2014 you integrate alongside it, read-only, through a fa\u00e7ade.<\/li>\nMES \/ the factory floor (OT).<\/strong> 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 \u2014 and rightly so.<\/li>\nThe contact-centre \/ telephony stack.<\/strong> 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.<\/li>\n<\/ul>\nThe move is not to attack these. It's to pick a process that reads reference data derived from them<\/em> without touching them live \u2014 and that's where enablement comes in.<\/p>\nTechnical enablers: what has to exist before you can even try<\/h2>\n 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<\/em>.<\/p>\n
Here's the sequence I'd stand up, roughly in dependency order:<\/p>\n
\nA controlled egress path.<\/strong> 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 \u2014 the SDK simply can't reach the network.<\/li>\nAn agent landing zone (DMZ \/ dedicated segment).<\/strong> Handlers need somewhere to run that is not<\/em> 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\u00e7ades below \u2014 never direct lines into SAP or OT.<\/li>\nAn integration fa\u00e7ade \/ anti-corruption layer.<\/strong> 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<\/em> the reference data a pilot needs \u2014 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.<\/li>\nService identity and secrets management.<\/strong> BLOCKS_API_KEY<\/code> in a gitignored .env<\/code> 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 \u2014 and a hard rule that keys never live in code or images.<\/li>\nA data contract + DLP gate.<\/strong> 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<\/em> \u2014 it carries region, weight and tier, no customer PII.<\/li>\nObservability into the SIEM.<\/strong> 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.<\/li>\nA governed delivery pipeline for agent code.<\/strong> Enabler: blocks check<\/code> wired into CI, code review on handlers, dependency\/SBOM scanning, and promotion from a masked non-prod environment to the landing zone \u2014 so agent code goes through the same change gate as everything else.<\/li>\nA masked non-prod environment.<\/strong> Enabler: a sandbox fed with masked\/synthetic data mirroring the fa\u00e7ade APIs, so the pilot can be built and demoed without a single production record leaving anywhere.<\/li>\n<\/ol>\nRead that list top to bottom and the real insight falls out: the hardest part of adopting an agent network isn't the agents.<\/strong> It's egress, identity, a read-only fa\u00e7ade and an audit trail \u2014 the same enablers any serious external integration needs. Blocks Network doesn't exempt you from them; the value is that once those enablers exist<\/em>, adding the next agent is cheap, because the plumbing is already paid for.<\/p>\nThat 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 \u2014 and the first agent is simply the thing that proves they work.<\/p>\n
How we actually get in the door<\/h2>\n 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<\/strong> \u2014 logistics or the contact centre \u2014 and solve one thing.<\/p>\n\nPick the lowest-risk high-value process.<\/strong> The delivery-window estimate is ideal: it's deterministic and LLM-free<\/strong>, 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.<\/li>\nPilot private, free, on-demand.<\/strong> Exactly the posture the build already uses \u2014 nothing public, nothing always-on.<\/li>\nInstrument it.<\/strong> Capture concrete before\/after metrics: time-to-quote a delivery window, error rate versus the manual process, number of cross-department handoffs removed.<\/li>\nRun the security review in parallel, scoped to the pilot.<\/strong> Because there's no personal data in play, residency and compliance review the architecture, not a live data flow.<\/li>\nOnly then propose scale.<\/strong> 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.<\/li>\n<\/ol>\nThe one principle underneath all of it<\/h2>\n A conservative enterprise doesn't buy capability \u2014 it buys the absence of unpleasant surprises<\/strong>. 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.<\/p>\nThat's not a weaker pitch. In a room like this, it's the only one that survives contact with the second meeting.<\/p>\n","protected":false},"excerpt":{"rendered":"
An enablement playbook for a large, risk-averse, vertically integrated company \u2014 mapping the internal estate, naming the systems you won’t crack first, and building the egress, identity, fa\u00e7ade and audit layers that turn “nice demo” into “approved pilot.”<\/p>\n","protected":false},"author":0,"featured_media":229,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[209,24],"tags":[116,26,221,225,29,224],"class_list":["post-226","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-ai-agents","category-ai-engineering","tag-a2a","tag-ai-agents","tag-blocks-network","tag-enablement","tag-enterprise","tag-security"],"aioseo_notices":[],"aioseo_head":"\n\t\t\n\t
![\"From](\"https:\/\/www.dobryakov.net\/blog\/wp-content\/uploads\/2026\/10\/enabling-blocks-network-enterprise-diagram.png\")
<\/p>\n