How Deep Agents run the porting loop

A green build tells only one part of the story.

The game can compile, package, and boot on the target device while still failing the first real player interaction. A menu may ignore a controller. A scene may hit its memory budget after five minutes rather than at launch. A shader or asset can work in the editor and fail in the target build. The port is not done when the compiler stops complaining. It is done when the game behaves correctly on the target platform under the conditions that matter.

That is why game porting is hard to staff across several projects. The engineer has to keep moving through the same evidence loop: understand a new project, check target constraints, prepare a build, inspect failures, run the game, capture proof, patch the cause, and recheck it. Each project needs technical judgment. A large part of the execution is still repetitive. The cost is not just time. It is the state the engineer has to reconstruct every time they switch from one port to another.

Four evidence layers of a game port from build to release showing what can fail and what proves success — A port has to pass more than a compilation check. Each layer needs its own evidence.

Our long-running agent took over that repeatable loop for each project. It maps the codebase, researches the target platform, chooses the next permitted tool, builds the port, executes a defined test path, captures screenshots, diagnoses a defect, applies a limited patch, and runs the check again. The programmer no longer manually drives every build and verification cycle. They supervise several agents, review evidence, resolve exceptions, and approve high-risk work.

This is a real production case. At the discovery, port preparation, build, and iterative validation stage, the agent took over the full scope previously assigned to a programmer. The project and target platform remain confidential, so we have removed identifying details and exact internal metrics. The pattern is reusable beyond game porting because it concerns any long-running technical workflow with repeatable evidence loops.

The system used LangChain Deep Agents. Deep Agents are an agent harness built on LangChain and LangGraph. The harness gives a model a long-lived workspace, planning and filesystem tools, subagent delegation, skills, durable state, and approval controls. In practice, that means the agent can work through a real technical task over time while the team keeps the state, permission boundaries, and review points visible.

What porting actually involves

Porting a game is not one problem. It is a stream of discoveries.

The source project may have implicit assumptions about input, graphics APIs, threading, file paths, controller support, rendering budgets, middleware, build scripts, and packaging. Some issues are visible in a compiler log. Others only appear after boot, in a specific menu, or halfway through a game loop. A green build can still have unreadable UI, a broken controller flow, missing assets, or a scene that never finishes loading.

A conventional automation script is valuable when the sequence is fixed. Build the project, run a smoke test, upload an artefact. It becomes brittle when a failure needs research and a choice between several possible tools or code paths. A programmer handles this by moving between the project, documentation, build output, debugger, the running game, and source control.

That was the job we wanted the agent to own for this defined stage of the port. Not a vague instruction to "make it work". A real working loop with a clear finish condition.

The agent could do	The programmer as human-in-the-loop owned
Inspect the repository and write a porting plan	Scope, commercial commitment, and release decision
Read official platform and engine documentation	Architecture choices outside the agreed boundary
Build, run, capture evidence, diagnose, and patch	Final gameplay and quality sign-off
Re-run the relevant checks after a fix	Certification submission and external release
Create a traceable handoff with open risks	Exceptions that change product intent and cross-project priorities

This boundary matters. The case did replace the programmer's work at this stage. It did not replace accountability for a shipped game. The programmer moved from doing every repeated action to supervising several agents, resolving the difficult cases, and deciding when an output was good enough to progress.

What Deep Agents added to the build

At the centre is the same model and tool calling loop used by many agent frameworks. What Deep Agents add is the machinery around the loop.

LangChain provides the agent building blocks, including models, tools, and middleware. LangGraph provides state, checkpoints, streaming, durable execution, and interrupts. Deep Agents package an opinionated set of capabilities for complex work on top of both. You can use the open-source SDK in your own environment or use Managed Deep Agents when you want LangSmith to run the harness and runtime.

For this agent, five Deep Agent features changed the result.

A filesystem turned the run into a workspace

