Two Architecture Paths for Coding Agents

Coding work is moving from one-shot code completion toward multi-step task execution that can be rolled back and verified. For long chains such as reading a repository, changing code, running tests, and revising after failures, whether decisions sit inside the model or in an external control layer directly affects explainability, failure recovery, and engineering control. The two common architectures are best understood through responsibility split, the execution loop, and how they are put into practice.

The real problem: not “can it write code,” but “who decides the next step”

Long-horizon coding does not end after a single generation. A typical flow includes understanding the goal and constraints, locating relevant files, proposing a change, applying a patch, running the build and tests, judging the failure from logs, and deciding whether to retry or narrow the scope. The hard part is each step’s questions: whether to continue, which tool to call, how to interpret a failure, and when to stop.

A system can be abstracted into three layers:

• Cognition: understand the natural-language goal, code context, and constraints.
• Action: read and write files, search, run commands, and invoke tests and static checks.
• Control: plan steps, limit permissions, validate results, and handle exceptions and budgets (step count, timeouts, and call limits).

The core split between the two architectures is whether the control layer exists independently and whether decision rights sit outside the model.

Path 1: model-native agents—put the “hands” inside the model

This path internalizes planning, tool choice, and when to think versus act as much as possible into model behavior. The usual shape is a strong reasoning model plus a relatively fixed set of tool interfaces (read files, edit, search, run commands, and similar). There is no separate “project manager” process making the call for the model. The model decides the next step from conversation state and tool results.

Main advantages:

1. A shorter interaction path. With one less external scheduler, latency and protocol conversion cost are lower. This fits interactive work such as changing a small piece of logic, explaining an error, or a local refactor.
2. More coherent expression. Planning and execution come from the same source, which reduces semantic loss between scheduler instructions and the model’s understanding.
3. A simpler product shape. For the end user it is an assistant that can keep working, and the engineering surface has fewer components.

Constraints that should be faced directly:

• Behavioral boundaries depend on model alignment and prompt constraints. Permissions, step limits, and dangerous operations (delete, force-push, change configuration) must be hard-blocked at the tool layer, not left to a promise that the model will behave.
• Observability is closer to a black box. Why a file was chosen, or why a path was abandoned, often has to be inferred afterward from traces or logs. Deterministic rules are hard to insert in time.
• Failure-recovery policy is hard to standardize. Different sessions may retry in different styles, which raises the cost of enterprise audit, compliance, and reproduction.
• Model upgrades can change “temperament.” Under the same prompt, planning granularity and conservatism may drift. Regression tests must cover behavior, not only one-shot generation quality.

In engineering terms, separate “can do” from “is allowed to do.” The model may propose running tests, but the sandbox, working directory, network, and secrets must be enforced by the runtime. A native agent is not uncontrolled. Soft decisions stay with the model; hard constraints stay in tools and the isolation environment.

Path 2: LLM plus an independent control framework—the model generates, the framework decides

This path treats the model mainly as an engine that proposes plans and generates patches, wrapped by an open-source or in-house scheduler. The scheduler owns task decomposition, the state machine, tool orchestration, result checks, and correction policy. When asked, the model returns a plan fragment, a patch, or an explanation of logs, but it does not hold final decision rights.

Think of it as a replaceable cognition layer and an auditable control layer. A typical loop is:

1. The scheduler creates or updates a task graph from the goal (analyze, modify, verify, finish).
2. It asks the model for the output required by the current step (for example, a patch to a file).
3. After tools run, deterministic checks (compile, unit tests, static rules, diff-size limits) decide success or failure.
4. On failure, policy narrows scope, rolls back, switches the search path, or escalates to human confirmation.

Advantages:

• Decisions are explainable and reproducible. Each step has state, policy, and a budget, which helps debugging and compliance.
• Models are swappable. The same workflow can use different generation models, reducing the risk of binding to one model’s behavior.
• It fits team standards. Commit-message format, tests must pass, no edits to secret files, and a cap on diff lines can be written as rules rather than hopes that the model remembers.
• Correction is more engineered. A test failure can follow a fixed path: locate the failing case, minimize the reproduction, then apply a targeted patch—instead of improvising every time.

