{"content_id":"uxrumphsyw","slug":"prompt-context-harness-agentic-loop-engineering","locale":"en","schema_type":"TechArticle","category":"comparison","category_name":"Comparison","title":"Differences and Design Methods for Prompts, Context, Harnesses, Agentics, and Loop Engineering","summary":"Prompt, Context, Harness, Agentic, and Loop Engineering address instructions, information, the working environment, autonomous execution, and iterative improvement, respectively. This article explains the boundaries, integration structures, application sequences, validation metrics, and failure prevention methods for these five approaches from a practical perspective.","author":{"name":"Injoys Editorial Team","url":"https://injoys.com/ko/about"},"key_points":["Prompt engineering is the process of clearly defining objectives, constraints, examples, output specifications, and success criteria.","Context engineering manages the relevance, recency, and source of the information that AI uses to make decisions, as well as token efficiency.","Harness Engineering creates an environment where AI can operate reliably through tools, permissions, sandboxes, documentation structures, validators, and logs.","Agentic engineering delegates the selection of the next action and tools needed to achieve a goal to AI to a limited extent.","Loop engineering converges results by linking generation, verification, root cause analysis, correction, re-execution, and termination conditions."],"content_markdown":"If we lump all efforts to improve the quality of generative AI under the umbrella of “writing good prompts,” it becomes difficult to accurately diagnose the causes of failure. Prompt, context, harness, agentic, and loop engineering are not interchangeable buzzwords, but rather complementary design approaches that address distinct control aspects: **request formulation, information selection, execution environment, autonomous decision-making, and iterative improvement**.\n\n## Core Definitions of the Five Concepts\n\n| Category | Key Question | Primary Design Focus | Representative Output | Representative Success Criteria |\n|---|---|---|---|---|\n| Prompt Engineering | How should we instruct the AI to perform a task? | Instructions, constraints, examples, output format | Prompt templates, example inputs and outputs | Instruction compliance rate, format accuracy, quality of initial results |\n| Context Engineering | What should we show the AI right now? | System guidelines, search documents, conversation history, memory, tool results | Context assembly rules, search and summarization policies | Relevance, recency, evidence-based accuracy, token efficiency |\n| Harness Engineering | What kind of working environment should we create to make it difficult for the AI to make mistakes? | Tools, Permissions, Sandbox, Repository Structure, Validators, Logs | Work Rules, Tool Interfaces, Testing and CI, Runbooks | Reproducibility, Safety, Verifiability, Recoverability |\n| Agent-Centric Engineering | Who will decide the next action, and within what scope? | Goals, Plans, Tool Selection, State Transitions, Delegation | Agent Loop, Orchestration, Approval Points | Task Completion Rate, Appropriate Tool Selection, Human Intervention Rate |\n| Loop Engineering | How will we converge when the initial result is incorrect? | Generation, Evaluation, Cause Classification, Correction, Re-execution, Termination Conditions | Evaluator, Regression Testing, Retry Policy, Failure Classification | First-Pass Rate, Recovery Rate, Number of Iterations, Final Pass Rate |\n\nConnecting these five concepts in a single line yields the following:\n\n**Express a request → Present the necessary information → Provide a safe working environment → Allow the AI to choose its next action → Verify and improve until the results meet the criteria.**\n\n### Points to Note When Interpreting Terminology\n\nWhile “prompt engineering” and “agent” are relatively widely used terms, the scope of “harness engineering” still varies depending on the context. Some articles refer to nearly all execution layers—excluding the model—as a “harness,” while others narrow the definition to the rules, verification, and feedback structures that coding agent users create outside the repository. “Loop engineering” is also best understood as a practical term describing the design of generation and validation as a closed-loop feedback process, rather than a formal classification fixed by a single standard. ([OpenAI][1])\n\n## 1. Prompt Engineering: Designing the Quality of Instructions\n\nPrompt engineering is the process of making the instructions given to a model clear and verifiable. While it often produces the most noticeable effects in a single request-response cycle, it also applies to system messages and multi-turn dialogue rules.\n\nA good prompt typically separates the following elements:\n\n- **Goal:** What needs to be accomplished?\n- **Input:** What is the subject of analysis, and what are the input boundaries?\n- **Constraints:** What should not be done; acceptable ranges; length and format\n- **Output Contract:** The structure of the result (e.g., JSON, table, code snippet)\n- **Success Criteria:** What conditions must be met for the response to be considered correct?\n- **Handling Uncertainty:** How should the system handle situations where information is insufficient or conflicting?\n- **Examples:** Representative inputs and outputs that demonstrate the expected behavior\n\nA practical template can start simply, as shown below.\n\n```text\nObjective:\nInput:\nConstraints:\nOutput Format:\nSuccess Criteria:\nVerification Method:\nHandling Uncertainty:\nRepresentative Examples:\n```\n\nIt is important to define success criteria and empirical testing methods before refining the prompt. Not all failures can be resolved by modifying the prompt; costs, delays, tool errors, and incorrect data selection may be issues at other levels. ([Claude Platform Docs][2])\n\n### Problems That Prompt Engineering Effectively Solves\n\n- Issues where the output format frequently breaks\n- Issues where the priority of instructions is ambiguous\n- Problems where the input and output are relatively clear, such as classification, extraction, transformation, and summarization\n- Problems where performance stabilizes when representative examples are provided\n\n### Problems That Are Difficult to Solve with Prompts Alone\n\n- When necessary facts or files are missing from the input\n- When outdated or conflicting documents are mixed together\n- When external systems must be safely queried or modified\n- When multiple execution stages and failure recovery are required\n- When there is no way to objectively verify whether the result is correct\n\n## 2. Context Engineering: Designing the Information the AI Sees\n\nContext engineering is the process of selecting, organizing, compressing, and updating all the information available to the model at the moment it generates an answer. Context may include not only the prompt but also system guidelines, user requests, conversation history, search documents, memory, tool descriptions, tool execution results, the current time, permission status, and task progress.\n\nSince the context window is finite, the goal is not to “include as much as possible,” but rather to **include the necessary information at the right time**. Anthropic describes context as a critical but finite resource for agents and recommends strategies such as a minimal toolset, representative examples, runtime search, compression, and memory management for long interactions. ([Anthropic][3])\n\n### Key Design Principles\n\n1. **Relevance First:** Include only the information necessary for the current stage.\n2. **Source and Recency:** Manage the document’s creation date, version, owner, and reliability together.\n3. **On-Demand Retrieval:** Rather than pre-loading all data, retrieve it from files, databases, or search systems as needed.\n4. **Information Hierarchy:** Distinguish between fixed rules, current tasks, reference materials, and tool results.\n5. **Conflict Resolution:** If multiple sources conflict, specify priorities and the authoritative source.\n6. **Compression and State Preservation:** Summarize old conversations without losing decisions, unresolved issues, or supporting links.\n7. **Separation of Instructions and Data:** Establish boundaries to prevent sentences in web pages or documents from being treated as system commands.\n\n### Example\n\nWhen a customer support AI answers a question about refund policies, simply reinforcing the prompt “Provide an accurate answer” has its limitations. Proper context engineering involves retrieving and providing the customer’s country, purchase date, product type, current policy version, exceptions, and order status at the appropriate moment, while ensuring that the policy provisions used in the response are traceable.\n\n## 3. Harness Engineering: Designing the Environment Where AI Works\n\nA harness is the operational framework that connects the model’s intelligence to real-world tasks. Harness engineering involves designing the work environment so that common AI errors are prevented or detected early through documentation, tools, permissions, structure, automated validation, and feedback.\n\n### Key Components of the Harness\n\n| Component | Role | Example |\n|---|---|---|\n| Work Instructions | Specify procedures and prohibitions for repetitive tasks | `AGENTS.md`, runbooks, checklists |\n| Knowledge Structure | Enables AI to easily find necessary materials | Repository map, ADR, glossary, collection of examples |\n| Tool Interfaces | Clearly restrict inputs and outputs of actions | File search, database queries, code execution, deployment APIs |\n| Execution Environment | Isolates failures and improves reproducibility | Sandbox, container, fixed dependencies |\n| Validator | Automatically verifies that results meet criteria | Schema validation, unit tests, linters, policy checks |\n| Permissions and Authorization | Restrict risky actions | Least privilege, separation of read/write access, human approval |\n| Observability | Record what was observed and what actions were taken | Traces, logs, tool invocation records, costs |\n| Recovery Mechanisms | Safely roll back and resume after a failure | Checkpoints, rollbacks, retry budgets |\n\nOpenAI’s harness engineering case study describes the engineer’s role as extending beyond simply writing code to designing environments, intentions, repository knowledge, and loops of testing, verification, review, and recovery. The key is not to simply ask the AI to “try harder,” but to explicitly add the missing capabilities and signals to the environment. ([OpenAI][1])\n\n### Example Data Structure\n\n```text\n/ai\n  /instructions   # Common rules and role-specific guidelines\n  /skills # Procedures for repetitive tasks\n  /examples # Good and bad results\n  /evals # Evaluation data and scoring rules\n  /policies # Permissions, security, and approval policies\n  /runbooks # Troubleshooting and exception handling\n```\n\nThis structure itself is not the only correct answer. What matters is that the data remains up-to-date, contains minimal duplication or conflicts, is accessible to the AI when needed, and that the rules lead to automated verification.\n\n## 4. Agent-Based Engineering: Provide Goals and Tools, Then Delegate the Next Action\n\nAgentic engineering is a design approach that provides AI with goals, tools, task status, and boundary conditions, allowing it to independently choose the next steps within a certain range to achieve those goals.\n\nAnthropic defines a **workflow** as a system that coordinates LLMs and tools via a predetermined code path, and defines an **agent** as a system in which the model dynamically determines its own process and tool usage. OpenAI also describes an agent as a system in which an LLM manages workflow execution and dynamically selects tools to interact with external systems. ([Anthropic][4])\n\n### Basic Agent Loop\n\n1. Observe the current goal and state.\n2. Plan the next subgoal or action.\n3. Select a tool and execute it.\n4. Check the results and changes in the environment.\n5. Decide on one of the following: complete, modify, retry, or hand off to a human.\n\n### When Agents Are Appropriate\n\n- When the sequence of tasks varies with each input\n- When unstructured information—such as natural language, documents, or code—must be interpreted\n- When multiple tools must be used selectively\n- When plans must be adjusted based on intermediate results\n- When failure causes are diverse and a certain level of recovery is possible\n\n### When Agents Are Overkill\n\n- Simple automation with fixed rules and sequences\n- Tasks that can be reliably resolved with a single API call or SQL query\n- Tasks with no means of verification and extremely high error costs\n- Systems that perform irreversible actions—such as payments, deletions, or deployments—without approval\n- Multi-agent structures where the number of agents is increased merely to expand roles, even though a single agent would suffice\n\nAutonomy is not a binary concept. It can be categorized into: an advisory type that only makes recommendations; an execution type that allows only limited read/write access; a supervised type that requires approval at key stages; and a high-autonomy type that operates for extended periods within a low-risk scope. Autonomy should be expanded in stages according to task risk and verification capabilities.\n\n## 5. Loop Engineering: Designing a Verifiable Improvement Process\n\nLoop engineering is not simply a matter of retrying. It involves creating an explicit, closed-loop feedback system consisting of **generation → verification → root cause analysis → selection of a correction strategy → re-execution → termination decision**.\n\n### Components of a Proper Loop\n\n1. **Generate Candidates:** Create drafts, code, plans, or data transformation results.\n2. **Validation:** Execute tests, schema checks, reference data checks, policy checks, and rationale checks.\n3. **Classification of Causes:** Distinguish between instruction errors, missing context, tool failures, implementation defects, and evaluator defects.\n4. **Correction:** Apply the minimum changes necessary to address the cause of failure.\n5. **Re-execution:** Do not repeat the entire process from the beginning; instead, restart from the necessary steps.\n6. **Termination:** Stop when one of the following conditions is met: passing, reaching the maximum number of iterations, exceeding the cost limit, exceeding the time limit, or reaching the uncertainty threshold.\n7. **Regression Protection:** Verify that the new modification has not broken existing successful cases.\n\nAgent evaluation is more complex than single-turn evaluation, which considers only inputs and outputs. Since agents call tools multiple times and alter the state of the environment, it is necessary to examine not only the final result but also the process and environmental changes. The core of automated evaluation is providing an input and applying scoring logic to the output or the altered state. ([Anthropological][5])\n\n### Verifier Priorities\n\n- **Deterministic Verification:** Compilation, unit tests, schemas, mathematical constraints, and permission checks\n- **Reference-Based Validation:** Reference data, citations of original sources, database cross-checks\n- **Rule-Based Validation:** Prohibited words, required fields, policy conditions\n- **Model-Based Evaluation:** Items that are difficult to formalize into rules, such as style, semantic preservation, and overall quality\n- **Human Evaluation:** High-risk judgments, validity of the objective itself, and approval of exceptions\n\nWhenever possible, use deterministic validation first, and do not allow the model to self-score its own results based solely on model evaluation. When using model evaluation, include evaluation criteria, examples, bias checks, and human review of samples.\n\n## The Five Approaches Form a Hierarchy, Not Substitutes\n\nIn real-world systems, the five approaches operate together.\n\n- Prompts establish a **contract for current actions**.\n- Context provides the **state and rationale necessary for judgment**.\n- The harness provides **an actionable environment and safety mechanisms**.\n- Agent-based design allocates **the authority to choose the next action**.\n- Loop design **detects errors and converges quality**.\n\nTherefore, it is inaccurate to assume that “context engineering has replaced prompt engineering” or that “using agents eliminates the need for workflows.” The broader layer simply encompasses or utilizes the narrower layer, and for simple problems, a simple design may be more stable.\n\n## Practical Example: An AI Coding System That Fixes Bugs\n\nLet’s assume an AI is fixing a bug where “only certain users encounter a 500 error after logging in.”\n\n### Prompt Engineering\n\n- Verify the conditions under which the error occurs.\n- Do not modify the public API.\n- Resolve the issue with minimal changes.\n- Report test results and remaining risks after the fix.\n\n### Context Engineering\n\n- Issue description and error logs\n- Relevant request trace IDs\n- Files related to authentication and user models\n- Recent change history\n- Architecture rules and coding standards\n- Failed tests and execution environment information\n\n### Harness Engineering\n\n- Tools for repository search, file reading/editing, and test execution\n- Isolated branches and sandboxes\n- Formatters, linters, unit and integration tests\n- No-change zones and permission policies\n- Logs of all commands and file changes\n- Rollbacks and checkpoints in case of failure\n\n### Agent-Based Engineering\n\nAI selects the sequence of steps—reproduction, hypothesis formulation, exploration of relevant code, patching, testing, and result summarization—based on the situation. However, deployments or data changes require human approval.\n\n### Loop Engineering\n\nIf a test fails, instead of repeating the same command, the system classifies the failure type. If it’s a reproduction failure, it supplements context collection; if it’s a regression failure, it refines the patch; and if it’s an environment error, it restores dependencies and settings. The process ends when all required tests pass and justification for the change is documented.\n\n## How to Determine What Kind of Engineering Is Needed Based on Problem Symptoms\n\n| Symptom | Area to Check First |\n|---|---|\n| Output format or style is frequently inconsistent | Prompt |\n| Facts or files required for the answer are missing | Context |\n| Incorrect tool selection or execution of dangerous commands | Harness and permission design |\n| Many variations that are difficult to handle with a fixed sequence | Agent-based design |\n| Initial results are often incorrect, but automatic evaluation is possible | Loops and evaluators |\n| The cause of failure is unknown and difficult to reproduce | Observability of the harness |\n| Costs increase with each iteration without any improvement in quality | Cause classification, verification signals, and termination conditions |\n| The more data there is, the worse the answers become | Context organization and search policy |\n\n## Recommended Implementation Order\n\n### Step 1: First, establish success criteria and an evaluation set\n\nCollect representative tasks, challenging cases, and prohibited cases, and define how results will be evaluated. If no ground-truth data is available, at a minimum, establish a schema, required evidence, policy compliance, and human evaluation criteria.\n\n### Step 2: Establish a single-call baseline\n\nMeasure performance, cost, and latency using the simplest prompt and the minimum necessary context. Without a baseline, it is difficult to distinguish the effects of complexity when deploying an agent.\n\n### Step 3: Instrument context provisioning\n\nRecord which documents and tool results were included, how old they were, and whether they were actually used in the response. Distinguish between search failures and excessive context.\n\n### Step 4: Create a Minimal Harness\n\nReduce the number of tools and clarify their names and inputs. Prioritize sandboxes, least privilege, automated testing, logs, and checkpoints.\n\n### Step 5: Grant Limited Autonomy\n\nHave a single agent begin by performing read-only, low-risk tasks. Specify termination conditions and conditions for human handover, and require separate approval for write, delete, payment, and deployment permissions.\n\n### Step 6: Close the Validation and Recovery Loop\n\nLink failure classifications, remediation strategies, maximum number of iterations, cost limits, and regression tests. Expand the scope of tools and autonomy only after the success rate has stabilized.\n\n## Operational Metrics\n\nSince there are no universal target values, benchmarks must be set based on task risk and cost.\n\n| Metric | Meaning |\n|---|---|\n| Task Completion Rate | The percentage that meets the final success criteria |\n| First-Pass Success Rate | The percentage of tasks that passed on the first attempt without iterative corrections |\n| Recovery Rate | The percentage of tasks that succeeded through the loop after the first failure |\n| Average Number of Iterations | The number of cycles required to reach success or termination |\n| Tool Selection Error Rate | The percentage of inappropriate or unnecessary tool invocations |\n| Evidence Completeness | The percentage of key claims supported by traceable sources |\n| Human Intervention Rate | The percentage of cases requiring approval, modification, or re-instruction |\n| Cost and Delay per Successful Unit | The resources required to complete a single successful task |\n| Number of Safety Incidents | The number of authorization violations, incorrect writes, or irreversible actions |\n| Regression Failure Rate | Percentage of new changes that break existing successful cases |\n\n## Common Design Mistakes\n\n| Area | Mistake | How to Improve |\n|---|---|---|\n| Prompt | Cumulates all exceptions into a single sentence | Structure the rules and separate representative examples from evaluation criteria |\n| Prompt | Instructs to “write well” without success criteria | Specify format, required content, prohibited actions, and evaluation criteria |\n| Context | Includes all irrelevant documents | Use runtime search and step-by-step context |\n| Context | Provides both outdated and current policies | Manage versions, expiration dates, and source references |\n| Harness | Provides many tools with overlapping functionality | Design a minimal set of tools with clear parameters |\n| Harness | Lacks write permissions and rollback capabilities | Implement least privilege, sandboxing, and checkpoints |\n| Agent-based | Creates multiple agents from the start | Verify using a single agent and a deterministic workflow |\n| Agent-based | Allows continuous execution without completion conditions | Establish explicit termination, budget, and handover conditions |\n| Loop | Repeats the same request verbatim | Classify failure causes and change the points of correction |\n| Loop | Self-evaluates all results using a single generative model | Combines deterministic checks, reference comparisons, and human sample reviews |\n\n## Implementation Checklist\n\n- [ ] Are success conditions verifiable not only through text but also, to the extent possible, through machine-readable checks?\n- [ ] Are the priorities of prompts, reference materials, and tool outputs clearly separated?\n- [ ] Can the source, version, expiration date, and owner of documents be tracked?\n- [ ] Are tool names and parameters clear and free of overlap?\n- [ ] Are read, write, delete, payment, and deployment permissions separated by risk level?\n- [ ] Are there sandboxes to isolate failures and rollback mechanisms in place?\n- [ ] Are all critical actions and tool calls logged in a reproducible format?\n- [ ] Are there external validators, such as tests, schemas, and policy checks?\n- [ ] Are the maximum number of iterations, cost, time, and conditions for human handover defined?\n- [ ] Is there regression testing to ensure new improvements do not break existing use cases?\n\n## Conclusion\n\nA good AI system is not the one with the longest prompts. It is a system that distinguishes where failures occurred—whether in **instructions**, **information**, **environment**, **decision-making**, **verification and recovery**, and applies the simplest solution at that specific layer. A stable approach is to first establish success criteria and a baseline for a single call, then augment context and the harness only as much as necessary, and finally expand autonomy and the iteration loop within verifiable bounds.","content_html":"\u003cp\u003eIf we lump all efforts to improve the quality of generative AI under the umbrella of “writing good prompts,” it becomes difficult to accurately diagnose the causes of failure. Prompt, context, harness, agentic, and loop engineering are not interchangeable buzzwords, but rather complementary design approaches that address distinct control aspects: \u003cstrong\u003erequest formulation, information selection, execution environment, autonomous decision-making, and iterative improvement\u003c/strong\u003e.\u003c/p\u003e\n\u003ch2\u003e\u003ca href=\"#core-definitions-of-the-five-concepts\" class=\"anchor\" id=\"core-definitions-of-the-five-concepts\"\u003e\u003c/a\u003eCore Definitions of the Five Concepts\u003c/h2\u003e\n\u003cdiv class=\"overflow-x-auto\"\u003e\u003ctable\u003e\n\u003cthead\u003e\n\u003ctr\u003e\n\u003cth\u003eCategory\u003c/th\u003e\n\u003cth\u003eKey Question\u003c/th\u003e\n\u003cth\u003ePrimary Design Focus\u003c/th\u003e\n\u003cth\u003eRepresentative Output\u003c/th\u003e\n\u003cth\u003eRepresentative Success Criteria\u003c/th\u003e\n\u003c/tr\u003e\n\u003c/thead\u003e\n\u003ctbody\u003e\n\u003ctr\u003e\n\u003ctd\u003ePrompt Engineering\u003c/td\u003e\n\u003ctd\u003eHow should we instruct the AI to perform a task?\u003c/td\u003e\n\u003ctd\u003eInstructions, constraints, examples, output format\u003c/td\u003e\n\u003ctd\u003ePrompt templates, example inputs and outputs\u003c/td\u003e\n\u003ctd\u003eInstruction compliance rate, format accuracy, quality of initial results\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003eContext Engineering\u003c/td\u003e\n\u003ctd\u003eWhat should we show the AI right now?\u003c/td\u003e\n\u003ctd\u003eSystem guidelines, search documents, conversation history, memory, tool results\u003c/td\u003e\n\u003ctd\u003eContext assembly rules, search and summarization policies\u003c/td\u003e\n\u003ctd\u003eRelevance, recency, evidence-based accuracy, token efficiency\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003eHarness Engineering\u003c/td\u003e\n\u003ctd\u003eWhat kind of working environment should we create to make it difficult for the AI to make mistakes?\u003c/td\u003e\n\u003ctd\u003eTools, Permissions, Sandbox, Repository Structure, Validators, Logs\u003c/td\u003e\n\u003ctd\u003eWork Rules, Tool Interfaces, Testing and CI, Runbooks\u003c/td\u003e\n\u003ctd\u003eReproducibility, Safety, Verifiability, Recoverability\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003eAgent-Centric Engineering\u003c/td\u003e\n\u003ctd\u003eWho will decide the next action, and within what scope?\u003c/td\u003e\n\u003ctd\u003eGoals, Plans, Tool Selection, State Transitions, Delegation\u003c/td\u003e\n\u003ctd\u003eAgent Loop, Orchestration, Approval Points\u003c/td\u003e\n\u003ctd\u003eTask Completion Rate, Appropriate Tool Selection, Human Intervention Rate\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003eLoop Engineering\u003c/td\u003e\n\u003ctd\u003eHow will we converge when the initial result is incorrect?\u003c/td\u003e\n\u003ctd\u003eGeneration, Evaluation, Cause Classification, Correction, Re-execution, Termination Conditions\u003c/td\u003e\n\u003ctd\u003eEvaluator, Regression Testing, Retry Policy, Failure Classification\u003c/td\u003e\n\u003ctd\u003eFirst-Pass Rate, Recovery Rate, Number of Iterations, Final Pass Rate\u003c/td\u003e\n\u003c/tr\u003e\n\u003c/tbody\u003e\n\u003c/table\u003e\u003c/div\u003e\n\u003cp\u003eConnecting these five concepts in a single line yields the following:\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eExpress a request → Present the necessary information → Provide a safe working environment → Allow the AI to choose its next action → Verify and improve until the results meet the criteria.\u003c/strong\u003e\u003c/p\u003e\n\u003ch3\u003e\u003ca href=\"#points-to-note-when-interpreting-terminology\" class=\"anchor\" id=\"points-to-note-when-interpreting-terminology\"\u003e\u003c/a\u003ePoints to Note When Interpreting Terminology\u003c/h3\u003e\n\u003cp\u003eWhile “prompt engineering” and “agent” are relatively widely used terms, the scope of “harness engineering” still varies depending on the context. Some articles refer to nearly all execution layers—excluding the model—as a “harness,” while others narrow the definition to the rules, verification, and feedback structures that coding agent users create outside the repository. “Loop engineering” is also best understood as a practical term describing the design of generation and validation as a closed-loop feedback process, rather than a formal classification fixed by a single standard. ([OpenAI][1])\u003c/p\u003e\n\u003ch2\u003e\u003ca href=\"#1-prompt-engineering-designing-the-quality-of-instructions\" class=\"anchor\" id=\"1-prompt-engineering-designing-the-quality-of-instructions\"\u003e\u003c/a\u003e1. Prompt Engineering: Designing the Quality of Instructions\u003c/h2\u003e\n\u003cp\u003ePrompt engineering is the process of making the instructions given to a model clear and verifiable. While it often produces the most noticeable effects in a single request-response cycle, it also applies to system messages and multi-turn dialogue rules.\u003c/p\u003e\n\u003cp\u003eA good prompt typically separates the following elements:\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003e\u003cstrong\u003eGoal:\u003c/strong\u003e What needs to be accomplished?\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eInput:\u003c/strong\u003e What is the subject of analysis, and what are the input boundaries?\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eConstraints:\u003c/strong\u003e What should not be done; acceptable ranges; length and format\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eOutput Contract:\u003c/strong\u003e The structure of the result (e.g., JSON, table, code snippet)\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eSuccess Criteria:\u003c/strong\u003e What conditions must be met for the response to be considered correct?\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eHandling Uncertainty:\u003c/strong\u003e How should the system handle situations where information is insufficient or conflicting?\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eExamples:\u003c/strong\u003e Representative inputs and outputs that demonstrate the expected behavior\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003eA practical template can start simply, as shown below.\u003c/p\u003e\n\u003cpre\u003e\u003ccode\u003e\u003cspan\u003eObjective:\n\u003c/span\u003e\u003cspan\u003eInput:\n\u003c/span\u003e\u003cspan\u003eConstraints:\n\u003c/span\u003e\u003cspan\u003eOutput Format:\n\u003c/span\u003e\u003cspan\u003eSuccess Criteria:\n\u003c/span\u003e\u003cspan\u003eVerification Method:\n\u003c/span\u003e\u003cspan\u003eHandling Uncertainty:\n\u003c/span\u003e\u003cspan\u003eRepresentative Examples:\n\u003c/span\u003e\u003c/code\u003e\u003c/pre\u003e\n\u003cp\u003eIt is important to define success criteria and empirical testing methods before refining the prompt. Not all failures can be resolved by modifying the prompt; costs, delays, tool errors, and incorrect data selection may be issues at other levels. ([Claude Platform Docs][2])\u003c/p\u003e\n\u003ch3\u003e\u003ca href=\"#problems-that-prompt-engineering-effectively-solves\" class=\"anchor\" id=\"problems-that-prompt-engineering-effectively-solves\"\u003e\u003c/a\u003eProblems That Prompt Engineering Effectively Solves\u003c/h3\u003e\n\u003cul\u003e\n\u003cli\u003eIssues where the output format frequently breaks\u003c/li\u003e\n\u003cli\u003eIssues where the priority of instructions is ambiguous\u003c/li\u003e\n\u003cli\u003eProblems where the input and output are relatively clear, such as classification, extraction, transformation, and summarization\u003c/li\u003e\n\u003cli\u003eProblems where performance stabilizes when representative examples are provided\u003c/li\u003e\n\u003c/ul\u003e\n\u003ch3\u003e\u003ca href=\"#problems-that-are-difficult-to-solve-with-prompts-alone\" class=\"anchor\" id=\"problems-that-are-difficult-to-solve-with-prompts-alone\"\u003e\u003c/a\u003eProblems That Are Difficult to Solve with Prompts Alone\u003c/h3\u003e\n\u003cul\u003e\n\u003cli\u003eWhen necessary facts or files are missing from the input\u003c/li\u003e\n\u003cli\u003eWhen outdated or conflicting documents are mixed together\u003c/li\u003e\n\u003cli\u003eWhen external systems must be safely queried or modified\u003c/li\u003e\n\u003cli\u003eWhen multiple execution stages and failure recovery are required\u003c/li\u003e\n\u003cli\u003eWhen there is no way to objectively verify whether the result is correct\u003c/li\u003e\n\u003c/ul\u003e\n\u003ch2\u003e\u003ca href=\"#2-context-engineering-designing-the-information-the-ai-sees\" class=\"anchor\" id=\"2-context-engineering-designing-the-information-the-ai-sees\"\u003e\u003c/a\u003e2. Context Engineering: Designing the Information the AI Sees\u003c/h2\u003e\n\u003cp\u003eContext engineering is the process of selecting, organizing, compressing, and updating all the information available to the model at the moment it generates an answer. Context may include not only the prompt but also system guidelines, user requests, conversation history, search documents, memory, tool descriptions, tool execution results, the current time, permission status, and task progress.\u003c/p\u003e\n\u003cp\u003eSince the context window is finite, the goal is not to “include as much as possible,” but rather to \u003cstrong\u003einclude the necessary information at the right time\u003c/strong\u003e. Anthropic describes context as a critical but finite resource for agents and recommends strategies such as a minimal toolset, representative examples, runtime search, compression, and memory management for long interactions. ([Anthropic][3])\u003c/p\u003e\n\u003ch3\u003e\u003ca href=\"#key-design-principles\" class=\"anchor\" id=\"key-design-principles\"\u003e\u003c/a\u003eKey Design Principles\u003c/h3\u003e\n\u003col\u003e\n\u003cli\u003e\u003cstrong\u003eRelevance First:\u003c/strong\u003e Include only the information necessary for the current stage.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eSource and Recency:\u003c/strong\u003e Manage the document’s creation date, version, owner, and reliability together.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eOn-Demand Retrieval:\u003c/strong\u003e Rather than pre-loading all data, retrieve it from files, databases, or search systems as needed.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eInformation Hierarchy:\u003c/strong\u003e Distinguish between fixed rules, current tasks, reference materials, and tool results.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eConflict Resolution:\u003c/strong\u003e If multiple sources conflict, specify priorities and the authoritative source.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eCompression and State Preservation:\u003c/strong\u003e Summarize old conversations without losing decisions, unresolved issues, or supporting links.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eSeparation of Instructions and Data:\u003c/strong\u003e Establish boundaries to prevent sentences in web pages or documents from being treated as system commands.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch3\u003e\u003ca href=\"#example\" class=\"anchor\" id=\"example\"\u003e\u003c/a\u003eExample\u003c/h3\u003e\n\u003cp\u003eWhen a customer support AI answers a question about refund policies, simply reinforcing the prompt “Provide an accurate answer” has its limitations. Proper context engineering involves retrieving and providing the customer’s country, purchase date, product type, current policy version, exceptions, and order status at the appropriate moment, while ensuring that the policy provisions used in the response are traceable.\u003c/p\u003e\n\u003ch2\u003e\u003ca href=\"#3-harness-engineering-designing-the-environment-where-ai-works\" class=\"anchor\" id=\"3-harness-engineering-designing-the-environment-where-ai-works\"\u003e\u003c/a\u003e3. Harness Engineering: Designing the Environment Where AI Works\u003c/h2\u003e\n\u003cp\u003eA harness is the operational framework that connects the model’s intelligence to real-world tasks. Harness engineering involves designing the work environment so that common AI errors are prevented or detected early through documentation, tools, permissions, structure, automated validation, and feedback.\u003c/p\u003e\n\u003ch3\u003e\u003ca href=\"#key-components-of-the-harness\" class=\"anchor\" id=\"key-components-of-the-harness\"\u003e\u003c/a\u003eKey Components of the Harness\u003c/h3\u003e\n\u003cdiv class=\"overflow-x-auto\"\u003e\u003ctable\u003e\n\u003cthead\u003e\n\u003ctr\u003e\n\u003cth\u003eComponent\u003c/th\u003e\n\u003cth\u003eRole\u003c/th\u003e\n\u003cth\u003eExample\u003c/th\u003e\n\u003c/tr\u003e\n\u003c/thead\u003e\n\u003ctbody\u003e\n\u003ctr\u003e\n\u003ctd\u003eWork Instructions\u003c/td\u003e\n\u003ctd\u003eSpecify procedures and prohibitions for repetitive tasks\u003c/td\u003e\n\u003ctd\u003e\u003ccode\u003eAGENTS.md\u003c/code\u003e, runbooks, checklists\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003eKnowledge Structure\u003c/td\u003e\n\u003ctd\u003eEnables AI to easily find necessary materials\u003c/td\u003e\n\u003ctd\u003eRepository map, ADR, glossary, collection of examples\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003eTool Interfaces\u003c/td\u003e\n\u003ctd\u003eClearly restrict inputs and outputs of actions\u003c/td\u003e\n\u003ctd\u003eFile search, database queries, code execution, deployment APIs\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003eExecution Environment\u003c/td\u003e\n\u003ctd\u003eIsolates failures and improves reproducibility\u003c/td\u003e\n\u003ctd\u003eSandbox, container, fixed dependencies\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003eValidator\u003c/td\u003e\n\u003ctd\u003eAutomatically verifies that results meet criteria\u003c/td\u003e\n\u003ctd\u003eSchema validation, unit tests, linters, policy checks\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003ePermissions and Authorization\u003c/td\u003e\n\u003ctd\u003eRestrict risky actions\u003c/td\u003e\n\u003ctd\u003eLeast privilege, separation of read/write access, human approval\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003eObservability\u003c/td\u003e\n\u003ctd\u003eRecord what was observed and what actions were taken\u003c/td\u003e\n\u003ctd\u003eTraces, logs, tool invocation records, costs\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003eRecovery Mechanisms\u003c/td\u003e\n\u003ctd\u003eSafely roll back and resume after a failure\u003c/td\u003e\n\u003ctd\u003eCheckpoints, rollbacks, retry budgets\u003c/td\u003e\n\u003c/tr\u003e\n\u003c/tbody\u003e\n\u003c/table\u003e\u003c/div\u003e\n\u003cp\u003eOpenAI’s harness engineering case study describes the engineer’s role as extending beyond simply writing code to designing environments, intentions, repository knowledge, and loops of testing, verification, review, and recovery. The key is not to simply ask the AI to “try harder,” but to explicitly add the missing capabilities and signals to the environment. ([OpenAI][1])\u003c/p\u003e\n\u003ch3\u003e\u003ca href=\"#example-data-structure\" class=\"anchor\" id=\"example-data-structure\"\u003e\u003c/a\u003eExample Data Structure\u003c/h3\u003e\n\u003cpre\u003e\u003ccode\u003e\u003cspan\u003e/ai\n\u003c/span\u003e\u003cspan\u003e  /instructions   # Common rules and role-specific guidelines\n\u003c/span\u003e\u003cspan\u003e  /skills # Procedures for repetitive tasks\n\u003c/span\u003e\u003cspan\u003e  /examples # Good and bad results\n\u003c/span\u003e\u003cspan\u003e  /evals # Evaluation data and scoring rules\n\u003c/span\u003e\u003cspan\u003e  /policies # Permissions, security, and approval policies\n\u003c/span\u003e\u003cspan\u003e  /runbooks # Troubleshooting and exception handling\n\u003c/span\u003e\u003c/code\u003e\u003c/pre\u003e\n\u003cp\u003eThis structure itself is not the only correct answer. What matters is that the data remains up-to-date, contains minimal duplication or conflicts, is accessible to the AI when needed, and that the rules lead to automated verification.\u003c/p\u003e\n\u003ch2\u003e\u003ca href=\"#4-agent-based-engineering-provide-goals-and-tools-then-delegate-the-next-action\" class=\"anchor\" id=\"4-agent-based-engineering-provide-goals-and-tools-then-delegate-the-next-action\"\u003e\u003c/a\u003e4. Agent-Based Engineering: Provide Goals and Tools, Then Delegate the Next Action\u003c/h2\u003e\n\u003cp\u003eAgentic engineering is a design approach that provides AI with goals, tools, task status, and boundary conditions, allowing it to independently choose the next steps within a certain range to achieve those goals.\u003c/p\u003e\n\u003cp\u003eAnthropic defines a \u003cstrong\u003eworkflow\u003c/strong\u003e as a system that coordinates LLMs and tools via a predetermined code path, and defines an \u003cstrong\u003eagent\u003c/strong\u003e as a system in which the model dynamically determines its own process and tool usage. OpenAI also describes an agent as a system in which an LLM manages workflow execution and dynamically selects tools to interact with external systems. ([Anthropic][4])\u003c/p\u003e\n\u003ch3\u003e\u003ca href=\"#basic-agent-loop\" class=\"anchor\" id=\"basic-agent-loop\"\u003e\u003c/a\u003eBasic Agent Loop\u003c/h3\u003e\n\u003col\u003e\n\u003cli\u003eObserve the current goal and state.\u003c/li\u003e\n\u003cli\u003ePlan the next subgoal or action.\u003c/li\u003e\n\u003cli\u003eSelect a tool and execute it.\u003c/li\u003e\n\u003cli\u003eCheck the results and changes in the environment.\u003c/li\u003e\n\u003cli\u003eDecide on one of the following: complete, modify, retry, or hand off to a human.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch3\u003e\u003ca href=\"#when-agents-are-appropriate\" class=\"anchor\" id=\"when-agents-are-appropriate\"\u003e\u003c/a\u003eWhen Agents Are Appropriate\u003c/h3\u003e\n\u003cul\u003e\n\u003cli\u003eWhen the sequence of tasks varies with each input\u003c/li\u003e\n\u003cli\u003eWhen unstructured information—such as natural language, documents, or code—must be interpreted\u003c/li\u003e\n\u003cli\u003eWhen multiple tools must be used selectively\u003c/li\u003e\n\u003cli\u003eWhen plans must be adjusted based on intermediate results\u003c/li\u003e\n\u003cli\u003eWhen failure causes are diverse and a certain level of recovery is possible\u003c/li\u003e\n\u003c/ul\u003e\n\u003ch3\u003e\u003ca href=\"#when-agents-are-overkill\" class=\"anchor\" id=\"when-agents-are-overkill\"\u003e\u003c/a\u003eWhen Agents Are Overkill\u003c/h3\u003e\n\u003cul\u003e\n\u003cli\u003eSimple automation with fixed rules and sequences\u003c/li\u003e\n\u003cli\u003eTasks that can be reliably resolved with a single API call or SQL query\u003c/li\u003e\n\u003cli\u003eTasks with no means of verification and extremely high error costs\u003c/li\u003e\n\u003cli\u003eSystems that perform irreversible actions—such as payments, deletions, or deployments—without approval\u003c/li\u003e\n\u003cli\u003eMulti-agent structures where the number of agents is increased merely to expand roles, even though a single agent would suffice\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003eAutonomy is not a binary concept. It can be categorized into: an advisory type that only makes recommendations; an execution type that allows only limited read/write access; a supervised type that requires approval at key stages; and a high-autonomy type that operates for extended periods within a low-risk scope. Autonomy should be expanded in stages according to task risk and verification capabilities.\u003c/p\u003e\n\u003ch2\u003e\u003ca href=\"#5-loop-engineering-designing-a-verifiable-improvement-process\" class=\"anchor\" id=\"5-loop-engineering-designing-a-verifiable-improvement-process\"\u003e\u003c/a\u003e5. Loop Engineering: Designing a Verifiable Improvement Process\u003c/h2\u003e\n\u003cp\u003eLoop engineering is not simply a matter of retrying. It involves creating an explicit, closed-loop feedback system consisting of \u003cstrong\u003egeneration → verification → root cause analysis → selection of a correction strategy → re-execution → termination decision\u003c/strong\u003e.\u003c/p\u003e\n\u003ch3\u003e\u003ca href=\"#components-of-a-proper-loop\" class=\"anchor\" id=\"components-of-a-proper-loop\"\u003e\u003c/a\u003eComponents of a Proper Loop\u003c/h3\u003e\n\u003col\u003e\n\u003cli\u003e\u003cstrong\u003eGenerate Candidates:\u003c/strong\u003e Create drafts, code, plans, or data transformation results.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eValidation:\u003c/strong\u003e Execute tests, schema checks, reference data checks, policy checks, and rationale checks.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eClassification of Causes:\u003c/strong\u003e Distinguish between instruction errors, missing context, tool failures, implementation defects, and evaluator defects.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eCorrection:\u003c/strong\u003e Apply the minimum changes necessary to address the cause of failure.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eRe-execution:\u003c/strong\u003e Do not repeat the entire process from the beginning; instead, restart from the necessary steps.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eTermination:\u003c/strong\u003e Stop when one of the following conditions is met: passing, reaching the maximum number of iterations, exceeding the cost limit, exceeding the time limit, or reaching the uncertainty threshold.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eRegression Protection:\u003c/strong\u003e Verify that the new modification has not broken existing successful cases.\u003c/li\u003e\n\u003c/ol\u003e\n\u003cp\u003eAgent evaluation is more complex than single-turn evaluation, which considers only inputs and outputs. Since agents call tools multiple times and alter the state of the environment, it is necessary to examine not only the final result but also the process and environmental changes. The core of automated evaluation is providing an input and applying scoring logic to the output or the altered state. ([Anthropological][5])\u003c/p\u003e\n\u003ch3\u003e\u003ca href=\"#verifier-priorities\" class=\"anchor\" id=\"verifier-priorities\"\u003e\u003c/a\u003eVerifier Priorities\u003c/h3\u003e\n\u003cul\u003e\n\u003cli\u003e\u003cstrong\u003eDeterministic Verification:\u003c/strong\u003e Compilation, unit tests, schemas, mathematical constraints, and permission checks\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eReference-Based Validation:\u003c/strong\u003e Reference data, citations of original sources, database cross-checks\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eRule-Based Validation:\u003c/strong\u003e Prohibited words, required fields, policy conditions\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eModel-Based Evaluation:\u003c/strong\u003e Items that are difficult to formalize into rules, such as style, semantic preservation, and overall quality\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eHuman Evaluation:\u003c/strong\u003e High-risk judgments, validity of the objective itself, and approval of exceptions\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003eWhenever possible, use deterministic validation first, and do not allow the model to self-score its own results based solely on model evaluation. When using model evaluation, include evaluation criteria, examples, bias checks, and human review of samples.\u003c/p\u003e\n\u003ch2\u003e\u003ca href=\"#the-five-approaches-form-a-hierarchy-not-substitutes\" class=\"anchor\" id=\"the-five-approaches-form-a-hierarchy-not-substitutes\"\u003e\u003c/a\u003eThe Five Approaches Form a Hierarchy, Not Substitutes\u003c/h2\u003e\n\u003cp\u003eIn real-world systems, the five approaches operate together.\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003ePrompts establish a \u003cstrong\u003econtract for current actions\u003c/strong\u003e.\u003c/li\u003e\n\u003cli\u003eContext provides the \u003cstrong\u003estate and rationale necessary for judgment\u003c/strong\u003e.\u003c/li\u003e\n\u003cli\u003eThe harness provides \u003cstrong\u003ean actionable environment and safety mechanisms\u003c/strong\u003e.\u003c/li\u003e\n\u003cli\u003eAgent-based design allocates \u003cstrong\u003ethe authority to choose the next action\u003c/strong\u003e.\u003c/li\u003e\n\u003cli\u003eLoop design \u003cstrong\u003edetects errors and converges quality\u003c/strong\u003e.\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003eTherefore, it is inaccurate to assume that “context engineering has replaced prompt engineering” or that “using agents eliminates the need for workflows.” The broader layer simply encompasses or utilizes the narrower layer, and for simple problems, a simple design may be more stable.\u003c/p\u003e\n\u003ch2\u003e\u003ca href=\"#practical-example-an-ai-coding-system-that-fixes-bugs\" class=\"anchor\" id=\"practical-example-an-ai-coding-system-that-fixes-bugs\"\u003e\u003c/a\u003ePractical Example: An AI Coding System That Fixes Bugs\u003c/h2\u003e\n\u003cp\u003eLet’s assume an AI is fixing a bug where “only certain users encounter a 500 error after logging in.”\u003c/p\u003e\n\u003ch3\u003e\u003ca href=\"#prompt-engineering\" class=\"anchor\" id=\"prompt-engineering\"\u003e\u003c/a\u003ePrompt Engineering\u003c/h3\u003e\n\u003cul\u003e\n\u003cli\u003eVerify the conditions under which the error occurs.\u003c/li\u003e\n\u003cli\u003eDo not modify the public API.\u003c/li\u003e\n\u003cli\u003eResolve the issue with minimal changes.\u003c/li\u003e\n\u003cli\u003eReport test results and remaining risks after the fix.\u003c/li\u003e\n\u003c/ul\u003e\n\u003ch3\u003e\u003ca href=\"#context-engineering\" class=\"anchor\" id=\"context-engineering\"\u003e\u003c/a\u003eContext Engineering\u003c/h3\u003e\n\u003cul\u003e\n\u003cli\u003eIssue description and error logs\u003c/li\u003e\n\u003cli\u003eRelevant request trace IDs\u003c/li\u003e\n\u003cli\u003eFiles related to authentication and user models\u003c/li\u003e\n\u003cli\u003eRecent change history\u003c/li\u003e\n\u003cli\u003eArchitecture rules and coding standards\u003c/li\u003e\n\u003cli\u003eFailed tests and execution environment information\u003c/li\u003e\n\u003c/ul\u003e\n\u003ch3\u003e\u003ca href=\"#harness-engineering\" class=\"anchor\" id=\"harness-engineering\"\u003e\u003c/a\u003eHarness Engineering\u003c/h3\u003e\n\u003cul\u003e\n\u003cli\u003eTools for repository search, file reading/editing, and test execution\u003c/li\u003e\n\u003cli\u003eIsolated branches and sandboxes\u003c/li\u003e\n\u003cli\u003eFormatters, linters, unit and integration tests\u003c/li\u003e\n\u003cli\u003eNo-change zones and permission policies\u003c/li\u003e\n\u003cli\u003eLogs of all commands and file changes\u003c/li\u003e\n\u003cli\u003eRollbacks and checkpoints in case of failure\u003c/li\u003e\n\u003c/ul\u003e\n\u003ch3\u003e\u003ca href=\"#agent-based-engineering\" class=\"anchor\" id=\"agent-based-engineering\"\u003e\u003c/a\u003eAgent-Based Engineering\u003c/h3\u003e\n\u003cp\u003eAI selects the sequence of steps—reproduction, hypothesis formulation, exploration of relevant code, patching, testing, and result summarization—based on the situation. However, deployments or data changes require human approval.\u003c/p\u003e\n\u003ch3\u003e\u003ca href=\"#loop-engineering\" class=\"anchor\" id=\"loop-engineering\"\u003e\u003c/a\u003eLoop Engineering\u003c/h3\u003e\n\u003cp\u003eIf a test fails, instead of repeating the same command, the system classifies the failure type. If it’s a reproduction failure, it supplements context collection; if it’s a regression failure, it refines the patch; and if it’s an environment error, it restores dependencies and settings. The process ends when all required tests pass and justification for the change is documented.\u003c/p\u003e\n\u003ch2\u003e\u003ca href=\"#how-to-determine-what-kind-of-engineering-is-needed-based-on-problem-symptoms\" class=\"anchor\" id=\"how-to-determine-what-kind-of-engineering-is-needed-based-on-problem-symptoms\"\u003e\u003c/a\u003eHow to Determine What Kind of Engineering Is Needed Based on Problem Symptoms\u003c/h2\u003e\n\u003cdiv class=\"overflow-x-auto\"\u003e\u003ctable\u003e\n\u003cthead\u003e\n\u003ctr\u003e\n\u003cth\u003eSymptom\u003c/th\u003e\n\u003cth\u003eArea to Check First\u003c/th\u003e\n\u003c/tr\u003e\n\u003c/thead\u003e\n\u003ctbody\u003e\n\u003ctr\u003e\n\u003ctd\u003eOutput format or style is frequently inconsistent\u003c/td\u003e\n\u003ctd\u003ePrompt\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003eFacts or files required for the answer are missing\u003c/td\u003e\n\u003ctd\u003eContext\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003eIncorrect tool selection or execution of dangerous commands\u003c/td\u003e\n\u003ctd\u003eHarness and permission design\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003eMany variations that are difficult to handle with a fixed sequence\u003c/td\u003e\n\u003ctd\u003eAgent-based design\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003eInitial results are often incorrect, but automatic evaluation is possible\u003c/td\u003e\n\u003ctd\u003eLoops and evaluators\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003eThe cause of failure is unknown and difficult to reproduce\u003c/td\u003e\n\u003ctd\u003eObservability of the harness\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003eCosts increase with each iteration without any improvement in quality\u003c/td\u003e\n\u003ctd\u003eCause classification, verification signals, and termination conditions\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003eThe more data there is, the worse the answers become\u003c/td\u003e\n\u003ctd\u003eContext organization and search policy\u003c/td\u003e\n\u003c/tr\u003e\n\u003c/tbody\u003e\n\u003c/table\u003e\u003c/div\u003e\n\u003ch2\u003e\u003ca href=\"#recommended-implementation-order\" class=\"anchor\" id=\"recommended-implementation-order\"\u003e\u003c/a\u003eRecommended Implementation Order\u003c/h2\u003e\n\u003ch3\u003e\u003ca href=\"#step-1-first-establish-success-criteria-and-an-evaluation-set\" class=\"anchor\" id=\"step-1-first-establish-success-criteria-and-an-evaluation-set\"\u003e\u003c/a\u003eStep 1: First, establish success criteria and an evaluation set\u003c/h3\u003e\n\u003cp\u003eCollect representative tasks, challenging cases, and prohibited cases, and define how results will be evaluated. If no ground-truth data is available, at a minimum, establish a schema, required evidence, policy compliance, and human evaluation criteria.\u003c/p\u003e\n\u003ch3\u003e\u003ca href=\"#step-2-establish-a-single-call-baseline\" class=\"anchor\" id=\"step-2-establish-a-single-call-baseline\"\u003e\u003c/a\u003eStep 2: Establish a single-call baseline\u003c/h3\u003e\n\u003cp\u003eMeasure performance, cost, and latency using the simplest prompt and the minimum necessary context. Without a baseline, it is difficult to distinguish the effects of complexity when deploying an agent.\u003c/p\u003e\n\u003ch3\u003e\u003ca href=\"#step-3-instrument-context-provisioning\" class=\"anchor\" id=\"step-3-instrument-context-provisioning\"\u003e\u003c/a\u003eStep 3: Instrument context provisioning\u003c/h3\u003e\n\u003cp\u003eRecord which documents and tool results were included, how old they were, and whether they were actually used in the response. Distinguish between search failures and excessive context.\u003c/p\u003e\n\u003ch3\u003e\u003ca href=\"#step-4-create-a-minimal-harness\" class=\"anchor\" id=\"step-4-create-a-minimal-harness\"\u003e\u003c/a\u003eStep 4: Create a Minimal Harness\u003c/h3\u003e\n\u003cp\u003eReduce the number of tools and clarify their names and inputs. Prioritize sandboxes, least privilege, automated testing, logs, and checkpoints.\u003c/p\u003e\n\u003ch3\u003e\u003ca href=\"#step-5-grant-limited-autonomy\" class=\"anchor\" id=\"step-5-grant-limited-autonomy\"\u003e\u003c/a\u003eStep 5: Grant Limited Autonomy\u003c/h3\u003e\n\u003cp\u003eHave a single agent begin by performing read-only, low-risk tasks. Specify termination conditions and conditions for human handover, and require separate approval for write, delete, payment, and deployment permissions.\u003c/p\u003e\n\u003ch3\u003e\u003ca href=\"#step-6-close-the-validation-and-recovery-loop\" class=\"anchor\" id=\"step-6-close-the-validation-and-recovery-loop\"\u003e\u003c/a\u003eStep 6: Close the Validation and Recovery Loop\u003c/h3\u003e\n\u003cp\u003eLink failure classifications, remediation strategies, maximum number of iterations, cost limits, and regression tests. Expand the scope of tools and autonomy only after the success rate has stabilized.\u003c/p\u003e\n\u003ch2\u003e\u003ca href=\"#operational-metrics\" class=\"anchor\" id=\"operational-metrics\"\u003e\u003c/a\u003eOperational Metrics\u003c/h2\u003e\n\u003cp\u003eSince there are no universal target values, benchmarks must be set based on task risk and cost.\u003c/p\u003e\n\u003cdiv class=\"overflow-x-auto\"\u003e\u003ctable\u003e\n\u003cthead\u003e\n\u003ctr\u003e\n\u003cth\u003eMetric\u003c/th\u003e\n\u003cth\u003eMeaning\u003c/th\u003e\n\u003c/tr\u003e\n\u003c/thead\u003e\n\u003ctbody\u003e\n\u003ctr\u003e\n\u003ctd\u003eTask Completion Rate\u003c/td\u003e\n\u003ctd\u003eThe percentage that meets the final success criteria\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003eFirst-Pass Success Rate\u003c/td\u003e\n\u003ctd\u003eThe percentage of tasks that passed on the first attempt without iterative corrections\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003eRecovery Rate\u003c/td\u003e\n\u003ctd\u003eThe percentage of tasks that succeeded through the loop after the first failure\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003eAverage Number of Iterations\u003c/td\u003e\n\u003ctd\u003eThe number of cycles required to reach success or termination\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003eTool Selection Error Rate\u003c/td\u003e\n\u003ctd\u003eThe percentage of inappropriate or unnecessary tool invocations\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003eEvidence Completeness\u003c/td\u003e\n\u003ctd\u003eThe percentage of key claims supported by traceable sources\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003eHuman Intervention Rate\u003c/td\u003e\n\u003ctd\u003eThe percentage of cases requiring approval, modification, or re-instruction\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003eCost and Delay per Successful Unit\u003c/td\u003e\n\u003ctd\u003eThe resources required to complete a single successful task\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003eNumber of Safety Incidents\u003c/td\u003e\n\u003ctd\u003eThe number of authorization violations, incorrect writes, or irreversible actions\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003eRegression Failure Rate\u003c/td\u003e\n\u003ctd\u003ePercentage of new changes that break existing successful cases\u003c/td\u003e\n\u003c/tr\u003e\n\u003c/tbody\u003e\n\u003c/table\u003e\u003c/div\u003e\n\u003ch2\u003e\u003ca href=\"#common-design-mistakes\" class=\"anchor\" id=\"common-design-mistakes\"\u003e\u003c/a\u003eCommon Design Mistakes\u003c/h2\u003e\n\u003cdiv class=\"overflow-x-auto\"\u003e\u003ctable\u003e\n\u003cthead\u003e\n\u003ctr\u003e\n\u003cth\u003eArea\u003c/th\u003e\n\u003cth\u003eMistake\u003c/th\u003e\n\u003cth\u003eHow to Improve\u003c/th\u003e\n\u003c/tr\u003e\n\u003c/thead\u003e\n\u003ctbody\u003e\n\u003ctr\u003e\n\u003ctd\u003ePrompt\u003c/td\u003e\n\u003ctd\u003eCumulates all exceptions into a single sentence\u003c/td\u003e\n\u003ctd\u003eStructure the rules and separate representative examples from evaluation criteria\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003ePrompt\u003c/td\u003e\n\u003ctd\u003eInstructs to “write well” without success criteria\u003c/td\u003e\n\u003ctd\u003eSpecify format, required content, prohibited actions, and evaluation criteria\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003eContext\u003c/td\u003e\n\u003ctd\u003eIncludes all irrelevant documents\u003c/td\u003e\n\u003ctd\u003eUse runtime search and step-by-step context\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003eContext\u003c/td\u003e\n\u003ctd\u003eProvides both outdated and current policies\u003c/td\u003e\n\u003ctd\u003eManage versions, expiration dates, and source references\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003eHarness\u003c/td\u003e\n\u003ctd\u003eProvides many tools with overlapping functionality\u003c/td\u003e\n\u003ctd\u003eDesign a minimal set of tools with clear parameters\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003eHarness\u003c/td\u003e\n\u003ctd\u003eLacks write permissions and rollback capabilities\u003c/td\u003e\n\u003ctd\u003eImplement least privilege, sandboxing, and checkpoints\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003eAgent-based\u003c/td\u003e\n\u003ctd\u003eCreates multiple agents from the start\u003c/td\u003e\n\u003ctd\u003eVerify using a single agent and a deterministic workflow\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003eAgent-based\u003c/td\u003e\n\u003ctd\u003eAllows continuous execution without completion conditions\u003c/td\u003e\n\u003ctd\u003eEstablish explicit termination, budget, and handover conditions\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003eLoop\u003c/td\u003e\n\u003ctd\u003eRepeats the same request verbatim\u003c/td\u003e\n\u003ctd\u003eClassify failure causes and change the points of correction\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003eLoop\u003c/td\u003e\n\u003ctd\u003eSelf-evaluates all results using a single generative model\u003c/td\u003e\n\u003ctd\u003eCombines deterministic checks, reference comparisons, and human sample reviews\u003c/td\u003e\n\u003c/tr\u003e\n\u003c/tbody\u003e\n\u003c/table\u003e\u003c/div\u003e\n\u003ch2\u003e\u003ca href=\"#implementation-checklist\" class=\"anchor\" id=\"implementation-checklist\"\u003e\u003c/a\u003eImplementation Checklist\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003e Are success conditions verifiable not only through text but also, to the extent possible, through machine-readable checks?\u003c/li\u003e\n\u003cli\u003e Are the priorities of prompts, reference materials, and tool outputs clearly separated?\u003c/li\u003e\n\u003cli\u003e Can the source, version, expiration date, and owner of documents be tracked?\u003c/li\u003e\n\u003cli\u003e Are tool names and parameters clear and free of overlap?\u003c/li\u003e\n\u003cli\u003e Are read, write, delete, payment, and deployment permissions separated by risk level?\u003c/li\u003e\n\u003cli\u003e Are there sandboxes to isolate failures and rollback mechanisms in place?\u003c/li\u003e\n\u003cli\u003e Are all critical actions and tool calls logged in a reproducible format?\u003c/li\u003e\n\u003cli\u003e Are there external validators, such as tests, schemas, and policy checks?\u003c/li\u003e\n\u003cli\u003e Are the maximum number of iterations, cost, time, and conditions for human handover defined?\u003c/li\u003e\n\u003cli\u003e Is there regression testing to ensure new improvements do not break existing use cases?\u003c/li\u003e\n\u003c/ul\u003e\n\u003ch2\u003e\u003ca href=\"#conclusion\" class=\"anchor\" id=\"conclusion\"\u003e\u003c/a\u003eConclusion\u003c/h2\u003e\n\u003cp\u003eA good AI system is not the one with the longest prompts. It is a system that distinguishes where failures occurred—whether in \u003cstrong\u003einstructions\u003c/strong\u003e, \u003cstrong\u003einformation\u003c/strong\u003e, \u003cstrong\u003eenvironment\u003c/strong\u003e, \u003cstrong\u003edecision-making\u003c/strong\u003e, \u003cstrong\u003everification and recovery\u003c/strong\u003e, and applies the simplest solution at that specific layer. A stable approach is to first establish success criteria and a baseline for a single call, then augment context and the harness only as much as necessary, and finally expand autonomy and the iteration loop within verifiable bounds.\u003c/p\u003e\n","tags":["Prompt Engineering","Context Engineering","Harness Engineering","AI Agents","AI Evaluation"],"faqs":[{"question":"Do the five engineering methods have to be implemented in order?","answer":"These are not fixed maturity levels. However, once you establish success criteria and a single call baseline, organize the prompts and context, and add a harness, autonomy, and an iteration loop as needed, it becomes easy to measure the effects of complexity."},{"question":"Is context engineering replacing prompt engineering?","answer":"They are not interchangeable. A prompt defines the actions to be taken and the output agreement, while context provides the facts, states, and rationale necessary for those actions. A good system designs both together."},{"question":"What is the difference between context engineering and harness engineering?","answer":"Context engineering focuses on the information a model perceives at a given moment. Harness engineering encompasses the tools, permissions, execution environments, document structures, logs, and recovery mechanisms used to locate that information, perform actions, and inspect the results."},{"question":"How do agents differ from general workflow automation?","answer":"While general workflows follow a predefined sequence and branching logic, agents interpret their current state to dynamically select their next actions and tools. For tasks with stable rules, deterministic workflows may be more cost-effective and predictable."},{"question":"How is loop engineering different from a simple retry?","answer":"A simple retry merely regenerates the output under the same conditions. Loop engineering involves verifying a failure using an external validation signal, classifying the cause, modifying the necessary components—such as the prompt, context, tools, or implementation—and then applying termination conditions and regression testing."},{"question":"When should I use multiple agents?","answer":"This approach is considered when the tools and permissions vary significantly by role, and when a single agent’s context or set of tools becomes too large, leading to degraded performance and evaluation. Creating multiple agents solely for the purpose of dividing roles can increase costs, latency, error propagation, and the difficulty of debugging."},{"question":"Is it okay to let AI evaluate its own results?","answer":"While it can be used as a supplementary indicator, relying on it as the sole validation tool is risky. Whenever possible, apply tests, schemas, reference data, and policy rules first, and supplement model evaluation with explicit rubrics and human sample reviews."},{"question":"What should I include in the harness documentation?","answer":"Include recurring work procedures, repository and system structures, permitted and prohibited actions, tool usage instructions, examples of best and worst practices, test commands, troubleshooting procedures, approval policies, and completion criteria. The documentation should be concise, searchable, and version-controlled."},{"question":"What is the most important security principle to follow when incorporating external documents into a context?","answer":"External documents must be treated as untrusted data and kept separate from system guidelines. Tool privileges must be minimized to prevent the execution of commands contained in the documents, and critical actions such as writing, deleting, payment, and distribution must be subject to separate policy checks and human approval."},{"question":"Where should a small team start?","answer":"Gather a small set of representative evaluations and failure cases to establish a baseline for a single model invocation. It is then most efficient to identify which of the following is the primary cause of failure—instructions, information, the tool environment, planning, or verification—and improve the system one layer at a time."}],"sources":[{"url":"https://platform.claude.com/docs/ko/build-with-claude/prompt-engineering/overview","title":"Overview of Prompt Engineering - Claude Platform Docs","type":"source"},{"url":"https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents","title":"Effective Context Engineering for AI Agents","type":"source"},{"url":"https://openai.com/index/harness-engineering/","title":"Harness Engineering: Leveraging Codex in an Agent-First World","type":"source"},{"url":"https://www.anthropic.com/engineering/building-effective-agents","title":"Building Effective Agents","type":"source"},{"url":"https://openai.com/business/guides-and-resources/a-practical-guide-to-building-ai-agents/","title":"A Practical Guide to Building Agents","type":"source"},{"url":"https://www.anthropic.com/engineering/demystifying-evals-for-ai-agents","title":"Demystifying Eval Functions for AI Agents","type":"source"},{"url":"https://martinfowler.com/articles/harness-engineering.html","title":"Harness Engineering for Coding Agent Users","type":"source"}],"images":[{"id":192,"url":"https://injoys.com/rails/active_storage/blobs/redirect/eyJfcmFpbHMiOnsiZGF0YSI6MTg0NywicHVyIjoiYmxvYl9pZCJ9fQ==--9f1b84d1d297642915a0d27477d3800017987668/ChatGPT%20Image%202026%E1%84%82%E1%85%A7%E1%86%AB%207%E1%84%8B%E1%85%AF%E1%86%AF%2016%E1%84%8B%E1%85%B5%E1%86%AF%20%E1%84%8B%E1%85%A9%E1%84%92%E1%85%AE%2004_12_32.webp","is_representative":true,"generation_method":"upload","mime_type":"image/webp","original_filename":"ChatGPT Image 2026년 7월 16일 오후 04_12_32.png","translations":{"ko":{"alt":"중앙 AI 허브와 지시, 정보, 도구, 자율 실행, 검증 루프 모듈이 연결된 시스템 구조","caption":"다섯 가지 AI 엔지니어링 방식이 하나의 시스템에서 연결되고 반복 개선되는 구조를 보여준다.","description":null},"en":{"alt":"Central AI hub connected to instruction, context, tools, autonomous action, and validation loop modules","caption":"The illustration shows five AI engineering approaches working together in a connected improvement cycle.","description":null},"ja":{"alt":"中央のAIハブに指示、情報、ツール、自律実行、検証ループの各モジュールが接続された構成","caption":"5つのAIエンジニアリング手法が連携し、反復的に改善される仕組みを表している。","description":null},"es":{"alt":"Núcleo central de IA conectado con módulos de instrucciones, contexto, herramientas, acción autónoma y validación","caption":"La ilustración muestra cinco enfoques de ingeniería de IA integrados en un ciclo de mejora continua.","description":null},"id":{"alt":"Pusat AI terhubung ke modul instruksi, konteks, alat, tindakan otonom, dan siklus validasi","caption":"Ilustrasi ini menunjukkan lima pendekatan rekayasa AI yang bekerja bersama dalam siklus perbaikan.","description":null},"pt":{"alt":"Núcleo central de IA ligado a módulos de instruções, contexto, ferramentas, ação autônoma e validação","caption":"A ilustração mostra cinco abordagens de engenharia de IA integradas em um ciclo contínuo de melhoria.","description":null},"zh-hant":{"alt":"中央 AI 核心連接指令、情境、工具、自主執行與驗證迴圈模組的系統架構","caption":"圖中呈現五種 AI 工程方法如何協同運作並形成持續改進的循環。","description":null}}},{"id":193,"url":"https://injoys.com/rails/active_storage/blobs/redirect/eyJfcmFpbHMiOnsiZGF0YSI6MTg1NCwicHVyIjoiYmxvYl9pZCJ9fQ==--47acd549387f7a60f4c18de6ac673ca1b551dd36/ChatGPT%20Image%202026%E1%84%82%E1%85%A7%E1%86%AB%207%E1%84%8B%E1%85%AF%E1%86%AF%2016%E1%84%8B%E1%85%B5%E1%86%AF%20%E1%84%8B%E1%85%A9%E1%84%92%E1%85%AE%2004_36_26.webp","is_representative":false,"generation_method":"upload","mime_type":"image/webp","original_filename":"ChatGPT Image 2026년 7월 16일 오후 04_36_26.png","translations":{"ko":{"alt":"지시 설정부터 정보 선별, 안전 환경, 자율 실행, 검증 반복까지 이어지는 AI 구축 파이프라인","caption":"AI 시스템을 단계적으로 설계하고 검증 결과를 앞 단계에 반영하는 실무 흐름을 보여준다.","description":null},"en":{"alt":"AI build pipeline from instruction setup and context filtering to safe execution, autonomous action, and validation loops","caption":"The illustration shows a step-by-step AI workflow with feedback loops returning results to earlier stages.","description":null},"ja":{"alt":"指示設定、情報選別、安全な実行環境、自律動作、検証ループへ続くAI構築パイプライン","caption":"AIシステムを段階的に設計し、検証結果を前の工程へ反映する流れを示している。","description":null},"es":{"alt":"Flujo de creación de IA con instrucciones, filtrado de contexto, entorno seguro, acción autónoma y validación iterativa","caption":"La ilustración muestra un proceso gradual de diseño de IA con ciclos de retroalimentación hacia etapas anteriores.","description":null},"id":{"alt":"Alur pembangunan AI dari pengaturan instruksi dan penyaringan konteks hingga eksekusi aman, tindakan otonom, dan validasi","caption":"Ilustrasi ini menunjukkan tahapan perancangan sistem AI dengan umpan balik ke proses sebelumnya.","description":null},"pt":{"alt":"Fluxo de construção de IA com instruções, filtragem de contexto, ambiente seguro, ação autônoma e validação iterativa","caption":"A ilustração mostra um processo gradual de projeto de IA com ciclos de retorno às etapas anteriores.","description":null},"zh-hant":{"alt":"從指令設定、情境篩選與安全環境，到自主執行和反覆驗證的 AI 建置流程","caption":"圖中呈現 AI 系統的分階段設計流程，以及驗證結果回饋至前序階段的機制。","description":null}}}],"published_at":"2026-07-16T17:00:54+09:00","updated_at":"2026-07-16T17:00:54+09:00","license":"cc_by","translation_status":"reviewed","available_locales":["ko","en","ja","es"],"data_locales":["ko","en","ja","es","id","pt","zh-hant"],"url":"https://injoys.com/en/articles/prompt-context-harness-agentic-loop-engineering"}