In February 2026 Cursor published the results of an experiment that is easy to dismiss as a lab curiosity. They built a harness that let thousands of AI agents work together on one codebase, a web browser, continuously for a week. At its peak the system produced around a thousand commits per hour without human intervention.
The interesting part is not the number. The interesting part is everything that failed before it worked. Because the failures were not model failures. They were organisational failures. And they map almost one to one onto what happens when you put agents to work in a staffing or professional services operation.
Lesson one: no ownership means no results
The first design was the most obvious one. Equal agents, one shared file where everyone could see what the others were doing, and the freedom to pick up work. It collapsed immediately. Agents held locks too long, forgot to release them, and waited on each other. Twenty agents delivered the throughput of one or two.
Worse: nobody took on the hard work. Without ownership every agent chose the small, safe change. Exactly what happens when you drop a generic assistant into a back office without giving it a clear scope. It summarises, it suggests, it never closes a case.
“The lack of structure meant no agent took responsibility for the project as a whole. They avoided contention and opted for smaller, safer changes.”
Lesson two: separate planning from execution
The breakthrough came from roles. A planner that owns the entire goal and writes no code itself. Subplanners that fully own a narrow slice. Workers that pick up one task, drive it to completion and report back. Recursive, with clear boundaries.
Translate that to a timesheet close. The planner owns the question: is this period ready for invoicing? It splits the work into slices per client, per contract type, per exception. Workers match hours to schedules, chase a missing approval, flag a rate that does not fit the agreement. None of them decides on their own that the period is closed. That stays with the owner.
Lesson three: the handoff is the product
In the Cursor system a worker does not report just what it did. The handoff contains concerns, deviations, findings and feedback. That message goes to the planner that asked for the task, which keeps the system in motion and lets information travel upward without everyone talking to everyone.
This is the single most underrated part for operational work. An agent that closes a case silently gives you nothing. An agent that reports 'invoice prepared, but the PO number on this assignment differs from the contract' gives you an operation that gets smarter every month. The handoff is where the audit trail, the exception list and the improvement backlog are born at the same time.
Lesson four: perfection kills throughput
Cursor tried demanding one hundred percent correctness before every commit. The system ground to a halt. A single typo made agents leave their scope, pile onto the same issue and block each other. Accepting a small, stable error rate, with a regular clean-up pass on a green branch, produced far more useful output.
In an operation you cannot apply that carelessly. An invoice to the wrong entity costs weeks. So you split the work: reversible steps run at full speed with a low, monitored error rate, and irreversible steps get a human gate. That distinction is a design decision, not a technical one, and it is where most agent projects go wrong.
Lesson five: your environment determines throughput
One of the most practical findings: once memory was under control, the disk became the bottleneck. Hundreds of agents compiling at once dominated the run time. The project structure and the tooling determined the output, not the intelligence of the models.
The same holds in professional services. If your core data on clients, professionals, assignments, contracts and margin is scattered across five systems that do not agree, agents spend their time reconciling instead of resolving. The ceiling on your agents is not the model. It is your foundation.
“The way you organise your systems determines the throughput of your agents, long before the model does.”
Lesson six: vague instructions get amplified
The final observation is the sharpest. With orders of magnitude more compute, every unclear instruction gets amplified. Agents follow your specification exactly, including the parts you never thought through. Vague goals produce agents that go deep on obscure details while the important work stands still.
That is why we start every engagement by mapping the process as it actually runs, not as it is documented. Which exceptions occur, who decides, what counts as done. Writing that down is most of the work. The agents come after.
What we take into our own builds
- 01Give every agent a scope and an owner. No generic assistants floating across the process.
- 02Split planning from execution, and let planners decide, not type.
- 03Make the handoff rich: what happened, what deviated, what needs attention.
- 04Set the error budget per step. Reversible work runs fast, irreversible work gets a human gate.
- 05Fix the foundation first. Aligned core data raises the ceiling for everything above it.
- 06Invest in the specification. It is the highest-leverage document in the whole system.
Cursor's experiment ran on a browser. Your operation runs on contracts, hours, invoices and exceptions. The architecture question is the same: who owns what, how does information travel, and where do you accept error. Agentic engineering is answering those questions well, and only then writing the agents.
Source: Cursor, Towards self-driving codebases, February 2026.
