Long-running work, event triggers, human checkpoints and evaluations reveal the real shape of an enterprise agent platform.
A set of engineering demos published by Google Cloud in July shows where the agent platform category is heading. The noteworthy examples are not the ones that produce polished text. They are the ones that pause for approval, wake up after an event, preserve state for weeks, run evaluations and connect an action to an auditable result.
That is the shape of a runtime, not a chatbot builder.
The enterprise workflow is rarely synchronous
A chat interaction begins and ends while a user is present. Business processes do not.
An expense waits for a manager. A customer case waits for evidence. A procurement request waits for budget approval. A field-service incident resumes when a sensor or technician changes its state. Some tasks take minutes; others span weeks.
An enterprise agent runtime therefore needs more than a request/response loop. It needs:
- durable state that survives restarts and model changes;
- event-driven triggers;
- pause, resume and cancellation;
- idempotent actions that do not duplicate side effects;
- deadlines, retries and compensation logic;
- human checkpoints with explicit ownership;
- an inspectable history of decisions and tools.
Without those capabilities, “long-running agent” often means an unreliable script that happens to call a model.
Human-in-the-loop is an execution primitive
One Google example routes low-value expenses through deterministic thresholds, screens higher-risk cases, runs a model-based compliance analysis and then pauses for human review before finalisation.
The important part is not the expense use case. It is the pattern.
Human review should not be an emergency fallback bolted on after launch. It should be a first-class state in the workflow. The system needs to know what evidence to present, who has authority, what happens if the reviewer does not respond, and whether the process can continue after a partial approval.
Different checkpoints serve different purposes:
- approval before a consequential action;
- verification when confidence is below a threshold;
- exception handling when policy cannot resolve the case;
- quality sampling for ongoing assurance;
- appeal when an affected person challenges an outcome.
Treating all of them as “send to a human” creates queues rather than control.
Evaluations belong in the release pipeline
An agent can return a correct final answer after taking the wrong path. It may use an unauthorised source, call an expensive tool repeatedly, expose unnecessary data or skip an approval. Evaluating only the response misses the failure.
A production evaluation should score the trace:
- Was the intent understood correctly?
- Was the right context retrieved?
- Were only permitted tools used?
- Were tool arguments valid?
- Did the workflow respect policy?
- Was the result verified?
- Did the agent escalate at the right moment?
- Did it complete within cost and latency budgets?
Those evaluations should run when prompts, models, tools, policies or workflow code change. Agent quality is a release property, not a one-time benchmark.
Runtimes create organisational leverage
A shared runtime can standardise identity, secrets, traces, approvals, budgets and evaluation. Teams can then focus on the domain logic of customer service, finance or operations instead of rebuilding the same control mechanisms.
But centralisation has a cost. An enterprise platform can become a bottleneck or impose one vendor’s assumptions on every workflow. The architecture should preserve a clear contract between the runtime and the agent: state, tool interface, events, telemetry and policy. That makes it possible to support more than one framework without creating an unmanaged free-for-all.
What leaders should ask
When evaluating an agent platform, move past “how quickly can we build a demo?” Ask:
- Can a task survive a deployment or regional failure?
- Can an operator inspect and change its state?
- Are approvals native and policy-driven?
- How are side effects deduplicated?
- Can tools be versioned without silently breaking agents?
- Are traces portable to the organisation’s observability stack?
- Can evaluations block a release?
- Can workloads run under private network and identity controls?
- How is model spend constrained per task or business unit?
- What is the exit path if the platform no longer fits?
The Lexdatum view
The agent platform is becoming the runtime for delegated work.
Its job is not to make an LLM look autonomous. Its job is to make automation durable, observable and interruptible. Enterprises should select platforms by their ability to manage state and consequence—not by the elegance of the prompt editor.
Sources
Research note: This analysis is based on public information available on 31 August 2026. Product capabilities, prices and regulatory interpretations can change. Vendor-reported metrics are identified as such. This is not legal, security or investment advice.