Blog

Most organisations do not have an agent problem. They have a control problem. The agents work. The orchestration frameworks are mature enough to prototype against. What breaks down is everything that sits between a working proof-of-concept and a system you would trust to interact with production data, regulated customer records, industrial hardware, or multi-tenant infrastructure at scale.

This is not a criticism of the frameworks themselves. It is a recognition that intelligence and governance are different engineering concerns — and that most agentic tooling has historically solved for the former while leaving the latter to whoever is doing the deployment. NemoClaw changes that equation, and understanding why matters if you are serious about putting agentic systems into production environments that carry real consequences.

OpenClaw Started the Shift

Before OpenClaw, the dominant pattern for enterprise AI was the single-prompt wrapper: a user sends a message, an LLM returns a response, a human decides what to do with it. It was useful. It was also fundamentally passive. The organisation retained full control because the model never touched anything — it just talked.

OpenClaw changed how organisations think about the execution boundary. By introducing practical agent coordination — tool-using agents that can plan, remember context across sessions, call external APIs, schedule recurring tasks, and delegate to specialist sub-agents — it created a model where AI systems could act, not just advise. That shift in framing is significant. Teams began to see AI not as a chat interface bolted onto their workflows, but as an execution layer embedded within them.

That is the right direction. It is also where the control problem begins.

The Enterprise Gap

The gap between an OpenClaw proof-of-concept and a production deployment is not primarily a capability gap. It is a governance gap. When enterprise teams push agentic systems beyond the sandbox, they encounter the same set of problems consistently.

• Agents accessing the wrong systems. Without explicit access controls, agents follow their instructions to wherever the tooling allows, including production databases, sensitive APIs, and external services that have no business being in an automated workflow.
• No consistent policy enforcement. Rules defined in a system prompt are not policy. They are suggestions. They drift, they get overridden by instruction injection, and they produce no audit artefact that a compliance team can review.
• Sensitive data routed to the wrong model. An agent calling a frontier cloud model to process personally identifiable data, legally privileged content, or regulated financial records may be in breach of data residency obligations before the response even arrives.
• Weak isolation between tenants, teams, or environments. In a multi-tenant SaaS platform, agents operating across shared infrastructure must be scoped absolutely. A failure in tenant isolation is not a bug — it is a data breach.
• Lack of deterministic network restrictions. Agents that can make outbound API calls without an allow-listed destination set are a lateral movement vector. In OT and ICS environments, this is not a theoretical risk.
• Poor auditability for regulated industries. Financial services, healthcare, critical infrastructure, and government deployments require more than logs. They require verifiable, tamper-evident records of what decisions were made, by which agent, under which policy, and with what data.
• No standard way to blend private, local, and custom models. Production deployments typically require a mixture of model types. Without a structured routing layer, this becomes an integration problem solved differently by every team, with no consistent privacy or cost governance.

Enterprise AI is not just about what agents can do. It is about what they are allowed to do, where they can do it, and how those decisions are enforced — consistently, inspectably, and at scale.

How NemoClaw Makes OpenClaw Enterprise-Ready

NemoClaw sits between the agent orchestration layer and the systems those agents interact with. It is not a replacement for OpenClaw. It is the control plane that OpenClaw was never designed to be. It addresses four distinct requirements that any serious enterprise deployment will eventually hit.

Policy Engine Integration

Prompts are not governance. A well-crafted system prompt can guide agent behaviour, but it cannot enforce it. Policy engines externalise decision logic into a form that is structured, versioned, auditable, and testable — independently of the model generating the action proposal.

With NemoClaw’s policy engine integration, access decisions are explicit: which agents can invoke which tools, under which roles, in which contexts, subject to which approval thresholds. A procurement_agent authorised to raise purchase requests up to £50,000 cannot, by prompt instruction alone, be talked into raising one for £500,000. The policy layer rejects the action before it reaches the execution surface.

For compliance teams, this matters because policy becomes an artefact. It can be reviewed, audited, version-controlled alongside your infrastructure code, and tested in isolation. It satisfies the EU AI Act’s Article 9 requirements for risk management and Article 14’s human oversight provisions in a way that no system prompt ever could.

Network Guardrails

Agentic systems need hard runtime boundaries, not soft behavioural ones. The network is where those boundaries are made real.

NemoClaw’s network guardrail layer enforces:

• Allow-listed API destinations — agents can only call endpoints that have been explicitly permitted for their role and context.
• Outbound access controls that prevent lateral movement into adjacent systems, including internal services an agent has no legitimate reason to reach.
• Service identity enforcement, so that agents authenticating to downstream systems present verifiable, scoped credentials rather than shared API keys.
• Segmented network zones that separate agent traffic from human-facing services, data stores, and operational technology interfaces.
• Zero-trust principles applied at the agent workload level — every connection is authenticated and authorised, regardless of where it originates.

