{"content_id":"tx8xp2gpig","slug":"ai-agent-harness-loop-graph-engineering","locale":"en","schema_type":"TechArticle","category":"knowledge_base","category_name":"Knowledge Base","title":"Understanding AI Agent Harness, Loop, and Graph Engineering Step by Step","summary":"A harness defines the environment and controls in which an agent works, a loop defines repetition and termination rules, and a graph defines permitted states and transition paths. These three terms are best understood not as an officially standardized classification, but as practical perspectives for managing the autonomy and risks of AI agents.","sponsorship_disclosure":null,"author":{"name":"Injoys Editorial Team","url":"https://injoys.com/ko/about"},"key_points":["Harness engineering involves designing the context outside the model, tools, permissions, validation, logs, and approval procedures as a single execution environment.","Loop engineering defines the conditions, budgets, and termination criteria for an agent to repeat planning, execution, validation, and revision.","Graph engineering uses states and transition rules to explicitly restrict or adjust the paths an agent can choose.","For most organizations, improving the harness and evaluation framework of a single agent first is more efficient than building a complex multi-agent graph.","Approving only an AI-generated summary report is insufficient for high-risk code; tests, the scope of changes, security boundaries, and original artifacts must also be verified."],"content_markdown":"As AI agents have begun taking on long-running tasks, writing good prompts alone is no longer enough to produce reliable results. This is because you must also design what information the agent sees, which tools it uses, when it repeats actions, which paths it follows, and where it must obtain human approval.\n\nThree terms that frequently appear when explaining this problem are **harness engineering**, **loop engineering**, and **graph engineering**. These are not international standards or rigorously agreed-upon academic classifications. They overlap, and their meanings may vary by product and development team. Rather than memorizing them as annual buzzwords, it is therefore more useful to distinguish them by the control questions each one seeks to answer.\n\n## Comparing the Three Concepts at a Glance\n\n| Concept | Core question | Primary design targets | Typical failure-prevention mechanisms |\n|---|---|---|---|\n| Harness engineering | Within what environment and rules does the agent work? | Context, tools, permissions, sandbox, hooks, logs, approvals, evaluation | Least privilege, approval for risky commands, test execution, context selection |\n| Loop engineering | What is repeated, and when does it stop? | Planning-execution-validation cycles, event processing, retries, budgets, termination conditions | Maximum iteration count, time and token limits, progress assessment, escalation on failure |\n| Graph engineering | Which states and paths are allowed? | Nodes, states, transitions, branches, parallel processing, checkpoints | Prohibited transitions, state validation, approval nodes, recovery paths |\n\nIn short, **a harness defines the environment and boundaries**, **a loop defines the repetition rules**, and **a graph defines the structure of possible paths**. In a real system, a loop may exist inside a graph node, while the entire graph may run within a single harness.\n\n## How Have Agent Control Methods Evolved?\n\n### Early Agents: Predefined Workflows Supplemented Autonomy\n\nEarly generative AI agents often forgot their goals during long-running tasks, repeatedly made incorrect tool calls, or produced unsupported results. In response, developers divided large tasks into smaller steps and fixed the inputs and outputs for each step.\n\nIn this approach, a person writes the entire procedure as a chain, flowchart, or state machine, while the LLM handles limited tasks such as classification, extraction, summarization, and drafting. Frameworks such as LangGraph are used to represent branching, cycles, checkpoints, and human intervention while preserving state.\n\nHowever, graph-based orchestration is not an outdated approach that ended in a particular year. Explicit graphs remain suitable for work where auditability, reproducibility, regulatory compliance, or precise recovery procedures are important.\n\n### Improved Model Capabilities: From Fixed Paths to Dynamic Tool Use\n\nAs tool use and reasoning capabilities improved, a single agent became able to choose actions such as search, code editing, testing, and file reading based on the situation. ReAct-style approaches are a representative structure in which reasoning, action, and observation alternate.\n\nThis change reduced the burden of having people define every branch in advance. At the same time, managing the information an agent reads, the permissions it holds, execution costs, and error recovery methods became more important. This is where context engineering and harness engineering moved to the center of practical implementation.\n\n### Long-Running Tasks and Multi-Agent Systems: Recombining Loops and Graphs\n\nFor long-running tasks, iterative planning, execution, and validation are more important than a single model call. When multiple agents participate, their roles, output formats, permissions, and termination conditions must also be specified. At the same time, leaving autonomous loops completely unattended can cause runaway costs, infinite retries, reward hacking, and optimization toward the wrong objective.\n\nModern agent systems are therefore designed not to eliminate autonomy, but to **combine areas where autonomy is allowed with areas under deterministic control**. This is not simply a return to the fixed chains of the past. Instead, it surrounds flexible execution with states, transitions, and policies.\n\nThese changes represent shifts in design emphasis rather than a precise timeline. Graphs, loops, and harnesses have coexisted from the beginning and continue to be used together today.\n\n## What Harness Engineering Covers\n\nA harness is not the foundation model itself, but the **execution system surrounding the model that enables it to perform real work**. Even when the same model is used, the harness can make a significant difference in success rate, cost, security, and reproducibility.\n\n### Major Components of a Harness\n\n1. **Instruction system**: System instructions, repository rules, coding standards, priorities, and prohibited actions\n2. **Context delivery**: Search, file selection, summarization, memory, and injecting documents when needed\n3. **Tool interfaces**: File editing, terminals, browsers, databases, and external APIs\n4. **Permissions and isolation**: Read and write scope, access to secrets, network restrictions, and sandboxes\n5. **Validation mechanisms**: Tests, linters, type checking, schema validation, and fact-checking\n6. **Human approval**: Approval for difficult-to-reverse actions such as deployment, payment, deletion, and external transmission\n7. **Observability**: Call records, costs, latency, errors, change history, and decision rationale\n8. **Recovery policies**: Retries, restoration of previous states, task termination, and escalation to the responsible person\n\nClaude Code's project instruction files and hooks can be viewed as examples of harness components. However, no single product feature represents an entire harness.\n\n### How It Differs from Context Engineering\n\nContext engineering optimizes which information and instructions are included in the current model call. It includes retrieving only relevant documents through search, summarizing old conversations, saving task state in external files, and separating context by subtask.\n\nHarness engineering is broader. In addition to context, it covers tool permissions, execution environments, approvals, validation, logging, and cost limits. Context engineering is therefore a core part of a harness, but using the two terms as if they meant exactly the same thing is inaccurate.\n\n## The Core of Loop Engineering Is the Termination Condition\n\nA loop allows an agent to inspect a result after producing it and try again if the result is insufficient. What matters is not repetition itself, but the **definition of progress and the conditions for stopping**.\n\n### Common Types of Loops\n\n- **Validation loop**: Produces a draft, checks it against tests or evaluation criteria, and corrects failed items.\n- **Event-driven loop**: Begins work when an external event occurs, such as an email, notification, code change, or sensor reading.\n- **Exploration loop**: Investigates multiple hypotheses or sources and adjusts the scope of exploration until sufficient evidence is available.\n- **Improvement loop**: Selects the next strategy based on previous results and evaluation scores. Optimizing only a single score can cause reward hacking, so multiple evaluation criteria and human review are required.\n- **Recovery loop**: Classifies the cause of an error, retries within the permitted scope, and hands the task off to a person if it remains unresolved.\n\n### Contracts Required for Safe Loops\n\nA contract between agents is not a legal contract, but an execution specification that defines inputs, outputs, and responsibilities. It should include the following items.\n\n| Contract item | What to specify |\n|---|---|\n| Objective | The result to be completed and what is out of scope |\n| Input | Available data, freshness, and confidence level |\n| Output | JSON schema, document format, required evidence, and test results |\n| Permissions | Allowed tools, file scope, external transmission, and modification permissions |\n| Validation | Tests and evaluation criteria that must be passed |\n| Budget | Tokens, time, number of calls, and number of parallel tasks |\n| Termination | Conditions for success, lack of progress, budget exhaustion, and risk detection |\n| Handoff | Which person or agent takes over after failure |\n\nIf completion criteria are ambiguous, an agent may conclude that the task is progressing even while merely rewriting sentences or repeating the same search. Rather than setting only a maximum iteration count, it is better to consider result quality, the increase in new information, changes in errors, and cost together.\n\n## Graph Engineering Structures the Boundaries of Autonomy\n\nA graph represents work as nodes and connections. A node may be a model call, tool execution, human approval, or validation process, while a connection indicates the next action based on the current state.\n\n### Differences Between Chains and Graphs\n\n- **A chain** is suitable for a linear process that proceeds from A to B and from B to C.\n- **A graph** is suitable for tasks requiring conditional branches, repetition, parallel execution, failure recovery, and intermediate saves.\n- **A dynamic graph** allows the model to propose the next subtask or path during execution.\n- **A constrained graph** keeps the model within permitted nodes and transitions even when it makes choices.\n\nThe purpose of modern graph design is not to have people predetermine every action. It is to embed **invariants that must be preserved** into the structure, such as requiring an approval node before data deletion or preventing a transition to the deployment state while tests are failing.\n\n### Signs That a Graph Is Needed\n\nIf several of the following conditions apply, it is worth considering an explicit graph.\n\n- There is a clearly defined recovery point to return to after failure.\n- A stage absolutely requires human approval.\n- Multiple tasks must run in parallel before their results are combined.\n- Available tools or permissions vary by state.\n- The complete execution path must be audited or reproduced.\n- A single-agent loop repeatedly encounters the same failure.\n\nTurning simple document summarization or a one-time data transformation into a graph may only increase complexity.\n\n## Practical Implementation Order: Start with a Harness and Expand as Needed\n\nThe following sequence is practical for most teams.\n\n1. **Define a single task and its success criteria.** First collect inputs, expected outputs, and failure cases.\n2. **Build a minimal harness.** Provide only the necessary context and tools, and set permissions, tests, logs, and cost limits.\n3. **Build an evaluation set.** Include not only normal cases but also ambiguous requests, incorrect documents, tool errors, and attempts to exceed permissions.\n4. **Turn points requiring repetition into loops.** Allow retries only where validation and correction actually improve quality.\n5. **Promote the workflow to a graph when branching and recovery become complex.** Specify states and transitions, and place approval nodes before risky actions.\n6. **Use multiple agents only when dividing the work is beneficial.** If parallel exploration or distinct specialized roles are unnecessary, a single agent may be simpler and less expensive.\n\n## Differences in Application Between Coding and Research\n\n| Item | Coding tasks | Research tasks |\n|---|---|---|\n| Verifiability | Automated validation through tests, builds, type checking, and similar methods is relatively easy | Source quality, omissions, and conflicting evidence must be assessed comprehensively |\n| Value of dynamic exploration | May be limited when the scope of changes is clear | High when comparing different search paths and hypotheses |\n| Major risks | Incorrect changes, security vulnerabilities, code tailored only to tests | Unsupported claims, duplicate sources, confirmation bias |\n| Suitable controls | Repository scope restrictions, tests, diff review, deployment approval | Source records, independent searches, searches for opposing evidence, citation verification |\n\nIt cannot be stated categorically that dynamic workflows are always inefficient for coding and always beneficial for research. A large-scale, testable migration may be well suited to an autonomous agent, while a fixed research procedure may be more efficient for a straightforward factual lookup. The key variables are not the field, but **the clarity of the objective, the feasibility of automated validation, the search space, and the cost of errors**.\n\n## Code Review Is Not Disappearing; the Unit of Review Is Changing\n\nWhen agents write code, developers spend less time entering every line themselves and take on more responsibility for overseeing requirements, design, test results, the scope of changes, and risks. Pull Request summaries and agent reports can accelerate reviews.\n\nHowever, approving changes after reading only a summary is not a safe default. Changes omitted by the agent or logic it misunderstood may also be absent from the summary. In the following situations, the original diff and related code must be reviewed directly.\n\n- Changes to authentication, payments, personal data, encryption, or access control\n- Database schema changes or irreversible migrations\n- Code sensitive to performance and concurrency\n- Large-scale refactoring outside test coverage\n- Changes to external dependencies, deployment settings, or secret handling\n- Cases where the agent's explanation does not match the actual diff\n\nHuman-in-the-loop does not mean having a person formally click a button. It also includes providing the evidence of changes, test results, possible failures, and rollback procedures needed for a person to make an informed judgment.\n\n## Common Pitfalls\n\n### Multi-Agent Systems Without a Purpose\n\nAdding agents creates costs for role coordination, duplicate calls, context transfer, and merging results. Unless parallel exploration from different perspectives is required or there is a reason to separate contexts, a single agent is better.\n\n### Unlimited Dynamic Workflows\n\nAllowing an agent to keep creating subtasks can rapidly increase token and tool-call costs. Costs are determined approximately by the sum of input and output token costs at each stage, tool costs, the number of parallel agents, and the number of iterations. The number of calls, number of concurrent executions, total budget, and maximum execution time must be limited separately.\n\n### Optimizing Only One Evaluation Metric\n\nIf test pass rate is the sole objective, incorrect optimization may occur, such as weakening tests or hiding exception handling. Quality, security, change size, cost, latency, and human evaluation should be used together.\n\n### Confusing Document Injection with Fine-Tuning\n\nDocument retrieval or project instructions may consistently change results, but they do not change the model weights. In a broad sense, this can be described as a learning effect of the system, but strictly speaking, it is adaptation using external memory and context. Documents or search indexes must be retained for the changes to persist in subsequent executions.\n\n## Evaluation, Security, and Economics That Are Easy to Miss in Operations\n\nAgent design does not end with an architecture diagram. In actual operations, **a system that measures what actually occurred is more important than what was permitted**.\n\n### Minimum Operational Metrics\n\n- Task success rate and human correction rate\n- Model and tool cost per task and total execution time\n- Number of iterations and percentage of calls consumed without progress\n- Number of approval requests, denials, and attempts to exceed permissions\n- Incorrect tool calls and recovery success rate\n- Percentage of results submitted without sources or tests\n- Degree to which results vary for the same input\n\n### Security Invariants\n\n- Instructions in external documents do not take priority over system policies.\n- Secrets are not unnecessarily exposed in model inputs or logs.\n- Read permissions are separated from write, delete, and deployment permissions.\n- External transmission and irreversible actions require separate approval or policy checks.\n- Agents cannot arbitrarily modify their own evaluation criteria, tests, or audit logs.\n\nThese invariants are safer when enforced through sandboxes, access control, graph transitions, and independent validators rather than through a single sentence in a prompt. Generative AI risk management must cover not only model accuracy but also the operating environment, human oversight, and incident response.\n\n## Which Concept Should You Learn First?\n\nIn current practice, harness engineering should be learned first. Equipping a single agent with accurate context, least privilege, automated validation, logs, approvals, and cost limits can reduce many failures.\n\nNext, add loops with termination conditions to tasks where repetition improves quality. When branching, parallel processing, recovery, and approval procedures become complex, express them explicitly as a graph. Before adopting complex terminology, prioritize making the agent's objectives, permissions, evidence, costs, and stopping conditions measurable.","content_html":"\u003cp\u003eAs AI agents have begun taking on long-running tasks, writing good prompts alone is no longer enough to produce reliable results. This is because you must also design what information the agent sees, which tools it uses, when it repeats actions, which paths it follows, and where it must obtain human approval.\u003c/p\u003e\n\u003cp\u003eThree terms that frequently appear when explaining this problem are \u003cstrong\u003eharness engineering\u003c/strong\u003e, \u003cstrong\u003eloop engineering\u003c/strong\u003e, and \u003cstrong\u003egraph engineering\u003c/strong\u003e. These are not international standards or rigorously agreed-upon academic classifications. They overlap, and their meanings may vary by product and development team. Rather than memorizing them as annual buzzwords, it is therefore more useful to distinguish them by the control questions each one seeks to answer.\u003c/p\u003e\n\u003ch2\u003e\n\u003ca href=\"#comparing-the-three-concepts-at-a-glance\" class=\"anchor\" id=\"comparing-the-three-concepts-at-a-glance\"\u003e\u003c/a\u003eComparing the Three Concepts at a Glance\u003c/h2\u003e\n\u003cdiv class=\"overflow-x-auto\"\u003e\u003ctable\u003e\n\u003cthead\u003e\n\u003ctr\u003e\n\u003cth\u003eConcept\u003c/th\u003e\n\u003cth\u003eCore question\u003c/th\u003e\n\u003cth\u003ePrimary design targets\u003c/th\u003e\n\u003cth\u003eTypical failure-prevention mechanisms\u003c/th\u003e\n\u003c/tr\u003e\n\u003c/thead\u003e\n\u003ctbody\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Concept\"\u003eHarness engineering\u003c/td\u003e\n\u003ctd data-label=\"Core question\"\u003eWithin what environment and rules does the agent work?\u003c/td\u003e\n\u003ctd data-label=\"Primary design targets\"\u003eContext, tools, permissions, sandbox, hooks, logs, approvals, evaluation\u003c/td\u003e\n\u003ctd data-label=\"Typical failure-prevention mechanisms\"\u003eLeast privilege, approval for risky commands, test execution, context selection\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Concept\"\u003eLoop engineering\u003c/td\u003e\n\u003ctd data-label=\"Core question\"\u003eWhat is repeated, and when does it stop?\u003c/td\u003e\n\u003ctd data-label=\"Primary design targets\"\u003ePlanning-execution-validation cycles, event processing, retries, budgets, termination conditions\u003c/td\u003e\n\u003ctd data-label=\"Typical failure-prevention mechanisms\"\u003eMaximum iteration count, time and token limits, progress assessment, escalation on failure\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Concept\"\u003eGraph engineering\u003c/td\u003e\n\u003ctd data-label=\"Core question\"\u003eWhich states and paths are allowed?\u003c/td\u003e\n\u003ctd data-label=\"Primary design targets\"\u003eNodes, states, transitions, branches, parallel processing, checkpoints\u003c/td\u003e\n\u003ctd data-label=\"Typical failure-prevention mechanisms\"\u003eProhibited transitions, state validation, approval nodes, recovery paths\u003c/td\u003e\n\u003c/tr\u003e\n\u003c/tbody\u003e\n\u003c/table\u003e\u003c/div\u003e\n\u003cp\u003eIn short, \u003cstrong\u003ea harness defines the environment and boundaries\u003c/strong\u003e, \u003cstrong\u003ea loop defines the repetition rules\u003c/strong\u003e, and \u003cstrong\u003ea graph defines the structure of possible paths\u003c/strong\u003e. In a real system, a loop may exist inside a graph node, while the entire graph may run within a single harness.\u003c/p\u003e\n\u003ch2\u003e\n\u003ca href=\"#how-have-agent-control-methods-evolved\" class=\"anchor\" id=\"how-have-agent-control-methods-evolved\"\u003e\u003c/a\u003eHow Have Agent Control Methods Evolved?\u003c/h2\u003e\n\u003ch3\u003e\n\u003ca href=\"#early-agents-predefined-workflows-supplemented-autonomy\" class=\"anchor\" id=\"early-agents-predefined-workflows-supplemented-autonomy\"\u003e\u003c/a\u003eEarly Agents: Predefined Workflows Supplemented Autonomy\u003c/h3\u003e\n\u003cp\u003eEarly generative AI agents often forgot their goals during long-running tasks, repeatedly made incorrect tool calls, or produced unsupported results. In response, developers divided large tasks into smaller steps and fixed the inputs and outputs for each step.\u003c/p\u003e\n\u003cp\u003eIn this approach, a person writes the entire procedure as a chain, flowchart, or state machine, while the LLM handles limited tasks such as classification, extraction, summarization, and drafting. Frameworks such as LangGraph are used to represent branching, cycles, checkpoints, and human intervention while preserving state.\u003c/p\u003e\n\u003cp\u003eHowever, graph-based orchestration is not an outdated approach that ended in a particular year. Explicit graphs remain suitable for work where auditability, reproducibility, regulatory compliance, or precise recovery procedures are important.\u003c/p\u003e\n\u003ch3\u003e\n\u003ca href=\"#improved-model-capabilities-from-fixed-paths-to-dynamic-tool-use\" class=\"anchor\" id=\"improved-model-capabilities-from-fixed-paths-to-dynamic-tool-use\"\u003e\u003c/a\u003eImproved Model Capabilities: From Fixed Paths to Dynamic Tool Use\u003c/h3\u003e\n\u003cp\u003eAs tool use and reasoning capabilities improved, a single agent became able to choose actions such as search, code editing, testing, and file reading based on the situation. ReAct-style approaches are a representative structure in which reasoning, action, and observation alternate.\u003c/p\u003e\n\u003cp\u003eThis change reduced the burden of having people define every branch in advance. At the same time, managing the information an agent reads, the permissions it holds, execution costs, and error recovery methods became more important. This is where context engineering and harness engineering moved to the center of practical implementation.\u003c/p\u003e\n\u003ch3\u003e\n\u003ca href=\"#long-running-tasks-and-multi-agent-systems-recombining-loops-and-graphs\" class=\"anchor\" id=\"long-running-tasks-and-multi-agent-systems-recombining-loops-and-graphs\"\u003e\u003c/a\u003eLong-Running Tasks and Multi-Agent Systems: Recombining Loops and Graphs\u003c/h3\u003e\n\u003cp\u003eFor long-running tasks, iterative planning, execution, and validation are more important than a single model call. When multiple agents participate, their roles, output formats, permissions, and termination conditions must also be specified. At the same time, leaving autonomous loops completely unattended can cause runaway costs, infinite retries, reward hacking, and optimization toward the wrong objective.\u003c/p\u003e\n\u003cp\u003eModern agent systems are therefore designed not to eliminate autonomy, but to \u003cstrong\u003ecombine areas where autonomy is allowed with areas under deterministic control\u003c/strong\u003e. This is not simply a return to the fixed chains of the past. Instead, it surrounds flexible execution with states, transitions, and policies.\u003c/p\u003e\n\u003cp\u003eThese changes represent shifts in design emphasis rather than a precise timeline. Graphs, loops, and harnesses have coexisted from the beginning and continue to be used together today.\u003c/p\u003e\n\u003ch2\u003e\n\u003ca href=\"#what-harness-engineering-covers\" class=\"anchor\" id=\"what-harness-engineering-covers\"\u003e\u003c/a\u003eWhat Harness Engineering Covers\u003c/h2\u003e\n\u003cp\u003eA harness is not the foundation model itself, but the \u003cstrong\u003eexecution system surrounding the model that enables it to perform real work\u003c/strong\u003e. Even when the same model is used, the harness can make a significant difference in success rate, cost, security, and reproducibility.\u003c/p\u003e\n\u003ch3\u003e\n\u003ca href=\"#major-components-of-a-harness\" class=\"anchor\" id=\"major-components-of-a-harness\"\u003e\u003c/a\u003eMajor Components of a Harness\u003c/h3\u003e\n\u003col\u003e\n\u003cli\u003e\n\u003cstrong\u003eInstruction system\u003c/strong\u003e: System instructions, repository rules, coding standards, priorities, and prohibited actions\u003c/li\u003e\n\u003cli\u003e\n\u003cstrong\u003eContext delivery\u003c/strong\u003e: Search, file selection, summarization, memory, and injecting documents when needed\u003c/li\u003e\n\u003cli\u003e\n\u003cstrong\u003eTool interfaces\u003c/strong\u003e: File editing, terminals, browsers, databases, and external APIs\u003c/li\u003e\n\u003cli\u003e\n\u003cstrong\u003ePermissions and isolation\u003c/strong\u003e: Read and write scope, access to secrets, network restrictions, and sandboxes\u003c/li\u003e\n\u003cli\u003e\n\u003cstrong\u003eValidation mechanisms\u003c/strong\u003e: Tests, linters, type checking, schema validation, and fact-checking\u003c/li\u003e\n\u003cli\u003e\n\u003cstrong\u003eHuman approval\u003c/strong\u003e: Approval for difficult-to-reverse actions such as deployment, payment, deletion, and external transmission\u003c/li\u003e\n\u003cli\u003e\n\u003cstrong\u003eObservability\u003c/strong\u003e: Call records, costs, latency, errors, change history, and decision rationale\u003c/li\u003e\n\u003cli\u003e\n\u003cstrong\u003eRecovery policies\u003c/strong\u003e: Retries, restoration of previous states, task termination, and escalation to the responsible person\u003c/li\u003e\n\u003c/ol\u003e\n\u003cp\u003eClaude Code's project instruction files and hooks can be viewed as examples of harness components. However, no single product feature represents an entire harness.\u003c/p\u003e\n\u003ch3\u003e\n\u003ca href=\"#how-it-differs-from-context-engineering\" class=\"anchor\" id=\"how-it-differs-from-context-engineering\"\u003e\u003c/a\u003eHow It Differs from Context Engineering\u003c/h3\u003e\n\u003cp\u003eContext engineering optimizes which information and instructions are included in the current model call. It includes retrieving only relevant documents through search, summarizing old conversations, saving task state in external files, and separating context by subtask.\u003c/p\u003e\n\u003cp\u003eHarness engineering is broader. In addition to context, it covers tool permissions, execution environments, approvals, validation, logging, and cost limits. Context engineering is therefore a core part of a harness, but using the two terms as if they meant exactly the same thing is inaccurate.\u003c/p\u003e\n\u003ch2\u003e\n\u003ca href=\"#the-core-of-loop-engineering-is-the-termination-condition\" class=\"anchor\" id=\"the-core-of-loop-engineering-is-the-termination-condition\"\u003e\u003c/a\u003eThe Core of Loop Engineering Is the Termination Condition\u003c/h2\u003e\n\u003cp\u003eA loop allows an agent to inspect a result after producing it and try again if the result is insufficient. What matters is not repetition itself, but the \u003cstrong\u003edefinition of progress and the conditions for stopping\u003c/strong\u003e.\u003c/p\u003e\n\u003ch3\u003e\n\u003ca href=\"#common-types-of-loops\" class=\"anchor\" id=\"common-types-of-loops\"\u003e\u003c/a\u003eCommon Types of Loops\u003c/h3\u003e\n\u003cul\u003e\n\u003cli\u003e\n\u003cstrong\u003eValidation loop\u003c/strong\u003e: Produces a draft, checks it against tests or evaluation criteria, and corrects failed items.\u003c/li\u003e\n\u003cli\u003e\n\u003cstrong\u003eEvent-driven loop\u003c/strong\u003e: Begins work when an external event occurs, such as an email, notification, code change, or sensor reading.\u003c/li\u003e\n\u003cli\u003e\n\u003cstrong\u003eExploration loop\u003c/strong\u003e: Investigates multiple hypotheses or sources and adjusts the scope of exploration until sufficient evidence is available.\u003c/li\u003e\n\u003cli\u003e\n\u003cstrong\u003eImprovement loop\u003c/strong\u003e: Selects the next strategy based on previous results and evaluation scores. Optimizing only a single score can cause reward hacking, so multiple evaluation criteria and human review are required.\u003c/li\u003e\n\u003cli\u003e\n\u003cstrong\u003eRecovery loop\u003c/strong\u003e: Classifies the cause of an error, retries within the permitted scope, and hands the task off to a person if it remains unresolved.\u003c/li\u003e\n\u003c/ul\u003e\n\u003ch3\u003e\n\u003ca href=\"#contracts-required-for-safe-loops\" class=\"anchor\" id=\"contracts-required-for-safe-loops\"\u003e\u003c/a\u003eContracts Required for Safe Loops\u003c/h3\u003e\n\u003cp\u003eA contract between agents is not a legal contract, but an execution specification that defines inputs, outputs, and responsibilities. It should include the following items.\u003c/p\u003e\n\u003cdiv class=\"overflow-x-auto\"\u003e\u003ctable\u003e\n\u003cthead\u003e\n\u003ctr\u003e\n\u003cth\u003eContract item\u003c/th\u003e\n\u003cth\u003eWhat to specify\u003c/th\u003e\n\u003c/tr\u003e\n\u003c/thead\u003e\n\u003ctbody\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Contract item\"\u003eObjective\u003c/td\u003e\n\u003ctd data-label=\"What to specify\"\u003eThe result to be completed and what is out of scope\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Contract item\"\u003eInput\u003c/td\u003e\n\u003ctd data-label=\"What to specify\"\u003eAvailable data, freshness, and confidence level\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Contract item\"\u003eOutput\u003c/td\u003e\n\u003ctd data-label=\"What to specify\"\u003eJSON schema, document format, required evidence, and test results\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Contract item\"\u003ePermissions\u003c/td\u003e\n\u003ctd data-label=\"What to specify\"\u003eAllowed tools, file scope, external transmission, and modification permissions\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Contract item\"\u003eValidation\u003c/td\u003e\n\u003ctd data-label=\"What to specify\"\u003eTests and evaluation criteria that must be passed\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Contract item\"\u003eBudget\u003c/td\u003e\n\u003ctd data-label=\"What to specify\"\u003eTokens, time, number of calls, and number of parallel tasks\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Contract item\"\u003eTermination\u003c/td\u003e\n\u003ctd data-label=\"What to specify\"\u003eConditions for success, lack of progress, budget exhaustion, and risk detection\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Contract item\"\u003eHandoff\u003c/td\u003e\n\u003ctd data-label=\"What to specify\"\u003eWhich person or agent takes over after failure\u003c/td\u003e\n\u003c/tr\u003e\n\u003c/tbody\u003e\n\u003c/table\u003e\u003c/div\u003e\n\u003cp\u003eIf completion criteria are ambiguous, an agent may conclude that the task is progressing even while merely rewriting sentences or repeating the same search. Rather than setting only a maximum iteration count, it is better to consider result quality, the increase in new information, changes in errors, and cost together.\u003c/p\u003e\n\u003ch2\u003e\n\u003ca href=\"#graph-engineering-structures-the-boundaries-of-autonomy\" class=\"anchor\" id=\"graph-engineering-structures-the-boundaries-of-autonomy\"\u003e\u003c/a\u003eGraph Engineering Structures the Boundaries of Autonomy\u003c/h2\u003e\n\u003cp\u003eA graph represents work as nodes and connections. A node may be a model call, tool execution, human approval, or validation process, while a connection indicates the next action based on the current state.\u003c/p\u003e\n\u003ch3\u003e\n\u003ca href=\"#differences-between-chains-and-graphs\" class=\"anchor\" id=\"differences-between-chains-and-graphs\"\u003e\u003c/a\u003eDifferences Between Chains and Graphs\u003c/h3\u003e\n\u003cul\u003e\n\u003cli\u003e\n\u003cstrong\u003eA chain\u003c/strong\u003e is suitable for a linear process that proceeds from A to B and from B to C.\u003c/li\u003e\n\u003cli\u003e\n\u003cstrong\u003eA graph\u003c/strong\u003e is suitable for tasks requiring conditional branches, repetition, parallel execution, failure recovery, and intermediate saves.\u003c/li\u003e\n\u003cli\u003e\n\u003cstrong\u003eA dynamic graph\u003c/strong\u003e allows the model to propose the next subtask or path during execution.\u003c/li\u003e\n\u003cli\u003e\n\u003cstrong\u003eA constrained graph\u003c/strong\u003e keeps the model within permitted nodes and transitions even when it makes choices.\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003eThe purpose of modern graph design is not to have people predetermine every action. It is to embed \u003cstrong\u003einvariants that must be preserved\u003c/strong\u003e into the structure, such as requiring an approval node before data deletion or preventing a transition to the deployment state while tests are failing.\u003c/p\u003e\n\u003ch3\u003e\n\u003ca href=\"#signs-that-a-graph-is-needed\" class=\"anchor\" id=\"signs-that-a-graph-is-needed\"\u003e\u003c/a\u003eSigns That a Graph Is Needed\u003c/h3\u003e\n\u003cp\u003eIf several of the following conditions apply, it is worth considering an explicit graph.\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003eThere is a clearly defined recovery point to return to after failure.\u003c/li\u003e\n\u003cli\u003eA stage absolutely requires human approval.\u003c/li\u003e\n\u003cli\u003eMultiple tasks must run in parallel before their results are combined.\u003c/li\u003e\n\u003cli\u003eAvailable tools or permissions vary by state.\u003c/li\u003e\n\u003cli\u003eThe complete execution path must be audited or reproduced.\u003c/li\u003e\n\u003cli\u003eA single-agent loop repeatedly encounters the same failure.\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003eTurning simple document summarization or a one-time data transformation into a graph may only increase complexity.\u003c/p\u003e\n\u003ch2\u003e\n\u003ca href=\"#practical-implementation-order-start-with-a-harness-and-expand-as-needed\" class=\"anchor\" id=\"practical-implementation-order-start-with-a-harness-and-expand-as-needed\"\u003e\u003c/a\u003ePractical Implementation Order: Start with a Harness and Expand as Needed\u003c/h2\u003e\n\u003cp\u003eThe following sequence is practical for most teams.\u003c/p\u003e\n\u003col\u003e\n\u003cli\u003e\n\u003cstrong\u003eDefine a single task and its success criteria.\u003c/strong\u003e First collect inputs, expected outputs, and failure cases.\u003c/li\u003e\n\u003cli\u003e\n\u003cstrong\u003eBuild a minimal harness.\u003c/strong\u003e Provide only the necessary context and tools, and set permissions, tests, logs, and cost limits.\u003c/li\u003e\n\u003cli\u003e\n\u003cstrong\u003eBuild an evaluation set.\u003c/strong\u003e Include not only normal cases but also ambiguous requests, incorrect documents, tool errors, and attempts to exceed permissions.\u003c/li\u003e\n\u003cli\u003e\n\u003cstrong\u003eTurn points requiring repetition into loops.\u003c/strong\u003e Allow retries only where validation and correction actually improve quality.\u003c/li\u003e\n\u003cli\u003e\n\u003cstrong\u003ePromote the workflow to a graph when branching and recovery become complex.\u003c/strong\u003e Specify states and transitions, and place approval nodes before risky actions.\u003c/li\u003e\n\u003cli\u003e\n\u003cstrong\u003eUse multiple agents only when dividing the work is beneficial.\u003c/strong\u003e If parallel exploration or distinct specialized roles are unnecessary, a single agent may be simpler and less expensive.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2\u003e\n\u003ca href=\"#differences-in-application-between-coding-and-research\" class=\"anchor\" id=\"differences-in-application-between-coding-and-research\"\u003e\u003c/a\u003eDifferences in Application Between Coding and Research\u003c/h2\u003e\n\u003cdiv class=\"overflow-x-auto\"\u003e\u003ctable\u003e\n\u003cthead\u003e\n\u003ctr\u003e\n\u003cth\u003eItem\u003c/th\u003e\n\u003cth\u003eCoding tasks\u003c/th\u003e\n\u003cth\u003eResearch tasks\u003c/th\u003e\n\u003c/tr\u003e\n\u003c/thead\u003e\n\u003ctbody\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Item\"\u003eVerifiability\u003c/td\u003e\n\u003ctd data-label=\"Coding tasks\"\u003eAutomated validation through tests, builds, type checking, and similar methods is relatively easy\u003c/td\u003e\n\u003ctd data-label=\"Research tasks\"\u003eSource quality, omissions, and conflicting evidence must be assessed comprehensively\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Item\"\u003eValue of dynamic exploration\u003c/td\u003e\n\u003ctd data-label=\"Coding tasks\"\u003eMay be limited when the scope of changes is clear\u003c/td\u003e\n\u003ctd data-label=\"Research tasks\"\u003eHigh when comparing different search paths and hypotheses\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Item\"\u003eMajor risks\u003c/td\u003e\n\u003ctd data-label=\"Coding tasks\"\u003eIncorrect changes, security vulnerabilities, code tailored only to tests\u003c/td\u003e\n\u003ctd data-label=\"Research tasks\"\u003eUnsupported claims, duplicate sources, confirmation bias\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Item\"\u003eSuitable controls\u003c/td\u003e\n\u003ctd data-label=\"Coding tasks\"\u003eRepository scope restrictions, tests, diff review, deployment approval\u003c/td\u003e\n\u003ctd data-label=\"Research tasks\"\u003eSource records, independent searches, searches for opposing evidence, citation verification\u003c/td\u003e\n\u003c/tr\u003e\n\u003c/tbody\u003e\n\u003c/table\u003e\u003c/div\u003e\n\u003cp\u003eIt cannot be stated categorically that dynamic workflows are always inefficient for coding and always beneficial for research. A large-scale, testable migration may be well suited to an autonomous agent, while a fixed research procedure may be more efficient for a straightforward factual lookup. The key variables are not the field, but \u003cstrong\u003ethe clarity of the objective, the feasibility of automated validation, the search space, and the cost of errors\u003c/strong\u003e.\u003c/p\u003e\n\u003ch2\u003e\n\u003ca href=\"#code-review-is-not-disappearing-the-unit-of-review-is-changing\" class=\"anchor\" id=\"code-review-is-not-disappearing-the-unit-of-review-is-changing\"\u003e\u003c/a\u003eCode Review Is Not Disappearing; the Unit of Review Is Changing\u003c/h2\u003e\n\u003cp\u003eWhen agents write code, developers spend less time entering every line themselves and take on more responsibility for overseeing requirements, design, test results, the scope of changes, and risks. Pull Request summaries and agent reports can accelerate reviews.\u003c/p\u003e\n\u003cp\u003eHowever, approving changes after reading only a summary is not a safe default. Changes omitted by the agent or logic it misunderstood may also be absent from the summary. In the following situations, the original diff and related code must be reviewed directly.\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003eChanges to authentication, payments, personal data, encryption, or access control\u003c/li\u003e\n\u003cli\u003eDatabase schema changes or irreversible migrations\u003c/li\u003e\n\u003cli\u003eCode sensitive to performance and concurrency\u003c/li\u003e\n\u003cli\u003eLarge-scale refactoring outside test coverage\u003c/li\u003e\n\u003cli\u003eChanges to external dependencies, deployment settings, or secret handling\u003c/li\u003e\n\u003cli\u003eCases where the agent's explanation does not match the actual diff\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003eHuman-in-the-loop does not mean having a person formally click a button. It also includes providing the evidence of changes, test results, possible failures, and rollback procedures needed for a person to make an informed judgment.\u003c/p\u003e\n\u003ch2\u003e\n\u003ca href=\"#common-pitfalls\" class=\"anchor\" id=\"common-pitfalls\"\u003e\u003c/a\u003eCommon Pitfalls\u003c/h2\u003e\n\u003ch3\u003e\n\u003ca href=\"#multi-agent-systems-without-a-purpose\" class=\"anchor\" id=\"multi-agent-systems-without-a-purpose\"\u003e\u003c/a\u003eMulti-Agent Systems Without a Purpose\u003c/h3\u003e\n\u003cp\u003eAdding agents creates costs for role coordination, duplicate calls, context transfer, and merging results. Unless parallel exploration from different perspectives is required or there is a reason to separate contexts, a single agent is better.\u003c/p\u003e\n\u003ch3\u003e\n\u003ca href=\"#unlimited-dynamic-workflows\" class=\"anchor\" id=\"unlimited-dynamic-workflows\"\u003e\u003c/a\u003eUnlimited Dynamic Workflows\u003c/h3\u003e\n\u003cp\u003eAllowing an agent to keep creating subtasks can rapidly increase token and tool-call costs. Costs are determined approximately by the sum of input and output token costs at each stage, tool costs, the number of parallel agents, and the number of iterations. The number of calls, number of concurrent executions, total budget, and maximum execution time must be limited separately.\u003c/p\u003e\n\u003ch3\u003e\n\u003ca href=\"#optimizing-only-one-evaluation-metric\" class=\"anchor\" id=\"optimizing-only-one-evaluation-metric\"\u003e\u003c/a\u003eOptimizing Only One Evaluation Metric\u003c/h3\u003e\n\u003cp\u003eIf test pass rate is the sole objective, incorrect optimization may occur, such as weakening tests or hiding exception handling. Quality, security, change size, cost, latency, and human evaluation should be used together.\u003c/p\u003e\n\u003ch3\u003e\n\u003ca href=\"#confusing-document-injection-with-fine-tuning\" class=\"anchor\" id=\"confusing-document-injection-with-fine-tuning\"\u003e\u003c/a\u003eConfusing Document Injection with Fine-Tuning\u003c/h3\u003e\n\u003cp\u003eDocument retrieval or project instructions may consistently change results, but they do not change the model weights. In a broad sense, this can be described as a learning effect of the system, but strictly speaking, it is adaptation using external memory and context. Documents or search indexes must be retained for the changes to persist in subsequent executions.\u003c/p\u003e\n\u003ch2\u003e\n\u003ca href=\"#evaluation-security-and-economics-that-are-easy-to-miss-in-operations\" class=\"anchor\" id=\"evaluation-security-and-economics-that-are-easy-to-miss-in-operations\"\u003e\u003c/a\u003eEvaluation, Security, and Economics That Are Easy to Miss in Operations\u003c/h2\u003e\n\u003cp\u003eAgent design does not end with an architecture diagram. In actual operations, \u003cstrong\u003ea system that measures what actually occurred is more important than what was permitted\u003c/strong\u003e.\u003c/p\u003e\n\u003ch3\u003e\n\u003ca href=\"#minimum-operational-metrics\" class=\"anchor\" id=\"minimum-operational-metrics\"\u003e\u003c/a\u003eMinimum Operational Metrics\u003c/h3\u003e\n\u003cul\u003e\n\u003cli\u003eTask success rate and human correction rate\u003c/li\u003e\n\u003cli\u003eModel and tool cost per task and total execution time\u003c/li\u003e\n\u003cli\u003eNumber of iterations and percentage of calls consumed without progress\u003c/li\u003e\n\u003cli\u003eNumber of approval requests, denials, and attempts to exceed permissions\u003c/li\u003e\n\u003cli\u003eIncorrect tool calls and recovery success rate\u003c/li\u003e\n\u003cli\u003ePercentage of results submitted without sources or tests\u003c/li\u003e\n\u003cli\u003eDegree to which results vary for the same input\u003c/li\u003e\n\u003c/ul\u003e\n\u003ch3\u003e\n\u003ca href=\"#security-invariants\" class=\"anchor\" id=\"security-invariants\"\u003e\u003c/a\u003eSecurity Invariants\u003c/h3\u003e\n\u003cul\u003e\n\u003cli\u003eInstructions in external documents do not take priority over system policies.\u003c/li\u003e\n\u003cli\u003eSecrets are not unnecessarily exposed in model inputs or logs.\u003c/li\u003e\n\u003cli\u003eRead permissions are separated from write, delete, and deployment permissions.\u003c/li\u003e\n\u003cli\u003eExternal transmission and irreversible actions require separate approval or policy checks.\u003c/li\u003e\n\u003cli\u003eAgents cannot arbitrarily modify their own evaluation criteria, tests, or audit logs.\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003eThese invariants are safer when enforced through sandboxes, access control, graph transitions, and independent validators rather than through a single sentence in a prompt. Generative AI risk management must cover not only model accuracy but also the operating environment, human oversight, and incident response.\u003c/p\u003e\n\u003ch2\u003e\n\u003ca href=\"#which-concept-should-you-learn-first\" class=\"anchor\" id=\"which-concept-should-you-learn-first\"\u003e\u003c/a\u003eWhich Concept Should You Learn First?\u003c/h2\u003e\n\u003cp\u003eIn current practice, harness engineering should be learned first. Equipping a single agent with accurate context, least privilege, automated validation, logs, approvals, and cost limits can reduce many failures.\u003c/p\u003e\n\u003cp\u003eNext, add loops with termination conditions to tasks where repetition improves quality. When branching, parallel processing, recovery, and approval procedures become complex, express them explicitly as a graph. Before adopting complex terminology, prioritize making the agent's objectives, permissions, evidence, costs, and stopping conditions measurable.\u003c/p\u003e\n","tags":["Context Engineering","Harness Engineering","AI Agents","Claude Code","AI Development","Coding Agent"],"faqs":[{"question":"How is harness engineering different from prompt engineering?","answer":"Prompt engineering primarily deals with the instructions and wording provided to a model. Harness engineering is the design of a broader execution environment that includes not only prompts but also context retrieval, tools, permissions, sandboxes, tests, logs, human approval, and error recovery."},{"question":"Do context engineering and harness engineering mean the same thing?","answer":"No. Context engineering focuses on selecting, retrieving, summarizing, and arranging the information the model currently needs to know. In addition to context management, harness engineering also addresses permissions, tools, validation, cost limits, and operational policies."},{"question":"What is the most important difference between a loop and a graph?","answer":"A loop defines what is repeated and when to stop, such as planning, execution, validation, and revision. A graph defines which states exist and how transitions can occur from one state to another. A graph can contain one or more loops."},{"question":"Does every AI agent need a graph framework like LangGraph?","answer":"No. For simple, short tasks, a single agent and a minimal harness may be sufficient. Graphs become more valuable when conditional branching, parallel processing, intermediate state persistence, failure recovery, human approval, or execution path auditing is required."},{"question":"Do multi-agent systems always perform better than a single agent?","answer":"No. Multi-agent systems are useful when parallel research, distinct specialized roles, or context separation is needed. If roles overlap or goals are unclear, they may only increase duplicated work, handoff errors, delays, and costs."},{"question":"How do you prevent an agent loop from repeating indefinitely?","answer":"You should set not only a maximum number of iterations but also budgets for time, tokens, tool calls, and cost. The system should treat a state with no new information or reduction in errors as a lack of progress, and be designed to stop or escalate to a human once a certain threshold is reached."},{"question":"Is it enough to review only the Pull Request summary of code written by AI?","answer":"A summary is only supplementary material and does not replace the original changes. For high-risk changes involving authentication, payments, personal information, data migration, or deployment configuration, you must directly review the actual diff, test coverage, dependencies, and rollback procedures."},{"question":"If company documents are continuously injected, does that mean the model has learned them?","answer":"The results may change persistently, but the model weights have not been updated. This is system-level adaptation that preserves external documents, search indexes, memory, and instructions and provides them again in subsequent runs, and it should be distinguished from fine-tuning in the strict sense."},{"question":"Does graph engineering mean returning to the fixed workflows of the past?","answer":"Not necessarily. Modern graphs are closer to hybrid control: they allow agents to plan autonomously and select tools in some segments while explicitly restricting risky transitions and mandatory approval points."},{"question":"What should be determined first when designing a harness?","answer":"The task's success criteria and the cost of failure should be determined first. Next, it is best to provide only the necessary context and tools, and set least-privilege access, automated validation, execution logs, cost limits, and stopping conditions."}],"sources":[{"url":"https://www.anthropic.com/research/building-effective-agents","title":"Anthropic — Building effective agents","type":"source"},{"url":"https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents","title":"Anthropic — Effective context engineering for AI agents","type":"source"},{"url":"https://www.anthropic.com/engineering/multi-agent-research-system","title":"Anthropic — How we built our multi-agent research system","type":"source"},{"url":"https://docs.langchain.com/oss/python/langgraph/overview","title":"LangGraph overview","type":"source"},{"url":"https://arxiv.org/abs/2210.03629","title":"ReAct: Synergizing Reasoning and Acting in Language Models","type":"source"},{"url":"https://nvlpubs.nist.gov/nistpubs/ai/NIST.AI.600-1.pdf","title":"NIST AI 600-1 — Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile","type":"source"}],"images":[{"id":662,"url":"https://injoys.com/rails/active_storage/blobs/proxy/eyJfcmFpbHMiOnsiZGF0YSI6ODI0NSwicHVyIjoiYmxvYl9pZCJ9fQ==--3a03e254c3d24990df4c3fc46145a5db24e457ba/ai-eb0e40fe.webp","is_representative":true,"generation_method":"ai_image","license":"ai_generated","mime_type":"image/webp","translations":{"ko":{"alt":"중앙 AI 시스템을 순환 화살표와 성공·실패 노드 그래프가 둘러싼 다이어그램","caption":"AI 에이전트의 실행 루프와 보안 검증, 분기 경로를 시각화한 구성도다.","description":null},"en":{"alt":"Central AI system surrounded by loop arrows and a graph of success and failure nodes","caption":"The diagram visualizes an AI agent’s execution loop, security checks, and branching paths.","description":null},"ja":{"alt":"中央のAIシステムを循環矢印と成功・失敗ノードのグラフが囲む図","caption":"AIエージェントの実行ループ、セキュリティ検証、分岐経路を可視化している。","description":null},"es":{"alt":"Sistema de IA central rodeado de flechas cíclicas y una red de nodos de éxito y error","caption":"El diagrama representa el bucle de ejecución, las verificaciones y las rutas de un agente de IA.","description":null},"id":{"alt":"Sistem AI pusat dikelilingi panah berulang dan graf simpul keberhasilan serta kegagalan","caption":"Diagram ini memvisualkan loop eksekusi, pemeriksaan keamanan, dan jalur bercabang agen AI.","description":null},"pt":{"alt":"Sistema central de IA cercado por setas cíclicas e uma rede de nós de sucesso e falha","caption":"O diagrama mostra o ciclo de execução, as verificações de segurança e as rotas de um agente de IA.","description":null},"zh-hant":{"alt":"中央 AI 系統周圍環繞循環箭頭與成功、失敗節點組成的路徑圖","caption":"此圖呈現 AI 代理的執行迴圈、安全檢查與分支路徑。","description":null},"de":{"alt":"Zentrales KI-System, umgeben von Kreispfeilen und einem Netz aus Erfolgs- und Fehlerknoten","caption":"Das Diagramm zeigt Ausführungsschleife, Sicherheitsprüfungen und verzweigte Pfade eines KI-Agenten.","description":null}}},{"id":663,"url":"https://injoys.com/rails/active_storage/blobs/proxy/eyJfcmFpbHMiOnsiZGF0YSI6ODI1MSwicHVyIjoiYmxvYl9pZCJ9fQ==--cea797c99aabaa4b8f760264327fe2ee8b34b423/ai-23d7d97a.webp","is_representative":false,"generation_method":"ai_image","license":"ai_generated","mime_type":"image/webp","translations":{"ko":{"alt":"보안 하네스 속 AI 로봇이 도구 루프와 분기 그래프를 거쳐 검증 및 경고 단계로 이동하는 흐름","caption":"AI 에이전트가 보호된 환경에서 반복 작업과 그래프 분기를 거쳐 사람의 검증을 받는 과정을 보여준다.","description":null},"en":{"alt":"AI robot moves from a secure harness through a tool loop and branching graph to validation and a warning gate","caption":"The diagram shows an AI agent progressing through protected execution, iterative tools, graph branches, and human validation.","description":null},"ja":{"alt":"保護されたAIロボットがツールのループと分岐グラフを経て検証と警告ゲートへ進む流れ","caption":"AIエージェントが保護環境から反復処理、グラフ分岐、人による検証へ進む工程を示している。","description":null},"es":{"alt":"Un robot de IA pasa de un entorno seguro a un bucle de herramientas, un grafo ramificado y una puerta de alerta","caption":"El diagrama muestra a un agente de IA avanzando por ejecución protegida, iteraciones, ramas y validación humana.","description":null},"id":{"alt":"Robot AI bergerak dari lingkungan aman melalui loop alat dan graf bercabang menuju validasi serta gerbang peringatan","caption":"Diagram ini menunjukkan agen AI melalui eksekusi terlindungi, proses berulang, cabang graf, dan validasi manusia.","description":null},"pt":{"alt":"Robô de IA passa de um ambiente seguro por um ciclo de ferramentas e grafo ramificado até validação e alerta","caption":"O diagrama mostra um agente de IA avançando por execução protegida, iterações, ramificações e validação humana.","description":null},"zh-hant":{"alt":"AI 機器人從安全框架經過工具迴圈與分支圖，走向人工驗證及警示閘門","caption":"此圖呈現 AI 代理從受保護執行、反覆工具操作和圖形分支走向人工驗證的流程。","description":null},"de":{"alt":"KI-Roboter durchläuft eine sichere Umgebung, eine Werkzeugschleife und einen verzweigten Graphen bis zur Warnschranke","caption":"Die Grafik zeigt einen KI-Agenten bei geschützter Ausführung, iterativen Abläufen, Graphverzweigungen und menschlicher Prüfung.","description":null}}}],"published_at":"2026-08-16T00:45:12+09:00","updated_at":"2026-08-16T00:45:12+09:00","license":"cc_by","translation_status":"reviewed","available_locales":["ko","en","ja","es"],"data_locales":["ko","en","ja","es","id","pt","zh-hant","de"],"url":"https://injoys.com/en/articles/ai-agent-harness-loop-graph-engineering"}