From Building Agents to Running Them: ZGI Is Building the Next Layer of Enterprise AI

Agents have changed significantly over the past year.

At first, the conversation focused on model capabilities, prompts, and getting more accurate answers from AI. Then RAG, workflows, tools, and Skills increasingly became standard components. Agents began moving from answering questions to executing tasks. Today, building an agent that can retrieve knowledge, call tools, and process data is considerably easier than it was two years ago.

At the same time, another problem is becoming clear: building an agent is no longer the hardest part.

The real challenge is keeping it running consistently, reliably, and under control once it enters a business.

It needs to connect to different models, use the company's knowledge and data, call real systems, and execute multistep processes. As task volumes grow, permissions, quotas, logs, costs, exceptions, audits, and deployment all need attention.

These issues are easy to hide behind a demo. In production, they surface one after another.

This is where ZGI has been investing its efforts.

Once agents enter real business, the questions change

A demonstration agent typically needs to answer three questions: Can it call the model? Can it retrieve knowledge? Can it complete the task?

An agent operating inside an enterprise must answer many more.

Within one organization, engineering might use Claude, operations might use GPT, certain tasks might favor DeepSeek on cost, and sensitive data might require a private model. A model is no longer a fixed choice. It becomes a resource that must be managed and allocated over time.

Knowledge is more than a few uploaded PDFs, too. A company's valuable information lives across product documents, business systems, databases, APIs, and internal services. Without access to that information, an agent may remain good at answering questions without being useful in actual operations.

The same is true of workflows. Real work rarely consists of one input and one answer. It involves querying, assessing, executing, seeking approval, and executing again. Any step can fail or require a person.

When these capabilities are connected, an agent begins to become a business system rather than an isolated AI feature.

A business system needs a runtime layer.

ZGI focuses on the runtime for agents

We increasingly describe ZGI as a runtime for enterprise AI agents.

It sits between models and business systems, bringing models, knowledge, data, Skills, workflows, and operational governance into one environment.

At the model layer, ZGI provides shared connectivity and management. Teams can use GPT, Claude, DeepSeek, Qwen, and internal models within the same system while managing credentials, quotas, usage, and costs centrally. Business applications should not need to rewrite their logic every time an underlying model changes.

At the knowledge and data layer, ZGI provides enterprise RAG and structured data capabilities so documents, knowledge bases, and business data can become an agent's context. Model capabilities determine how much an AI can understand; a company's own data determines whether it understands that company.

Above that are Skills and workflows.

Skills preserve reusable capabilities. File generation, data queries, reports, calculations, database access, and internal APIs can become modules that agents reuse instead of implementing the same functions repeatedly.

Workflows organize those capabilities into real processes. Knowledge retrieval, model calls, conditions, loops, HTTP requests, databases, code execution, and human approvals can be combined in one flow. An agent can then carry out a complete task through multiple steps.

This is a point we keep returning to: enterprises need systems that organize model capabilities into business execution.

Conceptual illustration: the runtime organizes models, context, and execution with shared governance.

Execution must come with governance

The more autonomous AI becomes, the more governance matters.

When an agent answers a few questions in an internal test environment, many concerns can be deferred. Once it accesses databases, calls APIs, handles customer information, or takes business actions, the company must know what it is doing.

At the runtime layer, ZGI therefore tracks execution logs, node status, inputs and outputs, model calls, token consumption, costs, and errors.

A failed workflow can be inspected at the relevant node. The model used for a task and the tokens consumed can be recorded. For agents that run over time, this is basic observability rather than an optional extra.

Permissions require the same attention.

Which agents members can use, which models they can access, and which capabilities they can invoke need to be managed at the organizational level. Model quotas, API keys, token budgets, and execution logs should not be scattered across personal accounts and configurations.

We want a clear boundary: agents can become more proactive while their behavior remains understandable, traceable, and controllable.

Opening the source gives enterprises control over their AI infrastructure

ZGI has opened its source code and continues to update it on GitHub and Gitee.

For us, this is about more than letting people inspect code.

As AI begins working with a company's knowledge, data, and systems, the team should have more control. It should understand how the system operates and be able to decide where it runs.

ZGI therefore supports self-hosting. Teams can deploy the Web, API, Sandbox, Runner, database, cache, and vector retrieval components on their own infrastructure and connect them to internal models, knowledge bases, databases, and business services.

For enterprises requiring data isolation, internal network operation, or stricter security boundaries, agents can become part of their existing technical architecture.

That is also the purpose of opening the source: AI can become more capable without an enterprise losing control of its runtime environment.

You can start using ZGI for free

Many agent platforms require a significant validation investment before a team can discover whether the system fits its business.

ZGI aims to make that first step easier.

Users can currently start with ZGI for free, create agents, connect models, configure knowledge bases, and try Skills and workflows to get a real agent process running.

We encourage developers and teams to begin with a specific problem.

It might be an enterprise knowledge assistant, a data query workflow, an agent that generates reports, or a workflow connecting internal systems.

First, run it on a real task.

What matters is not how many features appear on a product page. It is whether the agent can participate in actual work and keep completing it.

The next stage will involve more than simply more agents

The industry has produced a large number of agent builders.

That matters: it has lowered the barrier to building AI applications.

But we see it as the first stage.

As more agents are created, enterprises soon face another question: How will those agents coexist over time?

A future company may have more than one AI assistant.

Sales will have its agents, support will have its own, and engineering, operations, and finance will have theirs. They will use different models, access different data, hold different permissions, and run in different workflows.

At that point, creating agents will be only part of what the organization needs.

It will need infrastructure to manage how those agents connect to models, invoke capabilities, execute tasks, consume resources, and operate under governance.

This is ZGI's long-term view of Agent Runtime.

Models determine how far an agent can reason. The runtime determines whether it can actually operate.

Previously, we spent more time figuring out how to make AI capable of a task.

Now we are focused on how to keep it doing that work in a real business.

That is the layer ZGI continues to build.