How AI Agents Work: Prompt, Context, Harness & Loop Explained
In a Nutshell
Prompt engineering frames better questions; context engineering supplies the right information. Harness engineering gives the model tools, guardrails, and feedback so it can act instead of just respond. Loop engineering removes the human trigger by building a system that repeatedly prompts, monitors, and verifies until a verifiable goal is met, provided the task repeats and has a crisp exit condition.
These notes were generated by AI and may contain inaccuracies.
The AI world loves buzzwords. New terms are popping up faster than most people can track, and it's getting hard to tell which ones actually mean something and which are just noise. That confusion is a problem. When everything sounds important, nothing does. But a few of these terms are worth knowing because they genuinely build on each other in a useful way: prompt engineering, context engineering, harness engineering, and loop engineering.
Prompt engineering is how to talk to AI. How you frame it matters as much as what you ask. A generic question like "What makes a Netflix show successful?" produces a paragraph about popular genres and viewership trends that could have been copied from a blog post, with no structure, no hypotheses, nothing actionable. This is a prompt engineering problem - the model was given no role, no specific question, no output format.
A better prompt: "You are a data analyst looking at Netflix content. What are three hypotheses for why TV shows might get renewed more often than movies? For each hypothesis, suggest one metric I could use to test it." This produces three structured hypotheses, each with a specific metric that can be tested. Role, specific question, output format - these three elements make the difference.
Prompt engineering works great for one-off questions, but the model still knows nothing about the actual project - column names, data quality issues, specific words of a CSV, or code. Every time something specific to the project is needed, the process starts from zero.
Context engineering manages what information is made accessible to the model when generating a response. While prompt engineering focuses on how instructions are phrased, context engineering handles prompt instructions, data, chat history, and documents.
Andrej Karpathy defined it as "the delicate art and science of filling the context window with just the right information for the next step." The context window is everything the model sees at inference time. Context engineering is deciding what's relevant for this task right now and making sure that's what the model is working from.
More context is not always better. There is "context rot" - Groma research tested 18 frontier models in 2025 and found every single one gets worse as input length grows. The degradation starts well before the context window is even close to full. A model with a 200k token window can start losing quality at 50k. The right context matters, not more context.
Both prompt and context engineering share the same ceiling - after every exchange, the user is back reading the output, deciding what to do next, typing again. Harness engineering changes this by giving the model tools so it can actually act. A harness provides guardrails to keep it safe and feedback loops. It enables reading files, executing code, observing what happened, and reacting to it. It turns a model that talks into an agent that works.
Not all harnesses are equal. Cloud agent and CodeX are opinionated - they handle context compaction, memory, and tool orchestration largely behind the scenes. Pie, a minimal agent harness, takes the opposite approach with four core built-in tools, a system prompt under 1,000 tokens, and full transparency over everything the agent does. One gives speed and convenience, the other gives control and auditability. It's a dial between autonomy and control.
A harness takes over context management. Instead of the user deciding what to pass in at each step, the harness handles it. LangChain's docs describe this as compression isolation and memory working together so the agent can run for hours without manually trimming anything.
In a demonstration, giving a harness the instruction "Run the Netflix analysis notebook from top to bottom. If any cells fail, identify the error, fix it, and rerun until the entire notebook executes cleanly" allows it to read the notebook, execute it, read the actual error output, edit the broken cell, and rerun to verify the fix - all without additional user input.
With a harness, the model executed, observed the real result, reacted to it, and verified the fix, but the user was still the trigger - deciding when to start it, and when it finished, it stopped and waited. Loop engineering is designing the system that prompts the AI agent instead of prompting it yourself.
If stacked side by side: prompt engineering crafts the perfect message; context engineering assembles the perfect information around that message; harness engineering gives the agent guardrails, feedback loops, skills, and tools so it can act, not just respond; loop engineering builds a thing that triggers all of that automatically.
In Cloud, loops can be triggered via the /loop command: "Loop every 50 minutes if the Kaggle Netflix data set has new rows or any changes in the entries since the last run. Then, rerun the analysis notebook and append the summary of what changed to updates.log." This creates a background task that wakes up every 50 minutes, checks for changes, pulls updates if they exist, reruns the notebook, and logs what changed.
A more powerful primitive is "goal" - loop runs on a timer, goal runs until a condition is true. Example: "/goal notebook runs end-to-end with no errors and updates.log contains one new entry from today's date." The agent implements this using a separate evaluator that checks whether the condition is actually met. The worker and the checker are kept apart because whatever just wrote the code has every reason to believe it's good - an independent check doesn't.
Observe, decide, act, verify, repeat - that's the loop.
Token costs compound fast. A single agent loop on a medium task burns many tokens compared to a normal chat interaction. Running on a schedule, adding subagents, and letting it retry failures multiplies this again. Always set a hard token budget and a maximum iteration count before starting a loop.
A vague goal creates a runaway loop. "Make this goal better" may never stop because the agent can't tell when it's done. Every loop needs a condition that can actually be verified - test passed, file exists, column count matches. If a binary check can't be written for it, it's not a loop goal, it's a conversation.
Loops are not for everything. If the task isn't repetitive, doesn't have a clear done condition, or requires judgment calls a test can't catch, stay in the harness. Loop engineering earns its complexity only when the work genuinely repeats and the definition of done is crisp.
Keep JetBrains in your library
Save the videos and channels worth coming back to, and find them again in one place.
