The Work Is Inside the Parentheses

A line from Boris Cherny at Anthropic has been making the rounds: “I don’t prompt Claude anymore. My job is to write loops.” It is a good line because it captures a real transition in how people are starting to work with powerful models. The early era of LLMs was dominated by prompting: write the instruction, read the answer, adjust the instruction, try again. The next era is more procedural. Instead of asking the model to produce a single output, we build a system that can evaluate a state, take an action, observe the result, and continue until some condition has been satisfied.

I agree with the sentiment. The job is increasingly to write loops. But the more important thing is what a loop actually is.

A loop is not simply “let the model run for a while.” In programming, a loop has structure. It says: while this condition is not true, do this thing. Or: continue until this condition is met. There is always an evaluation followed by an execution. The system checks the state of the world, decides whether the condition has been satisfied, and either exits or performs another action. That is what makes it a loop rather than a long prompt.

So the real work is not merely creating an agent that can keep acting. It is defining the evaluation that tells the agent whether the last action mattered. What did we put inside the parentheses? What counts as done? What counts as better? What counts as a regression? What state needs to be carried forward so the next iteration is more informed than the last one?

That is why I think “loop engineering” is directionally right but incomplete. The leverage is in the evaluation. We are not just writing loops; we are creating systems that can evaluate chunks of work, decide whether they satisfy a condition, and then execute the next step accordingly.

Without that evaluation, a loop is just automated continuation. A powerful model can continue for a very long time. It can generate plans, search through tools, inspect files, make edits, summarize its progress, and try again. If the original goal is vague enough, it may eventually produce something plausible. But plausibility is not the same as correctness. If we say “build me App X,” and provide little else, then the model has to infer what App X means. It has to infer the users, the data model, the workflows, the edge cases, the integrations, the permissions, the interface, and the definition of success. A better model and a larger token budget will improve that process, but they do not eliminate the basic problem. The loop is spending intelligence to compensate for the absence of evaluation.

Software engineering gives us the cleanest version of this idea because software already has a culture of evaluation. A code agent can write code, run tests, inspect failures, patch the implementation, and repeat. In that environment, the loop has something concrete to check. Did the test pass? Did the build complete? Did the type checker succeed? Did the output match the expected fixture? The agent does not need to guess forever whether it is making progress. It can be told.

This is also how we think about our own agent infrastructure. One of the most important things we built was not a more elaborate prompt, but a deterministic way to evaluate the harness around the model. By using a mock LLM interface, we can test tool calling behavior, component interaction, handoffs, and context transitions without relying on a live model response every time. That lets us test the system around the non-deterministic component. Once that structure exists, the evaluation surface expands. We can run throughput tests, send millions of messages through the system, watch context compact and rehydrate, and observe agents operating as long-running processes rather than isolated chat sessions.

The lesson is not that everything should be deterministic. The lesson is that the non-deterministic part needs a deterministic frame around it. The model may decide how to interpret an ambiguous situation, but the system should know what state it is in, what tools are available, what result is expected, what action was taken, and what should be evaluated next. That is the difference between an agent that is merely active and an agent that is participating in a controlled process.

This becomes more important when we move from software engineering into enterprise workflows. Codebases come with files, tests, logs, types, git history, and build systems. Enterprises have SaaS tools, spreadsheets, process documents, ticket histories, Slack/Teams threads, data warehouses, browser-only workflows, tribal knowledge, and business rules that live in people’s heads. The process may be obvious to the team that runs it every day, but invisible to an agent unless it has been represented somewhere.

Take a simple business task: review a situation, decide what should happen next, and route it through the right process. On the surface, that sounds small. In reality, it depends on business context that is rarely contained in the prompt. The agent needs to know what the relevant entities are, where the data lives, which systems are authoritative, what the organization means by status or risk or priority, what actions are allowed, and what outcome would count as correct. A human employee often carries that context implicitly. They know which dashboard matters, which field is stale, which exception is normal, and which process doc is out of date. An agent does not know any of that unless the organization has represented it somewhere.

A high-end model can help discover these things. Given enough access and enough budget, it can inspect systems, read documentation, query endpoints, observe patterns, ask questions, and assemble a plausible ontology of the business. That is incredibly valuable. But if every future loop has to rediscover that ontology from scratch, then we have not built a system. We have built an expensive ritual.

The better pattern is to spend intelligence on discovery once, then preserve the result as managed context. This is how we think about the Agent Ontology Service, or AOS. A capable model can be given read-only access to explore the relevant systems, validate endpoints, map entities, identify relationships, and build an ontology layer around a business process. It can connect the language people use in the business to the systems where that language becomes data.

Once that ontology exists, the loop changes. The agent no longer has to begin with “go figure out what this company means.” It can begin with a more precise instruction: execute this process against this known context, under these constraints, and evaluate these outcomes. That shift matters enormously. It changes the cost profile because the loop is not spending tokens rediscovering the same background reality. It changes the reliability profile because the loop is now operating against a shared representation of the business. And it changes the improvement curve because the evaluation layer can become more complete over time.

This is the enterprise version of evaluation-driven development. Every business process contains a mix of deterministic and non-deterministic work. The judgment calls will remain judgment calls. The model may need to classify a situation, infer intent, summarize evidence, recommend an action, or decide which precedent applies. But once that ambiguous step has been resolved, the surrounding process can often become deterministic. If a risk is identified, route it to the right owner, attach the evidence, update the relevant system, create the follow-up task, and log the rationale. If required data is missing, request it from the source of truth. If an exception violates policy, escalate it through the correct path. If the workflow completes, write back the outcome and update the context for the next loop.

That is where context management becomes the control plane for agentic work. Context is not just memory. It is the durable state that allows loops to evaluate correctly across time. It tells the agent what exists, what matters, what has already been tried, what constraints apply, and what success looks like. It turns discovery into an asset rather than an expense. It allows expensive, high-autonomy work to be distilled into lower-cost, higher-determinism execution.

So yes, the job is to write loops. But in the enterprise, the job is more specifically to design the evaluations that make those loops worth running. The loop is the structure: evaluate, execute, repeat. The evaluation is the leverage. Context is what lets that learning persist.

The teams that win with agents will be the teams that know how to define success, capture business context, preserve ontology, and convert repeated judgment into durable process. The next frontier is not agents that can keep going. It is systems that know what they are checking for when they do.