Skip to main content

Introducing Field Orchestrator: The Intelligence Layer for Financial Audit.

Learn More

Introducing Field Orchestrator: The Intelligence Layer for Financial Audit.

Learn More

Forge: Powering Agentic Engineering at Fieldguide

Chris Szymansky
Chris Szymansky
5 min read

Forge is Fieldguide’s agentic engineering platform

Forge is Fieldguide's internal platform for running coding agents. An engineer files a task from our issue tracker or Slack, or drives Forge from the terminal over MCP. Forge assembles the context the agent needs, provisions an isolated cloud development environment built from the repository and its dependencies, lets the agent write and run code, applies a defined set of checks, and opens a pull request with the results of those checks attached. An engineer reviews and merges it the way they would any other PR.

Forge is becoming the default way our engineering team ships code, and most of our designers and PMs ship code with it too. During Forge’s first quarter in production, Fieldguide's total merged PR throughput increased 40%.

Forge

Across three patch-size bands, Forge-authored PRs merged 1.3 to 1.6 times faster than other PRs. Rollback rate and defect severity were flat against non-Forge PRs over the same period.

These are observational results. Several factors can affect throughput and merge time, so we do not treat them as a causal estimate. We do see them as early evidence that Forge-authored work moves through review at least as fast as comparable non-Forge PRs.

Agent-written code is just the beginning

An agent can write a patch in a few minutes. Merging that patch into a product where one change touches many interfaces, data models, document-processing systems, and third-party integrations requires context and verification evidence the model does not have on its own.

We tried multiple general-purpose agent platforms and coding agents that promised an end-to-end path. Some produced usable changes, but they kept the work inside their own closed systems and asked engineers to learn a separate workflow, which held adoption down. They lacked Fieldguide's conventions, struggled to exercise connected workflows, and gave reviewers no record of what was tested.

Forge's reusable workflows, which we call Blueprints, carry a scoped task through preparation, execution, verification, and delivery, and return a pull request with the verification evidence attached.

A Forge Blueprint carries a task from preparation through implementation and follow-up in one workspace.
A Forge Blueprint carries a task from preparation through implementation and follow-up in one workspace.

Forge wraps context around coding models

Forge is interoperable with any coding model and adds Fieldguide-specific context and process.

Task preparation: Every run starts with a scoped task packet containing the request, the relevant repository state, and the instructions the agent needs to work within Fieldguide's conventions. Forge Blueprints make that preparation repeatable, so teams can revise the workflow as reviewers find where agents need more guidance.

Execution: Some failures only surface when a change meets the rest of the product, where a component test passes and a browser flow or an integration is still broken. Each task gets an isolated cloud development environment built from the repository and its dependencies, so the agent can inspect code, run the application, execute commands, and use the same development tools an engineer would.

Verification: Blueprints define the checks a task must pass. Depending on the work, those checks include tests, static analysis, application behavior, or task-specific verification. Forge packages the patch with an account of what changed and what it verified.

Human review remains the final gate. Reviewers get the agent's record of the run, so they can apply judgment without reconstructing what happened.

Testing Forge on tasks with known outcomes

Working with Plover Labs, an applied AI coding lab, we built an evaluation set from 40 Fieldguide engineering tasks with known outcomes: ten backend, ten cross-cutting, ten UI, and ten data, workflow, or integration tasks.

For each run, Forge received the task information available in its input packet and a pinned version of the repository, with no access to the historical implementation. A calibrated judge then classified each result as merge-ready, marginal, or a failure by comparing the patch against the task requirements and the production solution.

Forge produced a merge-ready result on 37 of 40 tasks, with a median completion time of 28 minutes. Forge-authored PRs merged 1.3 to 1.6 times faster than other PRs. Rollback rate and defect severity were flat against non-Forge PRs over the same period, indicating consistent quality.

Forge evaluation results by task category.
Forge evaluation results by task category.

Each of the failures pointed at something we could fix. In one, Forge implemented the requested skeleton behavior for financial statements and passed the component tests, but never connected that behavior to report processing or bound it to the source table. The patch was locally correct and incomplete as a product change. We added it as a regression case so Forge catches the same shape of miss in later runs.

The evaluation has its limits. It was a retrospective, stratified dry run judged by one calibrated evaluator. The evaluation harness could not run the browser and generated-document checks available to Forge in production, and the patches did not pass through our ordinary production review and merge process.

How production use improves Forge

Code reviewers worked alongside the Forge team and showed us where task packets were thin and where Blueprints needed additional instructions or checkpoints. Plover Labs' evaluation system lets us test those fixes against work Fieldguide has already shipped.

Production results supply new failure modes, and the historical evaluation shows whether a proposed fix helps across the wider set. A confirmed fix results in a Blueprint update, an environment change, or a new regression case.

Production experience and evaluation results feed the next generation of Forge workflows.
Production experience and evaluation results feed the next generation of Forge workflows.

Models will keep improving. Our Blueprints, regression cases, and environment definitions accumulate alongside them, holding what Fieldguide has learned about how our software gets built, tested, and reviewed.

Forge now runs alongside our engineers as another path from a problem to a reviewable solution. Engineers are still responsible for all code they merge.

Our next set of work is widening Blueprint coverage to task categories Forge handles less consistently, bringing browser and generated-document checks into the evaluation harness, improving reviewer workflows, and matching models to task complexity.

Forge was built by Fieldguide’s engineering team in collaboration with Plover Labs (agent context and evals) and Jess Black (infrastructure).

Chris Szymansky

Chris Szymansky

CTO @ Fieldguide