For IoT, OT, and industrial control system environments, network guardrails are not optional hardening. They are the architectural requirement that makes deployment permissible at all. An agent that can reach a SCADA endpoint without an explicit, audited permission is a liability that no responsible infrastructure team should accept.

Privacy Router

The privacy router is the decision layer that determines where a given prompt or task should execute. It operates before the inference call is made, evaluating a set of routing criteria to select the appropriate model endpoint.

Routing decisions factor in:

• Data sensitivity classification — is the payload personally identifiable, legally privileged, regulated, or commercially sensitive?
• Tenant or customer policy — what are the contractual and jurisdictional commitments made to the entity whose data this is?
• Geographic and jurisdictional constraints — GDPR, CCPA, and sector-specific data residency obligations are enforced at the routing layer, not left to human review.
• Model capability requirements — does this task need frontier-level reasoning, or will a smaller, cheaper, local model produce an acceptable result?
• Latency requirements — for edge and real-time workloads, cloud inference may simply be too slow regardless of sensitivity.
• Cost governance — routing expensive tasks to premium models only when the task genuinely warrants it is a commercial discipline, not an optimisation afterthought.

Privacy-aware routing is not primarily a cost management tool. It is the mechanism by which trust boundaries are enforced across a system that touches data belonging to different organisations, jurisdictions, and sensitivity categories simultaneously.

Custom Model Support

General-purpose frontier models are remarkable at general-purpose reasoning. They are frequently the wrong tool for the job in specialised enterprise contexts — not because they are insufficiently intelligent, but because they have not been trained on the language, processes, knowledge, or data that makes a given business domain work.

NemoClaw’s custom model support enables a structured mixed-model strategy:

• Public frontier models for high-complexity synthesis, multi-step reasoning, and tasks where breadth of knowledge matters.
• Private hosted models for controlled workloads where data must not leave your infrastructure boundary but reasoning complexity is still substantial.
• Local or edge models via Ollama or equivalent for privacy-critical, latency-sensitive, or air-gapped deployments where cloud inference is architecturally unacceptable.
• Custom fine-tuned models for domain-specific tasks — medical coding, industrial fault classification, legal document review, or proprietary product knowledge — where a specialised model consistently outperforms a general one at a fraction of the inference cost.

The alternative to a structured mixed-model strategy is not simplicity. It is an accumulation of one-off integrations built by individual teams, with no consistent routing logic, no privacy enforcement, and no cost visibility.

Reference Architecture

The following describes how Virtually Pro approaches a production NemoClaw deployment for an enterprise client operating across cloud, edge, and OT environments.

Agent pods run in Kubernetes namespaces scoped to tenant or environment. NemoClaw sits as a sidecar and network policy enforcer: every action proposal from an OpenClaw agent passes through the policy engine before execution, and every model invocation is evaluated by the privacy router before the inference request is dispatched.

Network egress from agent pods is controlled by Kubernetes NetworkPolicy resources generated from NemoClaw’s allow-list configuration. An agent handling customer support queries cannot reach the financial reconciliation API — not because we trust the agent not to try, but because the network layer physically prevents it.

n8n handles event-driven workflow triggers: an agent detecting an anomaly fires an n8n webhook, which orchestrates notifications, ticketing, and escalation without any of that logic living inside the agent itself. ThingsBoard provides the telemetry substrate for IoT and industrial agents — MQTT ingestion, time-series storage, and threshold alerting that feeds agent scheduling without requiring cloud inference for every sensor reading.

Why It Matters in Edge, IoT, and SaaS

These are not independent concerns. The same architecture that improves operational control in a factory also improves commercial viability in a SaaS platform. The governance layer is not overhead — it is the product feature that unlocks regulated industries, enterprise procurement, and multi-region deployment simultaneously.

Final Position

The organisations that will operationalise agentic systems successfully are not the ones with the most powerful agents. They are the ones who understood early that governance is an architectural requirement, not a post-deployment patch.

OpenClaw gives you the orchestration model. NemoClaw gives you the control plane to make that model work in environments where the stakes are real — regulated industries, multi-tenant platforms, industrial systems, and edge deployments where network reliability is limited and inference latency is measured in milliseconds.

Getting this architecture right requires experience across domains that rarely sit in the same team: enterprise networking, Kubernetes operations, edge AI deployment, SaaS platform design, security boundary engineering, IoT integration, and compliance-led infrastructure design. That is precisely what Virtually Pro brings to these engagements.

We do not parachute in with a framework recommendation and a slide deck. We design the policy layer, instrument the network guardrails, configure the privacy router, build the model registry, wire in the workflow automation, and hand over a system that your operations team can own, your security team can inspect, and your compliance team can evidence.

Krzysztof Wiselka is the founder of Virtually Pro Ltd, an Edinburgh IT consultancy specialising in cyber security, cloud infrastructure, and enterprise AI architecture.