ZGI Logo
返回博客

Why Enterprises Need Their Own Agent Runtime

A
Admin User

ZGI Agent Runtime architecture

The biggest difference between an agent and a chatbot is not that the answer is longer, or that the model is stronger. The difference is that an agent keeps acting inside an environment.

A chatbot is mainly a conversation interface. It receives a question, generates a response, and may cite a few knowledge sources. When enterprises evaluate a chatbot, they usually look at accuracy, hallucination, tone, knowledge coverage, and compliance wording.

Agents are different.

An agent can remember context, call tools, access systems, schedule tasks, create and improve skills, maintain state across multiple entry points, and act on behalf of a user or an organization. Once AI moves from "answering questions" to "getting work done", it is no longer just an input box on a product page. It becomes a software actor with identity, permissions, memory, and execution capability.

That is why enterprises need their own Agent Runtime.

Not because "runtime" sounds more platform-like, but because once agents enter the enterprise, what must be governed is no longer just text output. It is the execution boundary.

Two Signals: Hermes Agent and OpenClaw

Two recent directions are worth paying attention to.

The first is Hermes Agent. Nous Research built Hermes Agent as an open-source, self-hostable personal agent that grows with use. It supports Telegram, Discord, Slack, WhatsApp, Signal, Email, CLI, and other entry points. It has long-term memory. It can use MCP tools, subagents, scheduled tasks, and web browsing. For execution, it supports multiple backends: Docker, Modal, Daytona, Singularity, and others can provide isolated execution environments, while local mode is closer to direct execution. More importantly, Hermes puts "creating skills from experience, improving skills through use, and continuously accumulating user preferences and knowledge" into the product design.

Hermes Agent shows that this kind of agent product is no longer just a model plus a chat UI. It is a runtime system made of memory, tools, skills, scheduling, subtasks, sandboxing, and multiple entry points.

That is valuable as a product signal. It shows the complete shape of an agent: not a one-time answer, but long-term companionship; not a single page, but multiple channels; not a fixed prompt, but accumulated skills; not only speaking, but calling tools, executing tasks, and learning over time.

The second signal is OpenClaw.

OpenClaw's ClawHub skill ecosystem shows the other side of an agent skill marketplace. Unit 42 recently analyzed ClawHub and found malicious skills that bypassed automatic scanning, including a macOS infostealer, scanning-evasion samples, and agentic abuse cases that used the agent's autonomous recommendation and execution capabilities for monetization. Unit 42's conclusion matters because the risk of agent skills is not only traditional malicious code. A skill can use natural-language instructions, installation steps, tool permissions, and the agent's runtime context to turn the agent itself into part of the attack chain.

This is not a criticism of OpenClaw, and it does not mean Hermes Agent has the same issue. They represent two different signals.

Hermes Agent shows that the agent product shape is maturing. Personal agents are beginning to have long-term memory, skill learning, tool use, and multi-channel execution.

OpenClaw shows that once agents can install skills, call tools, and access local or business systems, permissions, supply chain, isolation, and audit become core concerns.

Put these two signals together, and the enterprise requirement becomes clear.

Enterprise Agent Runtime signals

Personal agents can explore experience aggressively. Enterprise agents must have governance boundaries.

This is where ZGI is positioned. ZGI is a B2B, enterprise-grade Agent Runtime. It is not a personal assistant, and it is not a normal workflow canvas. It gives enterprises their own agent control plane, so they can build agent capabilities inside their own boundaries for identity, permissions, knowledge, models, tools, audit, and APIs.

Here, Agent Runtime does not simply mean "a backend service that runs agents". For enterprises, it is closer to an agent control plane. It manages agent identity, tool permissions, knowledge ACLs, model policies, sandboxing and network egress, approval flows, execution traces, version releases, rollbacks, stop switches, cost, and quotas. Without those controls, the more useful an agent becomes, the more likely it is to become a new risk entry point.

Prompting and Model Safety Are Not Enough

