Building the agent is no longer the whole problem. The production system around it (identity, isolation, policy, lifecycle, evaluation, and evidence) is becoming a category of infrastructure in its own right, and the open position is a customer-owned runtime foundation that travels with the software product.
Getting an agent to produce a useful answer is now the accessible part of the work. Frameworks, models, and tooling have made the reasoning loop something a small team can stand up quickly.
The difficulty has moved. Once an agent acts on real customer data, holds delegated authority, reaches external systems, and runs long enough to matter, the question stops being whether it can solve the task. The question becomes how it executes: where it runs, whose authority it carries, what it is allowed to reach, what happens when it fails, and what record it leaves behind.
Those are not properties of the agent's logic. They are properties of the system the agent runs inside. That system is the subject of this thesis.
Conventional application infrastructure assumes a fixed call graph, a single acting identity per request, short-lived stateless handlers, and behavior that changes only when code is deployed. Agents violate each assumption at once.
Each of these individually strains an existing pattern. Together they describe a workload that the surrounding infrastructure was never designed to govern.
The thing that has to be governed, recovered, evaluated, and accounted for is the full execution trajectory: the complete arc of an agent acting toward a goal, including every decision, tool call, credential use, external action, human approval, and state change along the way.
Existing units of infrastructure each capture only a slice of this arc. A request is a single entry point, not the reasoning and action that follow. A container is where code runs, not the identity or authority under which it acts. A model call is one step among many, blind to the surrounding decisions. A trace records what happened for observation, but it is not a control surface and does not hold the delegation, policy, or evidence context.
Governing an agent means governing the trajectory as a first-class object: durable across failures, attributable to a specific version and delegated authority, bounded by policy, and able to produce evidence that survives the run. Treating the trajectory as the unit of production is the shift that reorganizes everything else.
Every established category touches part of the problem and none owns the whole. Assembled ad hoc, they leave gaps precisely where authority, isolation, and evidence have to hold.
Each sees a fragment. No single layer holds identity, delegation, isolation, policy, lifecycle, and evidence together across the full trajectory.
There is one place where the fragments converge: the layer where the agent actually executes and acts. When control lives there, it applies to every governed action rather than only the requests that happen to pass through a particular hop.
These are not separate products bolted together. They are properties of one runtime that owns production execution.
A control point that governs sensitive execution has to sit inside the trust boundary the product and its customers require. Where that boundary falls varies, so the runtime has to be portable across environments while keeping the same control contract.
The same agent product may need to run in a software vendor's own environment, inside an enterprise customer's cloud account, or in a self-managed or disconnected environment where connectivity and key ownership are dictated by the customer. Each of these places execution, enforcement, sensitive state, and evidence under a different operating party.
A portable control contract keeps the agent identity, policy, lifecycle authority, and evidence architecture constant even as the deployment boundary moves. That is what makes the runtime something a customer can genuinely own: the operating model can flex without the security properties resetting, and the trust boundary stays where the customer needs it.
Once execution, identity, policy, and evidence live in one place, production stops being a one-way street. Behavior can be captured, evaluated, and improved through a governed loop that closes back on itself.
The loop is deliberately not autonomous. Evaluation can recommend, gate, contain, or prepare a lifecycle action, but the authority to promote or materially change production behavior terminates in explicit control, policy, and human authority.
The natural incumbents each have a reason not to build the neutral, portable runtime that software vendors actually need.
Hyperscalers optimize for their own ecosystems; their agent tooling is designed to deepen use of their platform, not to travel intact into a competitor's cloud or a customer's self-managed environment. Model vendors optimize around their own models and control planes, where portability across providers is not the objective.
Software vendors are in a different position. They need a runtime that becomes part of their product and operates across whichever customer boundaries a deal requires. Customer trust boundaries vary, so portability is not a convenience feature. It is part of what the runtime is for. The category is open precisely because the parties best placed to fill it are the parties least motivated to make it portable.
The same foundation that governs a single run scales up along a natural axis, from one execution to a full production intelligence and improvement surface.
Each stage reuses the same identity, policy, lifecycle, and evidence model. Nothing has to be re-architected as the surface grows from one run to a governed improvement loop across a fleet.
The same portability that lets one product run in many environments creates a path from a single feature to an enterprise-wide foundation.
A runtime embedded to carry one agent product into the enterprise can become the common execution, control, evidence, and lifecycle layer for the customer's broader agent environment.
Defensibility here does not come from a single feature. It comes from how deeply the runtime integrates into the way a customer builds, ships, secures, and operates agents, and from the assets that accumulate as it runs.
Integration surface
Compounding assets
Increasing architectural and operational embeddedness means each integration and each accumulated asset makes the runtime more valuable and harder to replace. The moat is the compounding relationship between the runtime and the customer's production practice.
Production agent infrastructure is becoming a category of its own. The open position is the customer-owned runtime foundation that travels with the software product and keeps execution, control, sensitive state, and evidence inside the required trust boundary.
Bring an agent, its deployment target, and the production questions your customers or security team are asking. We will walk through the runtime, control boundary, deployment model, and evidence architecture.