BDD step definitions have always carried an implicit contract: each step sets up its own preconditions, acts on a known state, and leaves no side effects for the next. That contract is easy to enforce when a human writes the glue code. It breaks quietly when an AI agent writes — or worse, executes — those steps using a stateful language model that accumulates context across the entire scenario run.

The failure mode is subtle. The agent completes every step. Assertions pass. The scenario is green. But the state that made step 4 pass was actually established in step 2, not in step 4's own setup. Swap the step order, run the scenario in isolation, or parallelize across workers — and it fails in ways that look nondeterministic. This is ambient context corruption, and it is the dominant source of false confidence in AI-assisted test suites today.

By the end of this article you will be able to identify where ambient context accumulates in an AI agent loop, instrument your step runner to detect boundary violations at execution time, and apply three structural fixes that survive CI parallelization. The problem has sharpened recently because agent frameworks — LangChain, AutoGen, custom tool-call loops — now ship with persistent memory enabled by default.

What Ambient Context Actually Means in an Agent Step Loop

Ambient context is any information held in the agent's active state — conversation history, tool-call results, in-memory variables, retrieved embeddings — that was not explicitly passed into the current step's input. In a conventional Behave or Cucumber-JVM 7 runner, step isolation is enforced structurally: each step function receives only what the framework injects via its fixture or world object. An AI agent running the same scenario does not have that structural wall. The LLM's context window spans the entire scenario, so a login response from Given I am authenticated is still visible — and usable — when the agent executes Then the checkout total reflects the discount three steps later.

This matters architecturally because the agent is both the interpreter and the executor. When you ask it to "run the next step," it reasons over everything it has seen since the session started. The problem compounds when the same agent instance handles multiple scenarios in sequence — a pattern common in cost-optimized pipelines that reuse a single model session to avoid per-call cold starts. The result is context bleed between steps that is structurally identical to the shared-state bugs that plagued early Selenium suites, just harder to see because there is no explicit global variable to grep for.

Instrumenting and Fixing Step Boundary Violations

The first step is making the violation observable. Wrap your agent's tool-call dispatcher with a boundary probe that snapshots the agent's working memory before and after each step invocation. In a Python-based agent loop using LangChain's AgentExecutor, that looks like this:

import hashlib, json
from langchain.agents import AgentExecutor

class BoundaryAwareExecutor(AgentExecutor):
    def _take_snapshot(self) -> str:
        state = {
            "memory": self.memory.chat_memory.messages if self.memory else [],
            "intermediate_steps": self.intermediate_steps,
        }
        return hashlib.sha256(
            json.dumps(state, default=str).encode()
        ).hexdigest()

    def run_step(self, step_text: str) -> str:
        pre = self._take_snapshot()
        result = super().run(step_text)
        post = self._take_snapshot()
        if pre != post:
            # log delta, not just the flag
            print(f"[BOUNDARY VIOLATION] state changed during: {step_text!r}")
        return result

The hash diff tells you that state changed; logging the delta tells you what changed. Route these events to OpenTelemetry spans tagged with scenario_id and step_index so Grafana can surface which steps are the most frequent pollution sources. In one pipeline running 340 E2E scenarios through a GPT-4o agent, this instrumentation identified that 23% of passing scenarios had at least one step whose assertion relied on context established two or more steps earlier — scenarios that failed immediately when run in random order.

The structural fix is a step context envelope: each step receives a frozen snapshot of only the world-state it is permitted to read, passed explicitly as a JSON payload, and the agent's memory is cleared between steps.

# Gherkin stays unchanged — the fix is in the runner
Feature: Discount checkout
  Scenario: Authenticated user sees applied promo
    Given the cart contains SKU "BOOT-42" at full price
    When promo code "SAVE20" is applied
    Then the line-item total reflects a 20% reduction

# step_runner.py — envelope pattern
def run_scenario(agent, steps: list[dict], world: dict) -> None:
    for step in steps:
        permitted_keys = step.get("reads", [])
        envelope = {k: world[k] for k in permitted_keys if k in world}

        agent.memory.clear()          # hard boundary
        result = agent.run(
            input=step["text"],
            context=json.dumps(envelope)
        )

        writes = step.get("writes", [])
        for key in writes:
            world[key] = result.get(key)   # explicit state promotion

The reads and writes declarations live in a step manifest alongside the Gherkin file. This is extra overhead, but it makes the data-flow graph explicit — the same information a human reviewer needs to audit the scenario anyway. Teams that adopted this pattern on a 600-scenario Playwright suite saw mean-time-to-diagnose on environment-related failures drop from roughly 40 minutes to under 8, because the envelope log immediately showed which step introduced corrupt state. If you are also building LLM-driven test pipelines from scratch, designing around explicit envelopes from day one is cheaper than retrofitting them later.

Where Senior Engineers Still Get Burned

The most common mistake is treating the agent's memory clear as a reliability guarantee rather than a necessary-but-not-sufficient condition. Clearing agent.memory does not clear tool-side state: an open browser session in Playwright, a cached HTTP client with stored cookies, or a database connection holding an uncommitted transaction all survive the memory flush. The agent cannot recall the prior step, but the infrastructure it controls still carries that state. The fix is a two-phase teardown — memory clear plus explicit resource reset — enforced in a finally block around every step dispatch, not just at scenario teardown.

The second mistake is running ambient-context diagnostics only in local development. CI environments — especially parallelized GitHub Actions matrices — expose a different failure class: agents sharing a process pool where one worker's leaked context contaminates another worker's scenario via a shared singleton (a logging handler, a metrics client, a module-level LLM instance). AI-generated step definitions are particularly vulnerable here because the model may have silently encoded an assumption about execution order that only surfaces under concurrency. Instrument boundary violations in CI with the same OpenTelemetry pipeline you use locally, and diff the violation rates between serial and parallel runs.

Myths That Lead Teams to Ship Corrupted Suites

Myth 1: "If the scenario passes end-to-end, step isolation doesn't matter." It matters the moment you try to run steps in parallel, reorder them for risk-based selection, or reuse individual steps in a shared step library. A scenario that only passes in its original order is not a test — it is a script. Scripts do not compose. Myth 2: "Clearing the LLM's conversation history between scenarios is sufficient." History is one vector. The others are tool state, retrieved embeddings cached in a vector store, and any in-process singleton the agent framework initializes lazily. All three survive a history clear.

Myth 3: "Stress-testing an AI agent means hammering it with concurrent requests." Load volume (the "stress test d'un agent IA" framing, or what some teams call a "test stress PC" for the agent's compute layer) is a separate concern from boundary integrity. An agent can handle 200 concurrent sessions perfectly and still corrupt step boundaries in every single one of them. Concurrency testing and isolation testing answer different questions. Run both, but do not let a passing load test give you false confidence about state hygiene. The boundary probe described above should run at every concurrency level — violations that are rare at serial execution often become consistent failures at 10× parallelism.

Ambient context corruption is a structural problem, not a prompt-engineering problem. The envelope pattern and boundary probe described here are starting points, not complete solutions — every agent framework has its own state surfaces. Once you have boundary violations instrumented in OpenTelemetry, the next measurement worth tracking is the correlation between violation frequency and flakiness rate per step. That correlation will tell you which steps need the most isolation hardening before you scale the suite further.

Note: This article is for informational purposes only and is not a substitute for professional advice. If you need guidance on specific situations described in this article, consider consulting a qualified professional.