Many teams start their first agent project from prompt design and model safety policies.

That is necessary. System prompts, refusal rules, content filters, output format constraints, and model safety capabilities all matter. But they cannot replace the runtime.

The core risks of enterprise agents are often not language-level risks.

Whether an agent can read a knowledge base should not be decided by a prompt. Whether it can call a production API should not be left to the model's moment-by-moment judgment. Whether it can send data to an external service should not depend only on a natural-language instruction like "please do not leak data". Whether it can create a new skill, install dependencies, execute code, send email, or modify a CRM should not be something the model decides on its own.

These are not copywriting problems. They are systems problems.

Enterprises need hard boundaries: identity, permissions, approvals, isolation, audit, versions, and rollback. A prompt can express intent. The runtime must enforce constraints.

Hermes Agent's security documentation reflects this point. It places security design across multiple layers, including tool permission approvals, container isolation, MCP credential filtering, context file scanning, cross-session isolation, and input sanitization. These capabilities cannot be replaced by "making the model behave better". They belong to runtime control.

OpenAI's monitoring work for internal coding agents also points to the same pattern. What needs attention is agentic behavior: unauthorized data transfer, destructive actions, prompt injection, sabotage, scheming, and other risk categories. This needs to be understood carefully: some of these are monitoring categories, not claims that every category has already appeared as a real incident. But the framework itself makes the point. Agent risk emerges in real workflows with rich tools, complex context, and persistent sessions, not in a single round of question answering.

So when enterprises adopt agents, they should not only ask, "Is the model strong enough?" They should ask: under what identity does this agent run? What permissions does it have? Where do its tools come from? What data can it see? Is every action traceable? Which actions require human approval? If something goes wrong, can we replay, pause, revoke, or isolate it?

The answer to those questions is the Agent Runtime.

The Boundary of Workflow

When enterprises start building AI automation, workflow is often the first thing they reach for.

That is reasonable. Workflows have clear strengths: they are structured, visible, controllable, and easy to debug. They are well suited for approvals, compliance, form processing, data synchronization, and fixed business processes.

But workflows also have boundaries.

As nodes increase, the path becomes longer. Each node waits for upstream output, maps parameters, handles errors, and passes results downstream. A task that looks simple can easily become ten or twenty nodes. What usually increases end-to-end latency is not the node count alone. It is sequential dependency, multiple model calls, external tool waiting, retries, human approvals, and paths that cannot be parallelized. More nodes also mean more failure points, more parameter mapping, more exception paths, and higher maintenance cost.

Workflow has another problem: it works well when the process is clear, but it becomes clumsy when the task is highly dynamic.

If the task path changes each time, or if the system needs to select tools, decompose subtasks, and create new steps based on context, a pure workflow becomes heavy. You have to draw every branch in advance, configure every node, and enumerate every exception. The result may not be an intelligent system. It may be a complex, slow, hard-to-maintain diagram.

That is why an enterprise Agent Runtime should not be reduced to a workflow builder.

Enterprises need Agent plus Workflow.

The agent dynamically understands the task, chooses tools, adds context, retrieves knowledge, and creates an action plan. The workflow fixes high-risk, deterministic, auditable steps into reliable execution paths. In other words, the agent provides flexibility. The workflow provides control.

This is not an either-or choice. LangChain's discussion of agent frameworks also emphasizes that production-grade agentic systems are often a combination of workflows and agents: use deterministic workflows where the process is clear, and introduce agents where dynamic judgment and tool selection are needed. Temporal's discussion of dynamic AI agents also shows how durable execution can record an agent's historical decisions and resume dynamic tasks after failure, instead of planning again from scratch. Enterprises do not need only a canvas or only free-form action. They need an engineering balance between dynamic decision-making and reliable execution.

ZGI does not treat workflow as the only answer. ZGI needs workflow, but it needs runtime even more: who is running, under what authority, what tools can be called, what data can be seen, when a fixed process is required, when an agent can handle the task dynamically, which steps need human approval, and which executions must be recorded and replayed.

