Carter's Knowledge Base

Coding Agent Infrastructure Patterns

4 min read

Coding Agent Infrastructure Patterns

Summary

These articles collectively outline a reusable architecture for serious unattended coding agents. The exact stack differs, but the recurring infrastructure pattern is remarkably consistent.

Repeated patterns

1. Standardized isolated environments

  • Ramp uses Modal sandboxes
  • Stripe uses standardized devboxes
  • In both cases, each run gets its own clean workspace and services

2. Pre-warming or snapshotting

  • Ramp rebuilds and snapshots environments on a schedule
  • Stripe keeps devboxes hot and ready in pools
  • The general lesson: move setup cost out of the critical path

3. Rich internal context hydration

  • Rule files scoped by directory or file pattern
  • MCP or equivalent tool calling for docs, tickets, code intelligence, build state, and internal systems
  • Pre-fetching likely useful context before the main agent loop starts

4. Deterministic wrappers around agent loops

  • Ramp describes plugins and explicit safeguards around write timing and synchronization
  • Stripe formalizes this as blueprints that mix deterministic nodes with agentic nodes
  • The broader lesson is that reliability often comes from combining LLM judgment with fixed workflow code

5. Strong feedback loops

  • Run local linting and checks before expensive CI
  • Limit CI retries rather than looping forever
  • Feed failures back into the agent in a structured way

6. Explicit orchestration roles

  • Recent multi-agent guidance makes a stronger role split explicit: an orchestrator plans and delegates, while subagents execute in fresh contexts
  • This separation keeps the top-level loop focused on decomposition and progress tracking instead of direct tool churn
  • The broader lesson: systems improve when planning and execution do not constantly contaminate each other’s context

7. Verification as a separate station

  • Builder and verifier roles should be separated whenever possible
  • Review, tests, browser automation, and visual checks should be treated as independent evidence generators
  • The broader lesson: reliability improves when verification is not left to the same agent that produced the code

8. Multiple parallelization patterns

  • Independent exploration (prep line) works for taste-heavy generation and option search
  • Distinct concurrent tasks (dinner rush) work when file ownership is clean
  • Phased waves (courses in sequence) work for larger projects with dependency trees
  • Sequential handoff pipelines (prep-to-plate assembly) work for long-horizon, research-heavy workflows
  • The broader lesson: multi-agent is not one pattern but a small family of orchestration shapes with different dependency assumptions

9. Prefer thin, task-specific tool surfaces when possible

  • Mario Zechner argues that many MCP servers are overbuilt for narrow tasks like browser automation, forcing agents to ingest dozens of tools and long descriptions just to do four or five things
  • His alternative is a tiny CLI harness made of Bash-invokable scripts for browser start, navigation, JavaScript evaluation, screenshots, and optional add-ons like DOM picking or cookie export
  • The broader lesson is not “never use MCP”; it is that agents often work better with small, composable tool surfaces that can be edited quickly and whose outputs can be saved directly to files
  • This complements the patterns above: orchestration scales better when each execution role also has a compact, purpose-built toolset rather than a giant general-purpose interface

Open questions worth tracking

  • How much determinism is ideal before an agent becomes too constrained?
  • Which verification tools most improve end-to-end success rates?
  • How important is multiplayer collaboration as these systems mature?
  • Where is the best boundary between local and remote execution?

Sources

Graph View

Backlinks