The costs are equally clear:

• The system is heavier. It needs state storage, a queue or event loop, timeout and concurrency control, and integration with the repository and CI.
• If scheduling is too rigid, it can suppress exploration: the framework insists on changing A while the model has found the root cause in B.
• Prompt and interface design must be strong. Repository structure, error summaries, and allowed tool results have to be fed to the model at high quality, or generation quality drops sharply.

Side by side: decision rights, tools, and failure

1. Where decisions sit
   Native path: the model decides continuously in the conversation; the system mainly provides tools and an environment.
   Framework path: a state machine or planner decides; the model is a generator and interpreter inside a step.

2. Tool calls
   Both need tools, but the meaning differs. On the native path, tools are the model’s limbs, and the model chooses when to call them. On the framework path, tools are stations on a pipeline. When to run tests or formatting is often triggered by policy and is not always asked of the model.

3. Failure and stop conditions
   The native path relies on the model “feeling it should stop,” so hard stops are required (maximum steps, maximum cost, no-progress detection).
   The framework path can encode an explicit terminal state: tests pass, static checks pass, and human or rule acceptance. That avoids endless edit loops.

4. Context management
   On long repository tasks, stuffing the full tree into the window is both expensive and unstable. The native path tends to let the model retrieve on its own. The framework path can use deterministic algorithms to shrink the file set first (change-related files, the dependency graph, the failure stack) and then let the model work on that subset. The latter is often cheaper and more stable, at higher implementation cost.

How to choose: match task length and organizational constraints

If the task is short, highly interactive, and used locally by an individual developer, the native style is lighter and imposes less mental overhead.
If the task is long, must land on the main branch, must pass quality gates, and must be auditable, independent control is a better fit.
Many real systems are hybrids: the model proposes a plan and the framework enforces permissions and verification; or the framework splits the task and the model freely uses read-only tools inside a subtask, while writes still go through review.

A few principles that do not depend on any vendor:

• Deny writes and high-risk commands by default; open them through an allowlist.
• Make every change rollback-able, and run tests in an isolated environment.
• Record the full trace: prompts, tool inputs and outputs, diffs, and test logs.
• Cap loops with a budget: steps, time, and failure count.
• Encode team standards as checkers, not only as prompt text.

Judge the gap by the closed loop, not by one pretty generation

When comparing the two systems, do not look only at whether one round of code looks elegant. Look instead at:

• Given a real repository and a failing test, how many steps it takes to fix the failure reliably.
• Whether unrelated files are changed by mistake.
• Whether the system can still locate the right place after context grows.
• Whether behavior remains regressable after a model generation change.
• Whether, when something goes wrong, an engineer can tell from logs whether the model or the policy was wrong.

The ceiling of the native path often rises with the model’s reasoning and tool-use ability. The floor of the framework path depends more on engineering: if retrieval, isolation, tests, and rules are solid, an ordinary model can still complete a large amount of mechanical change. For a team, “how large is the gap” is usually not a single score. It is how much system complexity they are willing to pay for controllability.

What to ship: move verification left before raising autonomy

Whichever path you choose, raise capability in this order:

1. Read-only understanding: Q&A, locating code, and explaining architecture.
2. Local patches plus mandatory tests.
3. Multi-file refactors plus a regression set.
4. Command execution under limited permissions.
5. Integration with review and CI gates.

Autonomy should rise with verification strength, not by granting unlimited write access at the start. Neutral infrastructure commonly used in the cloud—object storage for artifacts and logs, a container platform for isolated runs, and logging plus monitoring alerts for traces and failure notification—can support this loop without locking decisions to one generation model.

Closing

A model-native agent means the “brain” reaches out itself. An LLM plus a control framework means a project manager owns the process and the model owns the output. Neither is absolutely more advanced. The question is whether the design matches task length, risk level, and governance requirements. Split decision rights, tool rights, and verification rights, and intelligent coding can move from a demo to a maintainable engineering capability.