This is the runtime layer that enterprise agent systems must add.

Workflow boundary and ZGI Runtime

Enterprises Need Their "Own" Agent Runtime

Enterprises needing their own Agent Runtime does not mean every company must build a framework from scratch. It also does not mean every model must be privately deployed.

"Own" means the enterprise must own the agent control plane.

Models may come from OpenAI, Anthropic, DeepSeek, Qwen, Nous Research, or internal deployments. Tools may come from open-source ecosystems, MCP servers, internal systems, or third-party SaaS. Knowledge may come from documents, databases, tickets, CRM, engineering platforms, and business systems. But the agent's identity, permissions, memory, execution, logs, approvals, versions, data flow, and release boundaries cannot be handed entirely to a black-box tool, and they cannot be scattered across scripts owned by different teams.

An enterprise-grade Agent Runtime should answer at least these questions.

What is the agent's identity? It should not be just a chat history inside a user's account. It should be a managed execution subject. Which workspace does it belong to? Who maintains it? Which resources can it access? Which API key does it use? Which system or user does it act on behalf of?

What can the agent do? Tool permissions should be explicit, not enabled by default. Reading files, writing files, sending email, accessing internal APIs, executing shell commands, installing dependencies, and calling external services should all have different permission levels and approval policies.

Who owns the agent's memory? Long-term memory is a core agent capability, but in the enterprise, memory is also a data asset. Which memories belong to an individual? Which belong to a team? Which can enter the organizational knowledge base? Which must be deleted, redacted, or expired? These need rules.

Where do the agent's tools come from? Third-party skills, plugins, connectors, workflow nodes, and MCP servers are all supply chain. Enterprises need source verification, version locking, code review, sandboxing, allowlists, isolated execution, and the ability to disable or roll back when something goes wrong.

How does the agent handle knowledge? RAG is not finished when documents are put into a vector database. Enterprises need to know the data source, chunking strategy, index state, retrieved results, citations, access permissions, and update mechanisms. An agent should not be able to see every piece of knowledge simply because it can search.

How does the agent execute a process? Real tasks are rarely one model call. They are sequences of actions: retrieval, judgment, API calls, code execution, branching, tool use, and output generation. The runtime needs to record every step's input, output, state, latency, errors, and version.

How is the agent audited? Enterprises need to know where an output came from, why an action happened, who approved a high-risk operation, which version of the prompt and workflow was executed, which model and credential were used, and whether sensitive data crossed a boundary.

Together, these capabilities form the enterprise's own Agent Runtime.

This direction is also becoming a shared pattern in enterprise software. Microsoft uses the phrase control plane governance in its AI agent governance documentation, emphasizing agent ownership, identity, lifecycle management, observability, agent registry, policy enforcement, and continuous monitoring. Agent 365 is also positioned as a control plane for managing agents in the enterprise. In other words, when the number of agents grows, the governance target is no longer one application. It is the whole agent fleet.

Why Every Team Should Not Build Its Own Stack

Agents often start from local needs.

Sales wants a customer follow-up assistant. Support wants ticket routing. Legal wants contract review. Engineering wants a coding assistant. Operations wants content generation and data analysis. Each scenario looks independent, and each team can quickly assemble a demo.

The problem is that once these demos enter real work, they run into the same underlying issues: model configuration, knowledge permissions, tool integration, long-term memory, execution logs, approvals, API keys, releases, rollbacks, cost, and compliance.

If each team implements this stack on its own, the enterprise quickly ends up with a set of incompatible agent islands. Each agent has its own credential storage, permission model, log format, memory mechanism, plugin mechanism, and release process. It may look fast in the short term, but it becomes new platform debt in the long term.

An owned runtime is not meant to limit team innovation. It gives innovation a shared foundation.

Business teams can still build agents quickly. Developers can still connect tools and models. But identity, permissions, memory, knowledge, execution, audit, and APIs should not be reinvented from scratch every time.

