Autonomous AI Agents for Engineering Tasks with Closed-Loop Feedback Systems

brex · Tech · 2026 · source Agentic: yes · promotional bias: low · source-backed · extracted with prompt 0.5.4 (schema v2)

Generated from extraction.json — do not edit by hand. Every claim cites verbatim source evidence; stated means the quote directly asserts the claim, implied means it supports it indirectly.

Problem

Domain: Autonomous engineering task delegation

Brex needed AI coding agents to complete real production engineering tasks such as monorepo gRPC migrations without engineers manually relaying CI failures, review-bot comments, and test logs back into chat sessions.

Constraints:

• agents work on live monorepos with real CI and review bots
• automated feedback already exists but must be reachable by agents
• each task needs an isolated environment and full toolchain
• parallel execution requires orchestration and environment isolation
• agent work must remain tightly scoped and attributable to humans for review

Architecture

Brex built a closed-loop delegation platform for engineering agents. Tasks arrive from Slack, Linear, GitHub, or cron and are routed by an orchestrator to an agent pool. Each task gets its own remote developer environment and full engineering toolchain. Continuous scripts forward Slack requests, PR bot comments, and CI failures back to agents, allowing them to read feedback, iterate, and create a green PR for human review rather than stopping when automated systems report failures.

Diagram confidence: explicit (topology described by the source).

flowchart LR
  task-triggers[Task triggers] --> orchestrator[Orchestrator]
  orchestrator --> agent-pool[Agent pool]
  orchestrator --> remote-developer-environment[Remote developer environment]
  agent-pool --> remote-developer-environment
  remote-developer-environment --> ci-system[CI system]
  remote-developer-environment --> test-runner[Test runner]
  agent-pool --> github-pull-request[GitHub pull request]
  ci-system --> feedback-bridge-scripts[Feedback bridge scripts]
  review-bots[Review bots] --> feedback-bridge-scripts
  test-runner --> feedback-bridge-scripts
  feedback-bridge-scripts --> agent-pool
  github-pull-request --> human-reviewer[Human reviewer]

Components

Data flow

A human sends a Slack message or another system creates a task. The orchestrator routes the task to an agent and provisions a dedicated remote development environment. The agent edits code, opens or updates a PR, reads CI failures and review-bot comments through feedback loops, applies fixes, reruns validation, and leaves a reviewable PR for the human owner.

Why this architecture

Brex found that agent reliability on real work was mainly an infrastructure and connectivity problem. Agents already had enough capability for well-scoped migrations, but they could not read CI, review bots, or test feedback. Giving each agent an isolated environment, full toolchain, and automated feedback loops let agents keep iterating without engineers acting as messengers.

Models used: AI coding agents

Scale

• Brex ran dozens of gRPC migrations across its monorepo.
  “We ran dozens of gRPC migrations across our monorepo, and the process got better with each one. Minimal engineer-hours spent relaying CI output.”article, stated
• Simpler migrations involved 100 to 200 lines of changes and took about 30 minutes each.
  “For simpler services it worked well — 100 to 200 lines of changes, one-shot, about 30 minutes each. The work was repetitive enough that you could describe the pattern once and let the agent run.”article, stated
• The platform aims to support running 50 agents in parallel.
  “Running 50 in parallel, each iterating independently, requires thinking carefully about orchestration and environment isolation.”article, stated
• A task can produce a green PR by the end of the day.
  “You'd send a message in the morning and find a green PR waiting by the end of the day. No afternoon check-ins, no copying error logs into chat windows.”article, stated

Alternatives considered (roads not taken)

Human relays CI and review feedback to agents

Rejected because: It turned engineers into messengers for information already produced by automated systems.

Run agents in isolated sandboxes without production feedback

Rejected because: Agents hit CI/review feedback walls or continue without critical validation information.

Assign agents broad, underspecified engineering work

Rejected because: Brex says the pattern is for tedious, well-defined tasks and requires tight scope.

Patterns

tool-use-orchestration (agentic)

Agents receive a dedicated environment, full toolchain, CI feedback, review bot comments, tests, and PR workflow access.

async-message-orchestration (agentic)

Tasks enter from multiple trigger systems and are routed to agents that work independently until a PR is ready.

eval-driven-development (quality)

Agents iterate on exact CI failures, test runner stack traces, and review-bot comments rather than relying on final human relay.

human-in-the-loop-gate (governance)

Humans review the final PR, while automated systems and agents handle intermediate feedback loops.

guardrails-io-filtering (governance)

Brex constrains agents to tightly scoped tasks and attributes reviewed work to an actual human.

Tradeoffs

Close the feedback loop instead of adding human relay work

Chose scripts that feed CI and PR bot outputs back to agents over engineers copying logs and comments into chat windows.

Rationale: The information was already generated by engineering systems, so the missing piece was plumbing rather than human judgment.

Use isolated remote developer environments per task

Chose one RDE per delegated task over shared or unmanaged agent workspaces.

Rationale: Isolation enables independent iteration and supports scalable parallel execution.

Delegate well-scoped repetitive tasks first

Chose tedious, well-defined migrations and similar work over broad, ambiguous production engineering tasks.

Rationale: Agents performed reliably when the task pattern was clear and the platform supplied validation feedback.

Gotchas (what bit them)

Agents stop when they cannot read automated feedback.

Root cause: CI, review bots, and test runners produce the necessary diagnostics, but isolated agents cannot access them.

Resolution: Brex built scripts and feedback loops that forward PR comments and CI failures back to agents.

Humans became message relays instead of decision makers.

Root cause: The agent platform lacked plumbing to consume existing engineering-system outputs.

Resolution: Closed feedback loops let agents read failures and continue until the PR is ready for human review.

Parallel agent runs introduce systems-design complexity.

Root cause: Each independently iterating agent needs isolation and orchestration, especially at high parallelism.

Resolution: The platform gives each task its own remote developer environment and routes work through an orchestrator.

Evaluation

Brex evaluated the platform through repeated gRPC migrations, successful end-to-end runs without human relay, green PR outcomes, and lessons from scaling toward parallel agent execution.

Metrics: dozens of gRPC migrations · 100 to 200 lines of changes for simpler services · about 30 minutes per simpler one-shot migration · green PR by the end of the day · target consideration of 50 parallel agents

Outcomes

• Brex ran dozens of monorepo migrations with minimal engineer-hours relaying feedback.
• Agents could complete migrations start-to-finish once feedback loops were closed.
• The platform became a template for delegating well-scoped engineering work.
• Humans reviewed finished PRs instead of managing every intermediate failure.

The article reports dozens of migrations and discusses the design implications of running 50 agents in parallel, but does not disclose total merged PR count or failure rates.