The Common Architecture of Coding Agents: Separating Models from Runtimes

After using multiple coding agents for an extended period, it is easy to develop the impression that they are fundamentally the same. Their interfaces, command structures, task decomposition, and code-editing workflows often look highly similar. Even their approaches to specific tasks may follow nearly identical paths.

This raises a common question: are these products simply different interfaces over the same system?

A more accurate explanation is that they may not be the same product, but they likely share a similar underlying architecture:

The foundation model provides capabilities, while the runtime or scaffolding organizes those capabilities into an executable, verifiable, and auditable task loop.

This distinction is important because it helps developers avoid two common misconceptions:

1. Treating the product experience as a direct reflection of model capability.
2. Treating a model name as synonymous with a coding agent product.

Foundation models and coding agent products exist at different layers. The same model can be used by different runtimes, and the same runtime can integrate with different models. What ultimately determines usability is the combined effect of the model, context engineering, tool protocols, execution sandboxes, state management, permission controls, audit mechanisms, and evaluation systems.

Why Do Different Coding Agents Feel Like the Same Product?

Different coding agents may have different entry points, interfaces, and configuration methods, but their core workflow is highly consistent:

1. Receive a task.
2. Collect relevant context.
3. Create a plan.
4. Call tools.
5. Observe the results.
6. Revise the plan.
7. Run validation.
8. Report the changes.

This workflow can be abstracted as an observe–plan–act–verify loop.

Within this loop, the model primarily handles reasoning, code understanding, patch generation, and error analysis. The runtime parses the model’s output into executable actions and manages tool calls, file operations, command execution, test feedback, permission approvals, and process records.

The perceived intelligence of a coding agent therefore depends on more than the model. It also depends on whether the runtime can:

• Compress and organize context effectively.
• Provide high-quality tools.
• Recover from failed actions.
• Run tests automatically.
• Return useful feedback to the model.

It is not surprising that multiple products offer similar experiences. They are all addressing the same engineering problem: how to enable a model to complete coding tasks reliably in a controlled environment.

The major differences are usually not whether a product has this loop, but how well the loop is engineered.

The Core Separation: Model Capability and Runtime Responsibilities

A coding agent can be understood as two major layers.

The Model Layer

The model provides language understanding, code generation, reasoning, planning, and error analysis.

Important model-level capabilities include:

• Code comprehension accuracy.
• Patch quality.
• Long-context utilization.
• Compliance with tool-calling formats.
• Ability to correct itself after failure.

The model is a major source of the system’s upper capability limit, but it does not determine the entire product experience.

The Runtime Layer

The runtime, also commonly referred to as scaffolding or an execution framework, is responsible for:

• Building context.
• Registering and calling tools.
• Isolating the execution environment.
• Persisting state.
• Controlling permissions.
• Providing process observability.
• Validating results.

The runtime determines whether model capabilities can be converted into stable engineering output.

The relationship is similar to that between an engine and a complete vehicle. The engine matters, but the chassis, transmission, control systems, and safety constraints also determine the driving experience. Confusing a model with an agent product overlooks the substantial engineering differences in the runtime.

Six Key Modules in the Common Architecture

1. Task Orchestration Loop

Almost every coding agent is built around a recurring loop:

• Read the task and history.
• Build the current context.
• Ask the model to generate the next plan or action.
• Parse and execute the action.
• Collect the result.
• Continue to the next iteration.

The loop looks simple, but its engineering challenges include defining stopping conditions, retrying failed actions, revising plans, and closing the validation loop.

A simplified version can be represented as follows:

function run_agent_loop(task):
    memory = init_memory(task)
    while not done(task, memory):
        context = build_context(task, memory)
        decision = model.generate(context)
        action = parse_action(decision)
        if needs_approval(action):
            request_approval(action)
        result = tool_runtime.execute(action)
        memory.append(action, result)
        if should_verify(action):
            verify_result = run_validation()
            memory.append(verify_result)
        if unrecoverable_error(result):
            memory.append(recovery_hint())
    return summarize(memory)

This pseudocode does not depend on any specific product interface, but it reveals the common structure: the model produces decisions, while the runtime executes them and returns feedback.

The quality of the loop depends on whether the context is sufficient, whether actions can be parsed reliably, whether tools are dependable, and whether validation happens at the right time.

2. Context Engineering

Coding tasks are highly sensitive to context. The runtime must determine what information to place in the model’s context, including:

• The task description.
• Relevant code fragments.
• Directory structure.
• Previous modifications.
• Test output.
• Error logs.
• Project constraints.

Too little context forces the model to guess. Too much context increases cost and noise, potentially burying the most important information.

Mature runtimes commonly organize context into layers:

• System constraints.
• Task objectives.
• The current plan.
• Recent tool results.
• Retrieved code and symbols.
• Historical summaries.

Long-running tasks also require compression and retrieval strategies. Older conversations may need to be summarized, while important files or symbols are retrieved only when necessary.

Context engineering is a major source of the shared experience across coding agents because it determines whether different systems present the model with a similar view of the software project.

