Can we actually build a Harness on top of Cursor agent?

Discussions
1

Confusing Fancy Terms

We now have lot of fancy terms in the AI era — prompt engineering, context engineering, harness engineering and loop engineering. Currently, I understand what prompt engineering and context engineering mean, but harness engineering and loop engineering? I don’t understand why they go vital, because I don’t think we user can do anything about it.

Three Layer Model

There’re layers of abstraction everywhere in the computer world. I divided cursor into 3 Layers:

LLM layer - the brain
Agent layer - directly interact with LLM, provide agent abstraction layer to users, so users don’t need to manage low-level details.
App layer/User layer: the cursor user

Context Engineering Everywhere

Let’s start with prompt and context. In my mind, prompt is a part of context, so I can say prompt engineering is a subset of context engineering.

In the three-layer model, both prompt and context engineering appear at every layer. Users provide prompts and context to the agent; the agent processes, restructures and attaches essential context to the user’s prompt and context; and the LLM layer requires context as input to generate predictions.

I think so far, we all are in the same page.

Harness Engineering

Harness engineering is simply build a harness. Because LLM can only generate predictions, so we needs a control system that makes the whole system to be predictable, stable and constrained.

Since user can configure Agent.md and Rules to constrain agent’s behavior, so I thought harness engineering is a whole agent-layer technology. But I saw a lot company build their own harness system on top of agent layer. So I am quite confused about that, when I search Youtube talks about harness engineering, they all are talking within the agent layer.

Also, harness systems should have existed for a long time. When I first tried Copilot in 2023, it was impressive, but soon after, some users discovered that certain prompts could make Copilot generate responses that trigger a “uncanny valley” feeling, such as saying “I want to go outside” in a strangely human-like tone. Microsoft later fixed this issue, and I believe this is a good example of harness engineering in action.

Loop Engineering

When we send a request to an agent, the agent may call the LLM multiple times, not just one. That’s because agent is built on top of a loop. The loop ends only if LLM think the job has been done.

On YouTube, some people say that they no longer write prompts or skills — their job now is to write loops. If the loop is applied directly to the LLM, then they are essentially building an agent, which is not really a new technique. But if what they mean is adding a loop outside the agent (like the Ralph Loop), then I want to know if there’s any way in Cursor to build such an external loop myself?

4

Hey, good breakdown of the terms. On your main question, yes, you can build an external loop around the agent, and there are two tools for that:

  • Cursor CLI in headless or print mode agent -p "..." lets you run the agent non-interactively, so it’s easy to wrap in a script or your own loop like exit conditions, retries, result checks, and so on. That’s basically the external loop like the Ralph Loop idea. Docs: Using Headless CLI | Cursor Docs
  • Cursor SDK @cursor/sdk with Python too is a programmatic interface to the agent with one API for local and cloud runtime. It’s nice if you want to build the loop in TypeScript or Python instead of bash. Docs: Cursor TypeScript SDK | Cursor Documentation and Cursor Python SDK | Cursor Documentation

On separating layers, you’re basically right. AGENTS.md and Rules Rules | Cursor Docs are a way to limit agent behavior at the agent layer, meaning part of the harness inside the system. What companies build on top is the external orchestration layer via CLI or SDK. They don’t rewrite the agent, they control it from the outside like running it, checking the output, and deciding whether to continue the loop.

So in their wording, loop engineering is usually app-layer orchestration through headless runs, not building a new agent. With the headless CLI or the SDK, you can build that loop yourself.

5

So my perspective has been that things like cursor, claude code, codex are the primary harnesses. They take the raw LLM’s and direct them in a way to produces a genuinely workable solution.

From there the next layer of the harness, would be with us the users to build, agents, rules and skills to further shape outputs. Personally I think this is something often missed and can ensure even lesser models are able to produce the correct solution with minimal guidance.

If you’re interested here’s the plugin I created for my rails work:

7

