# Can we actually build a Harness on top of Cursor agent? **URL:** \ **Category:** Discussions\ **Created:** [July 7, 2026, 12:52pm UTC](https://forum.cursor.com/t/can-we-actually-build-a-harness-on-top-of-cursor-agent/165028 "2026-07-07T12:52:09Z")\ **Posts on this page:** 9\ **Page:** 1
**Author:** ![Congzhi](https://sea3.discourse-cdn.com/cursor1/user_avatar/forum.cursor.com/congzhi/32/113299_2.png) [@Congzhi](https://forum.cursor.com/u/Congzhi)\ **Post date:** [July 7, 2026, 12:52pm UTC](https://forum.cursor.com/t/can-we-actually-build-a-harness-on-top-of-cursor-agent/165028/1 "2026-07-07T12:52:09Z")
* * * ## 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? * * * ---
**Author:** ![deanrie](https://sea3.discourse-cdn.com/cursor1/user_avatar/forum.cursor.com/deanrie/32/1263_2.png) [@deanrie](https://forum.cursor.com/u/deanrie)\ **Post date:** [July 8, 2026, 6:29am UTC](https://forum.cursor.com/t/can-we-actually-build-a-harness-on-top-of-cursor-agent/165028/4 "2026-07-08T06:29:25Z")
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](https://cursor.com/docs/cli/headless) - 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](https://cursor.com/docs/sdk/typescript) and [Cursor Python SDK | Cursor Documentation](https://cursor.com/docs/sdk/python) On separating layers, you’re basically right. `AGENTS.md` and Rules [Rules | Cursor Docs](https://cursor.com/docs/rules) 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. ---
**Author:** ![Chris\_Bellairs](https://avatars.discourse-cdn.com/v4/letter/c/76d3ee/32.png) [@Chris\_Bellairs](https://forum.cursor.com/u/Chris_Bellairs)\ **Post date:** [July 9, 2026, 5:53pm UTC](https://forum.cursor.com/t/can-we-actually-build-a-harness-on-top-of-cursor-agent/165028/5 "2026-07-09T17:53:43Z")
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: > **[GitHub - chrisrackstallion/pitchd-rails-cursor-plugin](https://github.com/chrisrackstallion/pitchd-rails-cursor-plugin)** > > Contribute to chrisrackstallion/pitchd-rails-cursor-plugin development by creating an account on GitHub. ---
**Author:** ![Congzhi](https://sea3.discourse-cdn.com/cursor1/user_avatar/forum.cursor.com/congzhi/32/113299_2.png) [@Congzhi](https://forum.cursor.com/u/Congzhi)\ **Post date:** [July 10, 2026, 3:31am UTC](https://forum.cursor.com/t/can-we-actually-build-a-harness-on-top-of-cursor-agent/165028/7 "2026-07-10T03:31:39Z")
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? ---
**Author:** ![Congzhi](https://sea3.discourse-cdn.com/cursor1/user_avatar/forum.cursor.com/congzhi/32/113299_2.png) [@Congzhi](https://forum.cursor.com/u/Congzhi)\ **Post date:** [July 10, 2026, 3:59am UTC](https://forum.cursor.com/t/can-we-actually-build-a-harness-on-top-of-cursor-agent/165028/9 "2026-07-10T03:59:05Z")
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. ---
**Author:** ![Chris\_Bellairs](https://avatars.discourse-cdn.com/v4/letter/c/76d3ee/32.png) [@Chris\_Bellairs](https://forum.cursor.com/u/Chris_Bellairs)\ **Post date:** [July 10, 2026, 5:01am UTC](https://forum.cursor.com/t/can-we-actually-build-a-harness-on-top-of-cursor-agent/165028/10 "2026-07-10T05:01:25Z")
@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. ---
**Author:** ![Congzhi](https://sea3.discourse-cdn.com/cursor1/user_avatar/forum.cursor.com/congzhi/32/113299_2.png) [@Congzhi](https://forum.cursor.com/u/Congzhi)\ **Post date:** [July 10, 2026, 8:21am UTC](https://forum.cursor.com/t/can-we-actually-build-a-harness-on-top-of-cursor-agent/165028/11 "2026-07-10T08:21:07Z")
Sweet! I’ll take a look at your masterpiece ---
**Author:** ![deanrie](https://sea3.discourse-cdn.com/cursor1/user_avatar/forum.cursor.com/deanrie/32/1263_2.png) [@deanrie](https://forum.cursor.com/u/deanrie)\ **Post date:** [July 10, 2026, 1:52pm UTC](https://forum.cursor.com/t/can-we-actually-build-a-harness-on-top-of-cursor-agent/165028/14 "2026-07-10T13:52:40Z")
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: - Permissions / Run modes: allow/ask/deny lists that gate command execution and edits: [Permissions | Cursor Docs](https://cursor.com/docs/cli/reference/permissions) and [Run Modes | Cursor Docs](https://cursor.com/docs/agent/security/run-modes) - Hooks: scripts that run on agent events and can block actions programmatically: [Hooks | Cursor Docs](https://cursor.com/docs/hooks) - `.cursorignore`: restricts file access: [Ignore File | Cursor Docs](https://cursor.com/docs/context/ignore-files) 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](https://forum.cursor.com/t/security-privacy-issue-llms-will-attempt-to-circumvent-cursorignore/148441). 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. ---
**Author:** ![system](https://sea3.discourse-cdn.com/cursor1/user_avatar/forum.cursor.com/system/32/99069_2.png) [@system](https://forum.cursor.com/u/system)\ **Post date:** [October 8, 2026, 1:52pm UTC](https://forum.cursor.com/t/can-we-actually-build-a-harness-on-top-of-cursor-agent/165028/15 "2026-10-08T13:52:57Z")
This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.