The agent needed somewhere to put a project map, build logs, screenshots, notes from target-platform research, reproduction steps, and a handoff summary. Putting all of that into chat history would have made the model progressively less effective.

Deep Agents provide filesystem tools such as ls, read_file, write_file, edit_file, and glob. The backend decides whether those files live in thread state, durable storage, a local workspace, or a sandbox. In our case, the agent worked against an isolated project workspace and persisted the useful artefacts needed to resume a long run.

The filesystem also made the work inspectable. A human could open the agent's porting plan, compare a before-and-after screenshot, read its diagnosis, and see why it chose a particular fix. That is much better than trying to reconstruct a decision from a long chat transcript.

Skills gave it the rules of the job

The agent did not start every run with a wall of generic instructions. It had reusable skills for project reconnaissance, build and log analysis, visual validation, safe patching, and handoff.

Deep Agents load skills on demand. Their context engineering guidance makes a useful distinction between short memory that is always loaded and detailed procedures that should only appear when relevant. That kept the stable instructions compact while still giving the agent a disciplined workflow when it reached a build failure or a visual defect.

For example, the visual-validation skill required the agent to save a screenshot with the test scenario and build identifier. A screenshot without a reproducible scenario is weak evidence. The patching skill required it to identify the smallest likely cause, make a limited change, rebuild, and rerun the same scenario before declaring the issue fixed.

Tool choice stayed with the agent

The agent selected the next tool from the state of the work. It could search the project, inspect a configuration file, call an approved documentation search, run the build command in its sandbox, parse a log, start a target build, capture a screenshot, inspect the image, edit a source file, and rerun validation.

That is different from giving an agent one giant "execute anything" tool. Each tool had a clear contract and a bounded purpose. The model decided which permitted capability to use next. The runtime enforced where it could work and what needed review.

Subagents kept the coordinator focused

Some parts of a port are evidence-heavy. Documentation research can produce many pages. A project scan can return thousands of files. Build logs can become huge after a broken dependency or an API migration.

Deep Agents use subagents to isolate that work. The coordinator can ask a focused subagent to investigate a missing API, a graphics warning, or an asset issue and receive a concise report rather than every intermediate tool output. LangChain calls this context isolation. It is the reason to use subagents before any idea of assigning them personalities.

Checkpoints made a long run recoverable

The agent could run for much longer than a normal chat turn. It had to survive a build failure, a tool timeout, or a handoff to a reviewer without starting the whole task again.

LangGraph checkpoints provide that recovery point. The agent's state recorded the current plan, completed steps, work files, evidence, and pending review. The next run could resume the port instead of replaying discovery. That is a basic production requirement for long-running work, not an optional enhancement.

The actual work loop

The agent starts with a ticket that defines the source revision, target build, allowed workspace, expected test paths, and the condition for human handoff. It then works through the following loop.

A Deep Agent keeps project state and filesystem evidence while selecting research, repository, build and capture tools — The agent selects from approved tools and retains the evidence needed to resume the work.

1. Learn the project before changing it

First, the agent maps the codebase and build configuration. It identifies the engine version, project structure, dependencies, asset locations, platform-specific code, existing test hooks, and the likely entry point for a target build.

It also reads the relevant engine and platform documentation through approved sources. This step looks mundane, but it prevents a costly behaviour that we see in shallow coding agents. They start patching before they understand which version, API, or project convention they are touching.

The output is an explicit plan in the workspace. It records what the agent believes it needs to change, how it will validate each change, and what should force escalation.

2. Build and classify the evidence

The agent invokes the build tool in an isolated environment and saves the log. It separates warnings from blockers and groups failures by likely cause. A missing package, an unsupported API, a packaging configuration issue, and a compiler error are different jobs. The agent does not treat them as one large text blob.

When a build fails, it can delegate research on a focused issue to a subagent, search the specific API or documentation version, then return to the coordinator with a recommendation and cited evidence. The coordinator decides whether the finding fits the project's constraints and whether it can make the change safely.

