At ten in the morning, someone in the sales chat asks whether yesterday's leads have been followed up. A customer reply arrives in your inbox at the same moment. You open it, read it, and decide, “This customer seems interested. I'll follow up this afternoon.” Meanwhile, a colleague in operations sends a spreadsheet that needs updating by tonight. Two pieces of user feedback appear in Notion. A partner has not replied for three days, and you remind yourself to check in again today.
None of this is difficult. The real problem is that it all stays in your head.
You have to remember who has not replied, when to check again, whom to notify about an unusual number, how far a task has progressed, and what you still owe before leaving work. We already have email, CRM, project management, spreadsheets, knowledge bases, and automation tools. Yet these often solve “Where does the information go?” without really solving “Who keeps the work moving after something happens?”
This may be a turning point for agents entering real work.
For the past two years, we have asked whether AI can write better, answer more accurately, and code faster. As model capabilities become sufficient for more tasks, the question that matters to enterprise productivity shifts from “Can AI do this?” to “Can AI keep this moving?”
A valuable agent should do more than wait for questions. It should be able to take on the work that follows an event.
A notification is not automation. Real automation must take on the judgment that follows.
We have become very accustomed to notifications.
A customer replies: you get a notification. A task changes status: another notification. A metric behaves unusually: another. Inventory changes: another still.
The problem is that a notification simply hands the original work back to a person in a different form.
You still have to open it, read it, understand it, classify it, and decide what to do next. The system knows that something happened. It does not know what should happen afterward.
Traditional automation tools solve part of this problem. They excel at explicit rules: write a form submission to a spreadsheet, send an email after an order is completed, or synchronize data at nine every morning. When the logic fits a clear “If A, then B,” automation is highly effective.
But the parts of real work that consume the most attention are often the ones that cannot be fully specified in advance.
Does a customer's reply indicate buying intent, or is it just a polite inquiry? Is a piece of feedback a bug, a feature request, or a matter of habit? Is a falling business metric normal variation or something that needs immediate escalation? Is a contract clause merely worded differently, or does it carry a real risk?
These tasks require context and judgment.
That is why we see agents as more than an upgrade to automation tools. They allow automation to begin incorporating understanding.
The old sequence was “event occurs → action executes.” With an agent, it can become “event occurs → understand context → make a judgment → invoke capabilities → take action → hand back to a person when necessary.”
The added understanding and judgment are what make this wave of AI different for workflows.
From “give me an answer” to “keep this task moving”
Imagine a sales team receiving dozens of customer emails each day.
With a language model alone, you can copy an email into a chat and ask, “Does this customer intend to buy?”
The AI will give you an answer.
But the way work happens has not changed. A person still copies the email, asks the question, updates the CRM, and notifies sales.
An agent workflow should look different.
When a new email arrives, the system reads it, combines it with the customer's communication history in the CRM and the company's sales rules, and assesses the customer's current stage. An ordinary inquiry can enter a standard process. Clear buying signals can lead to key details being extracted, written to the CRM, and sent to the responsible salesperson. Special pricing, contracts, or high-value customers can pause automatic execution and return the task to a person.
People do not disappear.
They move from having to participate in every step to appearing where judgment and responsibility are needed most.
This is increasingly central to ZGI: helping agents take responsibility for a complete stretch of real work, rather than merely making their answers sound more human.
AI-generated conceptual illustration: understand and assess incoming events, then route exceptional cases to human review.
Why runtime matters once an agent starts doing real work
When an agent is just a chat page, the model is almost everything.
Once it begins executing real tasks, things become more complex very quickly.
It may use Claude to analyze long documents, DeepSeek for a batch of cost-sensitive tasks, and an internal model for sensitive data. It needs to read knowledge bases and query databases. It may call a CRM, internal APIs, and file tools, or execute code.
At that point, “Is the model smart enough?” is only one question.
More immediate questions follow. How are models managed together? How are tools reused? How are tasks connected? How do we trace failures? Who can call which capability? How many tokens did an execution consume? Which steps require human confirmation?
These are not questions for a single prompt.
They belong to the agent's runtime layer.
ZGI brings these previously scattered concerns into one runtime. Models provide understanding and reasoning. Enterprise knowledge and data provide real context. Skills package database queries, file generation, API calls, and report creation as reusable actions. Workflows organize those capabilities around business logic.
An agent no longer merely knows what ought to happen.
It begins to have the means to complete the work.
The value of Skills is more than a few extra features
Developers have been discussing Skills with increasing frequency.
It is easy to think of them as plugins for agents. In an enterprise, however, their deeper value lies in reusing capabilities.
Suppose a team has built a way to generate a weekly sales report: query the database, process Excel files, create charts, and produce a document in a fixed format. Previously, that capability might have been spread across scripts, prompts, and someone's computer.
Packaged as a Skill, it can be used repeatedly by different agents and workflows.
The same applies to looking up customer information, summarizing contracts, or creating tasks through an internal system.
Enterprise AI development can then shift from constantly creating new agents toward accumulating capabilities that agents can reuse.
Models will keep changing. A company's own capabilities should not have to start over every time.
What workflows really change is how work continues
Many AI products can produce an impressive answer. An enterprise needs a continuing process.
A customer complaint may require identifying the problem, checking an order, assessing responsibility, drafting a reply, updating a support ticket, and deciding whether to escalate based on severity.
Some steps suit model judgment, some are deterministic system operations, and some require a person.
Workflows bring them into one sequence.
In ZGI, model calls, knowledge retrieval, conditions, loops, HTTP requests, databases, code execution, and human steps can all form part of a workflow.
The interesting change is not simply having more node types. AI can participate throughout a business process instead of remaining at its entrance.
The more proactive the agent, the more the enterprise needs to know what it did
This is one of the biggest differences between an agent and an ordinary AI tool.
An occasional incorrect chatbot answer may have limited impact. If an agent automatically executes hundreds or thousands of tasks a day, an enterprise needs to know what happened in each execution.
Why did this workflow fail? What input did the model receive? Which model was used? How many tokens did it consume? Which Skill failed? Who triggered the task?
Once agents enter production, observability is foundational.
ZGI therefore considers execution alongside runtime logs, node status, inputs and outputs, model calls, token usage, permissions, and costs within the same governance system.
Our view is simple: AI can become more proactive without leaving the enterprise less aware of what is happening.
The next competition may not be about who has more agents
Today, people still compare how quickly they can build an agent.
One step further ahead, the question may be very different.
A future enterprise may run dozens or even hundreds of agents. Sales, support, engineering, operations, and finance will have their own processes and capabilities. They will use different models, access different data, invoke different Skills, and operate in different workflows.
At that point, the missing piece will no longer be a page for creating another agent.
The company will need a shared runtime that can show what those agents are doing, which capabilities they use, how many resources they consume, where problems arise, and when a person must take over.
This is how we understand Agent Runtime.
ZGI aims to connect the work already present in email, spreadsheets, databases, knowledge bases, and business systems so agents can carry it forward.
The simplest way I would put it is this:
In the first stage of AI, you ask and it answers. In the second, it helps you act. In the next stage of enterprise AI, it knows how the work should continue even when you are not watching every step.
Originally published on the ZGI blog.
Top comments (0)