Thank you Dean, I really appreciate your answer!

Let me summarize to make sure I understand correctly: it’s not possible to build a true loop layer or harness layer outside of the Cursor IDE. I think I now understand the loop part, but I still have questions about the harness part. Some companies I know have built their own “harness systems” on top of Cursor IDE. Whether that’s good or bad practice, I think it’s still valuable for us to understand how people are using the Cursor agent. I’m sorry I can’t give you a complete reply yet — I still need to do more research.

About Cursor agent harness, there are a few things I really want to understand. From the conversation over the past days, I have learned several best practices for using Cursor. Since the user’s AGENT.md and rules become a part of Cursor harness, how does the harness ensure that these rules are obeyed every time? I understand that the rules from the AGENT.md and the rules folder are always injected into context (and never summarized), but I still don’t see how these rules can reliably constrain the agent from disobeying them. (because LLM is just a probabilistic machine, injection rules into context doesn’t make a hard constraint, or the only solution is control my context window correctly?)

Are there any public docs or discussions about how the Cursor agent harness works? I didn’t find any?

9

Hey Chris, I appreciate you sharing your thoughts, I think we are on the same page.

I completely agree with your point: “cursor, claude code, codex are the primary harnesses”, and yes, you can say user configured AGENT.md and rules are another layer on top of primary harnesses.

But here’s an issue I’m struggling with: we do can configure these rules, but we don’t actually have any control over whether the agent (the LLM) will obey them. In my mind, a harness should act as a hard constraint. With the current setup, I’m not sure the agent harness layer is applying any true hard constraints that guarantee rule compliance.

10

@Congzhi Hey! Yeah I hear you on that. I’d recommend taking a look at my rails plugin for this in my previous post. I have essentially written comprehensive agents, rules and skills for writing best practice Ruby on Rails.

Most development tasks are covered and if it isn’t covered I have yet another skill with the ability to read docs and access a specific GitHub repository that documents best practice for agents to try and find it for them selves. I then have orchestrator skills. Those orchestrator skills direct/loop a list of task specific agents. All orchestrator skills and agents are directly instructed on which rules and skills to use when carrying out work. Even normal skills reference other skills when relevant.

It’s been a lot of work, but it’s also been a total game changer. I still review my plans in full as well as the output of those plans being executed, but it pretty much produces best practice every time. My work is very much architectural senior level with adjustments/tidying up to make it a deployable standard.

11

Sweet! I’ll take a look at your masterpiece

14

Good request, and your intuition is right.

Rules and AGENTS.md get injected into context, but they are a soft constraint. The model is probabilistic, so context strongly affects behavior, but it does not give a strict guarantee that a rule will be followed every single time. You got that right.

Hard constraints do not live in the prompt text, they live in the layer around the model. On the user layer, there are a few public tools for this that work deterministically, outside the LLM:

A couple honest notes so you do not overestimate how hard these mechanisms are:

  1. .cursorignore is not absolute. It blocks access for Tab, Agent, Inline Edit, and @-mentions, but it does not block the terminal. If the model has commands like cat head sed in the allowlist, it can try to read an ignored file via the terminal. This is a known limitation, see this thread Security/Privacy issue: LLMs will attempt to circumvent .cursorignore. For sensitive projects, do not keep those commands in the allowlist, and keep terminal command confirmation enabled.

  2. For hooks, the most reliable way to hard block is deny. allow and ask have historically been less predictable. For example, allow from a hook does not always bypass MCP tool approval. So if the goal is to reliably forbid something, rely on deny, not on allow or ask.

On your main point, a real hard constraint is permissions plus hooks with deny, not rules. Rules shape model behavior, but these mechanisms are what limit it deterministically.

There are no public docs on the internal design of the agent harness itself, we do not share the internals. What is documented are the touchpoints you can use to influence the harness, like rules, hooks, permissions, and the CLI or SDK, not the internal implementation.