The Rise of Contract-Based Agents: Comparing My "Contract-First" Approach to Karpathy's "LOOPS.md"

Introduction

The conversation around AI agents is shifting rapidly from "vibe-based prompting" to structured system architecture. If you've been following recent developments, you might have seen Andrej Karpathy's technical notes, LOOPS.md, which outline rules for letting models run autonomously.

One section in his notes particularly stood out to me: "III. NEGOTIATE THE CONTRACT FIRST."

Reading it felt incredibly familiar. Back in April, I published a detailed guide on Dev.to titled Contract-Based Design: How I Make AI Agents Work Faster Without Breaking Each Other.

It is fascinating to see two independent developers—operating at different scales—arrive at the exact same structural solution to the same problem. Here is a breakdown of why this pattern is emerging as an industry standard.

The Common Ground: Why "Contract-First"?

Both my April article and Karpathy's June/July notes highlight a critical bottleneck: unstructured agent interaction leads to high failure rates.

Naively letting agents generate code or make API calls on the fly results in drift, broken dependencies, and infinite loops. The solution we both independently developed relies on a simple, elegant mechanism: Markdown (.md) files on disk acting as negotiated contracts before execution.

Here is how the two approaches compare side-by-side:

Where the Architectures Diverge (And Complement Each Other)

While the mechanism is nearly identical, our primary engineering goals differed slightly. Looking at both together provides a full picture of how to build robust systems:

1. My Focus: Decoupling for Parallel Performance

In my original post, my main goal was speed and horizontal scaling.
In standard pipelines, agents are sequentially dependent (Frontend waits for Backend, which waits for Database). By writing the contract first, you shift from agent dependencies to data dependencies.

• Once the .md contract is on disk, a frontend agent can build using mock data defined in the contract, while the backend agent concurrently builds the actual implementation. They work in parallel without blocking each other.

2. Karpathy's Focus: Guardrails for Autonomous Iteration

In LOOPS.md, the primary goal is reliability over long, unattended runs.
Karpathy uses the contract as an immutable rubric for an independent Evaluator agent. The Generator and Evaluator "argue" via markdown until they agree on the assertions.

• Once agreed, the contract acts as a rigid grading sheet. If the run goes sideways later, the system can safely restart and try again because the contract prevents the model from grading its own homework or drifting.

Here is a rewritten version of the conclusion that highlights your perspective as a hands-on developer. It emphasizes that your approach was born out of practical engineering and daily debugging on the ground, rather than theory.

Conclusion: Pragmatic Engineering Meets Research Validation

I didn't arrive at this approach through academic or theoretical research. I am a developer, and Contract-Based Design was born entirely out of practical, hands-on frustration—specifically, watching my agents break, block each other, and fail in real-world scenarios. I built this pattern simply because I needed a reliable way to make my code ship faster without constant pipeline failures.

Seeing the exact same markdown-based contract pattern formalized in LOOPS.md from a research perspective is highly validating. It suggests that whether you approach agent design from a high-level research framework or from late-night debugging on the ground, the practical reality is the same: letting models write code without a strict, upfront interface contract simply does not scale.

If you are a developer looking to solve these exact multi-agent coordination bottlenecks in your own projects, you can read my original, hands-on implementation guide here:

👉 Contract-Based Design: How I Make AI Agents Work Faster Without Breaking Each Other