A year of AI coding / 13
The agent harness is becoming a platform
An agent platform should be evaluated through its execution, identity, data, and recovery boundaries as well as its model capabilities.
By Grafty team · · 3 min read
Written in .
Connecting a model to a shell produces a demonstration quickly. Operating that arrangement for a team requires considerably more infrastructure.
The worker needs a reproducible environment. Tool calls need identities. Someone has to decide which network destinations are reachable, where outputs are stored, and what survives a failed session. Those choices shape the usefulness of the agent as much as the next model upgrade.
At Google I/O on May 19, 2026, Google expanded Antigravity and announced preview access to its agent harness through an SDK. The developer announcements described a broader platform for building and operating agents. That move reflects a practical reality: the execution system around a model is becoming a substantial product of its own.
Open full-size diagram Inspect the execution boundary
For a team building internal applications, we would start with where the work runs. Is each task isolated? Can one task read another task's files? Are environments created from a known image? Does a restarted worker pick up a half-written directory, or a clean checkout with an explicit handoff?
These questions become concrete when an agent installs a package or runs a generated script. An environment that shares a developer's home directory and credentials has a different risk profile from a short-lived worker with only a repository checkout.
Isolation also has a maintenance cost. Images need patching, dependencies need updates, and caches need ownership. A stale environment that fails every new task is not useful merely because it is isolated.
Open full-size diagram Separate execution from inference
The phrase "runs on our infrastructure" needs a precise definition. A worker can execute internally while sending prompts and selected source code to a hosted model. Alternatively, inference can run inside an organization's network. Those are different configurations with different requirements.
Map the actual data path. What enters a model request? Where are prompts and outputs retained? Does telemetry include tool results? Which policies apply to backups and support access? Local execution answers only part of that review.
We think this distinction matters particularly for internal app development. A sample row copied into a test, a schema description, or an error log can contain sensitive information even when the full database never leaves its network.
Treat agent identity as an application identity
The agent should not inherit broad access simply because a developer launched it. Give the worker the capabilities required for the task, and use a separate approval or identity for consequential operations.
For example, reading a staging schema can be allowed while running a production migration remains unavailable. The restriction should hold at the tool or service boundary even if the task text asks for more.
The platform also needs a usable record of actions: which task requested an operation, which identity performed it, and what result came back. Retain enough to investigate without turning logs into a second store of secrets.
Buy the operating model you can support
An SDK can provide useful building blocks, but it does not automatically provide a complete service. The team still needs to know who handles failed workers, exceeded budgets, provider outages, and configuration changes.
Before adopting a platform, run a small workload through an interruption, a tool failure, and a denied operation. Inspect what the operator sees and how the task recovers. That exercise often reveals more about production readiness than a successful generation demo.
The model will continue to improve. The platform decision is about whether the organization can safely use those improvements inside its actual engineering environment.