How agents made a cross-stack investigation manageable

Some engineering problems refuse to stay inside one team's code. A symptom appears in production, but the cause could sit in a shared library, a build choice, the runtime, or the way the system is deployed. Each plausible fix needs its own setup, measurement, and review. The expensive part is not typing a patch; it is finding out which patch deserves to exist.

We ran into exactly that problem when a Cloudflare Worker exceeded our memory target even while idle. Repeated conversations pushed it further over budget, toward Cloudflare's 128 MB per-isolate memory limit. The search touched application code, a shared agent library, profiling, CI, and deployment. No single optimization was likely to settle it.

We gave agents bounded questions to investigate in parallel. They inspected code, profiled workloads, tried changes on separate branches, and brought back results an engineer could challenge. The team defined success up front and retained the architectural decision. That division of labor is the story: the agents expanded the search; people decided what counted as proof.

First, make the problem testable

Before anyone changed the architecture, the team defined three workloads and a memory target for each. A candidate also had to preserve agent behavior and pass functional checks. Without that common bar, an improvement at idle could masquerade as a solution while making conversations worse.

The warm case mattered most. It tested whether a long-lived isolate could keep serving conversations without steadily losing headroom.

Then, let competing ideas fail quickly

Several ideas sounded reasonable. Agents built the candidates and compared them against the same workloads. Some changes passed their functional tests yet still missed the memory goal. A documented “no” spared the team from carrying a convincing but ineffective fix into production.

Two investigations did uncover real retention problems: cleanup kept stack-bearing errors, and completed agent objects lived longer than intended. Both fixes mattered. Neither made the combined Worker fit reliably. Other agents found that some benchmark comparisons were flawed by missing telemetry, inconsistent sampling, or the wrong build. Fixing the measurement was as important as fixing the code.

The fix was a boundary, not a smaller bundle

The decisive change was a runtime boundary. The original Worker loaded HTTP handling, coordination, database access, telemetry, tools, and the agent Workflow into one isolate. A build split could rearrange files, but it could not guarantee separate live memory. We moved Workflow execution to a second private Worker, leaving application requests and coordination in the first.

Before

One Worker HTTP · coordination · agent execution One shared isolate

After

App Worker HTTP · coordination Isolate pool A

Workflow Worker Agent execution · tools Isolate pool B

That design gave each side its own isolate pool. It did not make memory disappear or halve total compute. It addressed the actual constraint: how much work was live inside any one Worker isolate. Carrying the change through required separate builds, CI changes, a private connection between the Workers, deployment sequencing, and per-Worker monitoring. This was an architecture change with an operations tail, not a one-line memory fix.

What the evidence did—and did not—prove

In matched local profiling, the largest split isolate met all three targets. We show rounded relative changes rather than internal memory budgets. The comparison measures V8 used heap within an isolate; it is not a sum of both Workers or the same metric as Cloudflare's production memory reporting.

Preview then exercised fresh and repeated conversations, a tool-heavy run, and cancellation followed by a successful retry. The planned functional checks passed, and the observed preview windows recorded no Workflow failures.

The remaining risk was on the other side of the boundary: the App Worker still had a high peak in one polling-heavy preview window. The Workflow split worked; the broader memory investigation stayed open.

The split solved the measured Workflow-isolate problem. It did not close every memory question, and the preview checks were not a promise about every production workload.

The gain was engineering attention

In the usual workflow, engineers have to take turns with the same scarce attention: reproduce a profile, try a hypothesis, wait for a build, check another repository, then explain the result to the next person. The cost is not only elapsed time. Every handoff interrupts people who also own product work, and a promising result is hard to trust if its setup cannot be reconstructed.

Here, several bounded investigations could advance at once. Each came back with a branch and an evidence trail: commands, measurements, functional checks, and a disposition. Engineers could compare options instead of personally operating every experiment. Agents also carried the less visible work after the decision—test repairs, build sequencing, preview setup, and rollout notes.

That is the economic shift: more credible options examined per unit of engineering attention. A small team can explore more than one avenue without assigning an engineer to each. A larger team gets a shared evidence record across code and ownership boundaries. This case did not track a human control group, so it does not establish a number of days or dollars saved. Parallel runs consume compute, and reviewing their work still takes time.

The right way to price the workflow is to compare elapsed time, human review time, compute cost, and rework across similar investigations—not to treat an agent's runtime as a proxy for an engineer's hours.

Why not just ask a model or another coding agent?

You can ask a model for likely causes. You can give a coding agent a checkout and ask it to make a fix. Both are useful, but neither answer alone is an investigation. The hard part here was running competing hypotheses against the same workloads, across repositories and runtime boundaries, without losing the ability to reproduce or question a result. That requires more than a good prompt.

Each investigation needs an authorized, isolated workspace where an agent can clone the relevant code, run the actual tests and profilers, keep artifacts, and recover from a failed run. Separate environments let hypotheses proceed in parallel without colliding over files or test state. Shared databases, credentials, and external services still need deliberate boundaries; a sandbox does not make those safe by default.

This case used separate engineering branches and experiment logs. Dexto's cloud environments, project context, skills, and connected tools are designed to make that working pattern repeatable—not to claim that a model or another agent cannot write the code. The useful unit of work is a reviewable answer: what was tested, at which revision, with which commands, what failed, and what decision the evidence supports. Agents can prepare that answer and a patch. People retain authority over the tradeoff, merge, and deployment. Our harness engineering article explains the supporting infrastructure in more detail.

The pattern to take forward

The team did not need an agent to guess the answer faster. It needed enough room to test several answers properly. A shared target made the results comparable; independent runs exposed dead ends; a human review turned those results into an architectural decision. The outcome was a narrower memory domain, along with a clearer account of what still needed work. That is how agents become useful in cross-functional engineering: they expand the investigation while the team stays responsible for the conclusion.