3. Run the game and capture the result

The build is not the finish line. The agent launches a defined game scenario, executes the test path, captures screenshots at named checkpoints, and reads available runtime telemetry.

This creates a useful feedback loop. The agent can see that a menu fails to render, a control hint is clipped, a scene stalls, or a visual element is missing even when the compiler is happy. It can connect a screenshot to the logs and to the code that changed in the current run.

A loop links a build artefact, game run, visual capture, diagnosis and source patch — The build only earns confidence after the agent exercises and inspects the result.

4. Diagnose, patch, and prove the fix

The agent writes a short diagnosis before it edits. It identifies the evidence, the likely root cause, the target files, and the validation that would disprove its own hypothesis. Then it applies the smallest change that could fix the issue.

This is where long-running state matters. The agent can preserve the prior screenshot, build log, failed scenario, and exact patch. When the retest passes, it has evidence that the defect was fixed rather than merely moved. When the retest fails, it has a clean next question instead of a vague instruction to try again.

5. Hand the right artefacts to a person

Once the agreed workflow reaches its stop condition, the agent prepares a handoff. It includes the source revision, changed files, build output, screenshot evidence, checks run, unresolved warnings, and the precise decision that still needs a human.

The agent did not publish a game on its own. It made the human review smaller and better informed. That is what allowed it to take over the programmer's defined stage of work without creating an unbounded release risk.

The programmer became the operator

The meaningful change was not that one engineer had a faster coding assistant. The workflow itself changed.

Before the agent, one programmer could actively progress only the project in front of them. A build failure on one port often meant stopping, reading logs, researching a platform detail, applying a change, and waiting for the next build before returning to another project. The engineer carried the state of each port in their head.

After the agent, each project had its own long-running worker and workspace. The workers handled the repeatable loop independently. The programmer could check the state of several ports, read the evidence behind a recommendation, steer an agent with more context, or stop work that was not worth pursuing. That is a different role from manually executing every step.

The human-in-the-loop model worked because the agent did not hide the work. It surfaced the current plan, selected tool calls, build logs, screenshots, source changes, and open risks. The programmer stepped in where a decision required product judgment, deeper architecture knowledge, or authority beyond the agent's permission boundary.

A comparison of one programmer manually working serially and one programmer supervising three parallel agents — The programmer becomes the control point for exceptions and approval, not the manual executor of every loop.

Before
  programmer → investigate → build → test → patch → repeat

After
  programmer → assign and steer several agents → review evidence → decide exceptions
  agent A    → investigate → build → test → patch → report
  agent B    → investigate → build → test → patch → report
  agent C    → investigate → build → test → patch → report

A simplified implementation shape

This is not the project's source code. It shows the part of the Deep Agents design that mattered most: trusted context, small tools, an approval gate, and a checkpoint.

from dataclasses import dataclass

from deepagents import create_deep_agent
from langchain.tools import ToolRuntime, tool
from langgraph.checkpoint.memory import InMemorySaver


@dataclass
class PortContext:
    project_root: str
    target: str
    source_revision: str


@tool
def run_target_build(runtime: ToolRuntime[PortContext]) -> str:
    """Build the approved revision for the approved target."""
    return build_project(runtime.context.project_root, runtime.context.target)


@tool
def capture_test_checkpoint(name: str, runtime: ToolRuntime[PortContext]) -> str:
    """Run a named scenario and save a screenshot with runtime evidence."""
    return run_and_capture(runtime.context.project_root, name)


@tool
def prepare_handoff(summary: str) -> str:
    """Write a release-candidate handoff. It does not publish the build."""
    return write_handoff(summary)


