AI agents are changing the shape of software.
Traditional SaaS gives users a set of features and expects them to operate the product. Agent-based software starts from a goal: the system retrieves context, chooses tools, executes steps, asks for approval when needed, and returns an outcome.
The interface may become simpler. The system behind it becomes much harder to operate.
That creates an early strategic question for agent companies: should they build a general platform, or begin with one concrete workflow?
Why vertical workflows are easier to validate
A focused workflow makes the value visible.
Resolving a support ticket, reviewing a contract, handling an invoice exception, onboarding an employee, or routing a procurement request all have recognizable inputs, steps, owners, and outcomes. A team can speak with the people doing the work, observe where the process fails, and measure whether the product saves time or reduces manual intervention.
A general agent platform is harder to evaluate. “Build any agent” sounds flexible, but it asks the buyer to identify the use case, design the workflow, connect the systems, define permissions, and carry much of the implementation risk.
For an early product, flexibility can easily become work transferred to the customer.
The workflow is only the visible layer
Once an agent moves from a demo into a real organization, the same operational questions appear across industries:
• Which data is the agent allowed to read?
• Which identity does it use when calling a tool?
• Which actions require human approval?
• What happens when a long-running task fails halfway through?
• Can an operator inspect the full execution history?
• Can the team change models without rebuilding the business process?
• Can the system meet deployment, security, and data-residency requirements?
These may look like infrastructure concerns, but they directly affect adoption. A company will not give an agent meaningful access if it cannot control permissions, trace actions, or stop unsafe execution.
This is where an agent runtime becomes relevant. The runtime is not the use case itself. It is the operational layer that keeps knowledge, tools, workflows, state, approvals, execution, and observability working together.
“Start with a workflow” does not mean “stay vertical forever”
The useful distinction is not simply platform versus application. It is whether the team can turn delivery experience into reusable product capability.
A practical architecture has three layers:
Runtime core — execution, state, permissions, tool access, approvals, logs, retries, and recovery.
Reusable workflow layer — templates, Skills, nodes, and domain patterns that can be used across similar processes.
Organization-specific configuration — data sources, identity systems, policies, approval rules, and internal integrations.
The first layer should remain general. The second should grow through repeated use. The third will always contain some variation, but it should not repeatedly force changes into the core.
If every new customer requires the execution engine to be rewritten, the company is still doing custom projects. If a new deployment mostly involves configuration, integration, and workflow adaptation, the platform is beginning to compound.
What should an early agent platform measure?
Feature count is a weak signal. The number of supported models or workflow nodes says little about whether the system is usable in production.
More useful questions are:
• How long does it take to get the first real workflow running?
• Does the second similar deployment require materially less work?
• Can failed tasks be inspected and resumed instead of restarted?
• How often does a human need to rescue the workflow?
• Will a customer connect real systems and grant meaningful permissions?
• Will they pay for reliable execution, not just access to a demo?
These signals connect infrastructure work to business value.
The path we are taking with ZGI
We are building ZGI as a self-hostable Agent Runtime, primarily in Go. It brings models, knowledge, tools, Skills, workflows, state, and execution into one workspace.
Our goal is not to claim that a horizontal platform can discover product-market fit in isolation. We want to validate the runtime through concrete workflows, identify the operational problems that repeat across deployments, and turn those repeated problems into reusable capabilities.
In short: use workflows to discover the hard problems; use the runtime to solve the ones that keep returning.
The source is available on GitHub:
[https://github.com/zgiai/zgi]
The open question for infrastructure teams is not whether to care about use cases. It is how to learn from use cases without allowing every implementation to become a separate product.
What signal tells you that an agent company is building a repeatable platform rather than a collection of custom deployments?
Top comments (0)