The Shift from Build-Time Logic to Runtime Execution

Introduction to the Series

This is the first post in a two-part series on operating agentic systems in production.

• Part 1: examines the structural shift from build-time-defined execution to runtime-generated execution paths.

• Part 2: introduces an emerging operational discipline — AgenticOps — for safely building, deploying, and governing agents at scale.

This post focuses on the former: the shift in execution and the gap it creates.

Software Behavior Is No Longer Fully Defined at Build Time

Traditional software systems were largely deterministic. Engineers defined logic in code. Control flow was explicit. Execution paths were inspectable prior to deployment. Even in distributed systems, while complexity increased, the execution graph was still fundamentally determined by code and configuration.

Agentic systems change that assumption. AI agents interpret context, select tools, access MCP servers, and determine next actions at runtime. The resulting execution path is not fully defined in source code. It is shaped dynamically based on model output, tool availability, and intermediate results.

In agentic systems:

• An agent may select different tools for the same high-level objective.

• Tool responses may alter subsequent reasoning.

• Agents may delegate tasks to other agents.

• Execution may span multiple MCP servers (public or private).

• Downstream state changes may influence future decisions.

The system’s effective control flow is therefore partially unknown until execution completes. These paths are not hypothetical. They are instantiated at runtime.

This has implications for:

• Debugging

• Incident response

• Governance

• Auditability

And the complexity compounds as agents coordinate or spawn additional tasks.

Fragmented Visibility Across the Execution Chain

Current tooling provides partial visibility:

• Prompt tracing captures model input/output.

• Gateway logs capture inbound/outbound traffic.

• Service telemetry captures API calls.

• CI systems scan code and dependencies.

• Policy engines define high-level constraints.

Each operates at a boundary. - none reconstruct the full causal chain from:

(Model decision → agent reasoning → MCP interaction → tool invocation → runtime state → downstream impact)

Agentic systems extend this problem. The execution path itself is dynamic and cross-system. Teams often reconstruct behavior manually by correlating logs across:

• Agent frameworks

• MCP servers

• Tool APIs

• Infrastructure services

• Security systems

This reconstruction is time-consuming and rarely complete.

The Agentic Execution Gap

We use the term Agentic Execution Gap to describe the disconnect between:

• Dynamic runtime behavior of agents

• Fragmented visibility and governance systems

The gap widens as:

• More tools are integrated

• MCP ecosystems expand

• Agents coordinate

• Runtime autonomy increases

Chip Huyen has written about reliability challenges in production AI systems, particularly around distribution shifts and emergent behavior. In agentic systems, reliability issues often arise not from model output alone but from how decisions propagate through tools and infrastructure.

Defining the Agentic Action Path

To reason about this clearly, it is useful to define a shared abstraction. The Agentic Action Path refers to the complete runtime execution chain:

Model → Agent → MCP → Tool → Runtime execution → Downstream state change

This construct is intended to:

• Clarify causal boundaries

• Provide a shared debugging model

• Anchor tracing requirements

• Support auditability

The agentic action path is not a single trace event. It is a composed execution graph that spans multiple systems. In traditional architectures, execution graphs are largely known at design time.

In agentic systems, they are discovered at runtime. If that path cannot be reconstructed after execution, teams lack proof of behavior.

Observability Explains. It Does Not Constrain.

Observability reconstructs behavior after the fact. It allows teams to examine what happened during execution, correlate events across systems, and understand how a sequence of actions unfolded.

But observability alone does not constrain behavior while it is happening. Traditional observability systems were designed for environments where execution paths were largely deterministic. Logs, traces, and metrics help engineers diagnose failures or performance problems after the system has run. They explain the past; they do not shape the present.

In agentic systems, that distinction becomes more consequential. When agents operate in production environments, runtime decisions can initiate real actions across connected systems. An agent’s reasoning step may immediately translate into tool invocation, API calls, or infrastructure changes.

For example, runtime decisions may:

• Trigger outbound network calls to external services

• Query or modify internal databases

• Write files or change application state

• Execute scripts or launch background processes

• Invoke tools capable of making financial, operational, or security-sensitive changes

Each of these actions occurs during execution. Once triggered, the effects may propagate across multiple systems before a human operator even becomes aware of the chain of events.

Observability systems can later reconstruct the sequence: Model decision → agent reasoning → tool invocation → downstream system change.

They can show which tool was called, what arguments were passed, and which services were affected. This is valuable for debugging and incident analysis. However, reconstruction does not equal control.

If a tool invocation modifies data, sends an irreversible request, or triggers additional automated processes, the system state may already be altered by the time an operator analyzes the trace. The execution path has already propagated through the environment.

This is why runtime-defined systems introduce a different operational requirement.

Visibility alone is not sufficient when the system itself can take actions. Runtime boundaries must exist alongside runtime visibility. Systems need mechanisms that evaluate execution context as it unfolds and determine whether a particular action is permissible before it occurs.

As agentic systems expand across tools, MCP servers, and distributed services, organizations must treat runtime execution as a first-class operational domain — one that requires both deep visibility and explicit boundaries during execution itself.

Toward a New Operational Model

The shift is not from secure to insecure.  It is from build-time-defined execution to runtime-defined behavior. In static systems, reviewing code and permissions is often sufficient to reason about behavior.

In runtime-defined systems, reasoning requires:

• Continuous tracing

• Causal reconstruction

• Execution-aware guardrails

• Feedback loops between CI and production

In Part 2 (coming soon), we examine the operational discipline required to manage this shift: AgenticOps.