3. Tools and Protocols

Coding agents need to read and write files, search code, run tests, inspect version-control differences, and execute static checks. Runtimes generally expose these capabilities as tools and define their names, parameter structures, return formats, and error semantics.

The model selects actions based on tool descriptions. The runtime validates parameters, executes the tools, and returns structured results.

The main design goal of the tool layer is stability and interpretability:

• Tools should not be too coarse, or the model will have difficulty composing them.
• Tools should not be too fine-grained, or the number of calls and context cost will become excessive.
• Results should be as structured as possible.
• Error codes, important logs, and actionable suggestions should be preserved so the model can make corrections.

4. Execution Environments and Sandboxes

Once a coding agent can execute commands, security and isolation become essential. A runtime generally needs to execute tasks in a sandbox that controls:

• File-system access.
• Network access.
• Resource consumption.
• Execution time.

Enterprise environments may also require different permission levels for read-only analysis, patch generation, test execution, and submitting changes.

A sandbox is not an optional add-on. It is a prerequisite for deploying coding agents safely. Without isolation, an incorrect model action could affect the real environment. Without resource limits, a long-running task could overload an execution node. Without snapshots and rollback, recovering from failure becomes much more difficult.

5. State, Memory, and Recovery

Long-running tasks cannot always be completed in a single iteration. The runtime must maintain a task state machine that records:

• The current phase.
• Completed actions.
• Items awaiting validation.
• Failure causes.
• Recovery points.

State management allows an agent to resume after interruption and prevents it from repeating high-risk actions unnecessarily.

Memory can be divided into three categories:

• Short-term tool results.
• Task-level summaries.
• Long-term project knowledge.

Short-term memory preserves continuity within the current task. Task-level summaries control context length. Long-term knowledge depends on retrieval and permission controls.

Recovery is a major source of product-level differentiation. When the same test fails, one runtime may locate the relevant logs and retry with a correction, while another may stop after displaying the error message.

6. Permissions, Auditing, and Observability

In enterprise environments, the most important question is often not whether a coding agent can generate code, but whether it can be managed responsibly.

Permission controls should include:

• Least-privilege access.
• Approval levels.
• Additional confirmation for sensitive operations.

Audit mechanisms should record:

• Model decisions.
• Tool calls.
• File changes.
• Command execution.
• Validation results.

Observability should track metrics such as:

• Task success rate.
• Average number of iterations.
• Tool failure rate.
• Context cost.
• Latency.
• Human takeover rate.

These features may not directly make the model appear more intelligent, but they determine whether the agent can become part of a real software development process. In many cases, the product’s sense of reliability comes from carefully designed permissions and auditing rather than from the model alone.

Evaluation and In-House Development: Do Not Ask Only Which Model Is Best

Coding agents should be evaluated layer by layer.

Model-Level Evaluation

Focus on:

• Code understanding.
• Patch generation.
• Test repair.
• Compliance with tool-calling formats.
• Long-context utilization.
• Failure correction.

The evaluation set should be based on tasks from real repositories rather than simple question-answering benchmarks alone.

Runtime-Level Evaluation

Focus on:

• Tool completeness.
• Context-management strategies.
• Sandbox isolation.
• State recovery.
• Configurable permissions.
• Process auditing.
• Reliability of the validation loop.

A product with a very strong model but a poorly engineered runtime may deliver a worse practical experience than one with a moderately capable model and a robust runtime.

Engineering Integration Evaluation

Also consider whether the agent:

• Fits the organization’s existing development workflow.
• Integrates with version control and testing systems.
• Produces structured process records.
• Supports a suitable combination of private or cloud deployment capabilities.

For cloud deployments, container platforms can be used to host isolated execution environments, while logging and monitoring services can provide process observability. Object storage can preserve task artifacts and audit records. Baidu AI Cloud can provide these types of general-purpose cloud capabilities, but the final architecture should still be determined by task boundaries, security and compliance requirements, and cost constraints.

A Practical Path for Building an Agent

When building an agent in-house, it is usually better not to pursue a fully featured platform from the start.

A more practical sequence is:

1. Define the tool protocol and task state machine.
2. Implement the minimum closed loop:
   • Read code.
   • Modify code.
   • Run validation.
   • Return results.
3. Add context compression and failure recovery.
4. Add permission approval and auditing.
5. Use evaluation sets to continuously optimize the combination of model and runtime.

This approach keeps the initial system focused while creating a foundation for later improvements.

Conclusion

After extended use, multiple coding agents may seem like the same product. This does not necessarily mean they are built from the same product or service. More likely, they share a common architectural pattern:

The model provides reasoning capability, while the runtime organizes that capability into an executable, verifiable, and auditable loop.

Models and agent products are different things. Foundation models and coding agent products also exist at different layers.

Understanding the separation between the model layer and the runtime layer helps developers evaluate products more rationally, design in-house systems more effectively, and treat security, auditing, recovery, and validation as equally important to model capability in enterprise deployments.