agent = create_deep_agent(
    model="openai:gpt-5.5",
    tools=[run_target_build, capture_test_checkpoint, prepare_handoff],
    system_prompt=(
        "You are a game porting engineer. Keep a written plan in the workspace. "
        "Use source revision and target from trusted runtime context. "
        "Do not report a defect fixed until the named scenario has been rerun."
    ),
    context_schema=PortContext,
    checkpointer=InMemorySaver(),
    interrupt_on={
        "prepare_handoff": {"allowed_decisions": ["approve", "reject"]},
    },
)

In production, the checkpointer is durable and the execution tool is backed by an isolated sandbox. The application validates the identity and authorisation of the caller before it constructs PortContext. The model receives a target identifier, not arbitrary access to another project's source tree.

Safety was part of the product, not a prompt

Code execution is useful for this job and dangerous in the wrong place. The Deep Agents backend documentation warns that local shell execution can read accessible files, modify the host, run commands with user permissions, and consume unbounded resources. That is suitable for a trusted local development tool, not a multi-tenant production service processing untrusted input.

Our design treated every tool as a capability with a narrow contract. The agent could read the assigned project and use its workspace. It could not read secrets, cross into another project, choose an arbitrary host command, or publish a build. Sensitive operations paused for human review.

Agent permissions divided into autonomous actions, actions paused for human review and blocked actions — The agent's autonomy came from carefully scoped capability, not unrestricted access.

Deep Agents support filesystem permissions that allow, deny, or interrupt file operations by path. Tool-level human-in-the-loop controls can pause a tool call so a reviewer can approve, edit, reject, or respond. Both are enforcement mechanisms. Neither relies on the model remembering a sentence in its instructions.

The business outcome

The direct result was capacity. At this stage of the work, the long-running agents took over the repeated end-to-end responsibility previously carried by one programmer. Each could investigate, build, test visually, patch defects, and create a reviewable handoff without waiting for that person to keep moving between tools.

That changes the economics of a port in a few practical ways.

Several projects can progress through the same known loop at once instead of waiting for one engineer to context-switch between them.
Engineers spend less time performing repeated build, log-reading, and verification cycles. Their attention moves toward architecture, hard edge cases, gameplay judgment, release decisions, and managing agent portfolios.
Every completed loop leaves artefacts behind. The next engineer receives a project map, build output, screenshots, patches, and open questions rather than an oral update.
The studio can assess platform feasibility earlier because each agent produces concrete evidence instead of a speculative estimate.
The same harness can support more than one target or project without asking a human to remember the exact process every time.

There is a broader lesson for AI transformation. The biggest value does not always come from attaching an assistant to an existing role. It can come from identifying a bounded operational stage, giving an agent the tools and controls needed to own it, then redesigning human work around review and exception handling.

What we would test before expanding the boundary

Replacing one defined stage is evidence, not permission to automate everything around it. Before we let an agent take on more of a port, we would test the next boundary explicitly.

We would evaluate whether the agent can distinguish an engine regression from a project bug, whether visual evidence catches real player-facing issues, whether it escalates uncertainty instead of guessing, and whether its patches remain within a sensible change budget. We would also test project isolation, prompt injection through source content, tool misuse, cost limits, and recovery after a failed build.

LangSmith observability makes the tool sequence and model decisions visible in traces. LangSmith evaluation lets a team replay representative cases, compare versions, and turn a production failure into a regression test. That operating loop is one reason the LangChain stack is compelling for this kind of work. The harness, durable runtime, tracing, evaluation, and deployment path were designed to fit together while leaving us free to choose the model, tools, and infrastructure.

Where to start

Do not begin by asking an agent to port an entire game. Start with one evidence-producing loop.

Give it a trusted project context, read-only repository tools, a build command in an isolated sandbox, one test scenario, and a screenshot capture tool. Require a handoff with the build result and evidence. Once it completes that loop reliably, allow a narrow class of patches and make it prove the result by rerunning the same scenario.

The official Deep Agents quickstart is a good way to learn the SDK. The subagent guide, context engineering guide, and human-in-the-loop guide are the next pages to read before building a long-running production worker.