ZGI's Position

ZGI is positioned as a B2B, enterprise-grade Agent Runtime.

Hermes Agent represents the product direction of personal agents: long-term companionship, multiple entry points, memory, skills, tools, and self-improvement.

OpenClaw exposes the real-world problem of open skill ecosystems: when agents can install skills, access systems, and execute actions, supply chain, permissions, isolation, and audit become central.

ZGI is the kind of product enterprises should own.

It is not a personal agent. It is not an assistant for a single user.

It is not just a workflow tool. Workflow matters, but ZGI does not force complex business problems into an increasingly slow and heavy node graph.

It is not a thin wrapper around model APIs. Models are only one part of enterprise agents. Enterprises also need knowledge, tools, permissions, workspaces, execution records, releases, and system integration.

ZGI is the enterprise's own Agent Runtime: a system for building, running, governing, and exposing AI capabilities inside the organization's own boundaries.

Agents are configurable, executable, callable, and governable AI capability units. They turn prompts, models, knowledge, tools, and release modes from individual know-how into team assets.

Workflows are traceable execution graphs. They make retrieval, model calls, HTTP requests, code execution, conditional branching, tool calls, and outputs observable, debuggable, and versioned, without forcing every intelligent task into static nodes.

Knowledge/Dataset is enterprise semantic memory. It allows documents and business materials to enter agents and workflows in an authorized, indexed, retrievable, and citable way.

Model Gateway is the model governance layer. It centralizes providers, models, credentials, channels, and tenant configuration, and leaves architectural room for multi-model routing, failover, cost control, and customer-owned API keys.

Workspace Governance is the organizational boundary. It handles teams, roles, permissions, asset ownership, API keys, execution records, and release boundaries.

APIs allow agents and workflows to be called by real products and business systems, instead of remaining inside a console.

ZGI does not try to solve every enterprise AI problem with one slogan. It is more like an open engineering starting point: a system that brings the runtime problems every enterprise will meet when building agents into a deployable, reviewable, discussable, and extensible product.

Agent Runtime observability trace

Agent Runtime Is a Production Prerequisite

Enterprises will have many agents.

Some will face employees, some will face customers. Some will only read knowledge, while others will modify business systems. Some will analyze, and others will execute. Some will operate inside one workspace, while others will orchestrate multiple tools across systems.

As the number of agents grows, what enterprises need to govern is not one agent. It is the agent as a class of execution subject.

Who creates them? Who owns them? Who can call them? Which systems can they touch? How do they learn and remember? How are they upgraded? How are they monitored? How are they stopped? How do teams investigate incidents after they happen?

One core capability here is observability. Traditional logs can tell you whether an API succeeded or failed, but agent risk happens in a more granular execution process: what it retrieved, which tool it called, which context, model interaction, and external I/O influenced the action, and how state changed. Research such as AgentTrace separates agent traces into operational, cognitive, and contextual traces so that agent reasoning, execution, and environmental interaction can be continuously observed. An enterprise Agent Runtime needs to turn this kind of trace into product capability, not leave teams to search through chat logs after an incident.

Without runtime, agents are a set of tools.

With runtime, agents can become enterprise capability.

Hermes Agent and OpenClaw remind us of the same thing from different angles: the value of an agent comes from its runtime capability, and so does its risk. The more useful an agent becomes, the closer it gets to real data, real systems, and real actions.

Enterprises cannot look for safety only at the model layer. They also cannot hand execution boundaries to personal assistants, ungoverned tool marketplaces, or scripts maintained separately by each team.

Enterprises need their own Agent Runtime not because it sounds more "platform-like", but because production systems need controllable boundaries.

For AI to enter the enterprise, the final question is not only "Can it do the work?" The real question is: "Can it do the work inside the right boundaries, with every step understandable, traceable, and governable?"

That is the position of ZGI.

A B2B, enterprise-owned Agent Runtime.

A way for enterprises to truly own their AI capabilities.

References