"The conditions I just gave disappeared halfway through."
"I only wanted a part fixed, but even the parts I liked got changed."
"They told me it was complete, but nothing happens when I press the button."
Have you ever experienced this when having AI write text, create documents, or build websites?
Every time it happens, you redo the explanation, look for errors, and ask for corrections again. Before you know it, you are constantly monitoring the AI's work.
That's where we want to consider a harness.
It sounds like a difficult name, but the concept is very familiar. What do you delegate? Which documents do you use? How do you verify? If something is wrong, where do you fix it and when do you stop? This "way of proceeding with work" is prepared outside of the AI.
In this article, the Astra we handle is OpenAI's GPT-6 Astra, and Fable is Anthropic's Claude Fable 5.1. Based on official documents as of September 10, 2026, the latter half will look at applications for announcement texts, sales aggregation, and website production.
In addition, we plan to distribute a one-day-only harness video from here tomorrow👇
https://x.com/MakeAI_CEO/status/2027682940847898770?s=20
1. A harness is a mechanism for AI to proceed with work
For example, suppose you ask a capable person to "promote next month's event."
Even if that person is highly capable, they cannot create accurate guidance without knowing the date, participation fee, application destination, and target audience. If they don't have the authority to operate the company's SNS, they can't post, and if it hasn't been decided whether it's okay to publish, they can't put it out on their own.
Therefore, you hand over event materials, text samples, work procedures, verification items, and approval rules before publication.
Making similar preparations for AI is the entry point to understanding harnesses.
A harness is a mechanism that combines information to pass to the AI, tools to make it use, work procedures, and verifications or restrictions.
In fact, official Claude Code documentation explains Claude Code itself as a harness, providing tools, information management, and an execution environment around the model.
Let's clarify similar terms here.
A "prompt" is a request text to the AI. "Context" is the information the AI refers to during that task. A "harness" is the overall mechanism for proceeding with work while using them.
For an event announcement, "write an announcement" is the prompt. The event outline and past announcement texts are the context. The mechanism that drives the flow of reading materials, creating text, cross-checking dates and times, and publishing after approval is the harness.
In other words, creating one long prompt does not complete a harness by itself.
There is a difference between writing "please check before publishing" in text and actually stopping the publishing operation until the check is finished.
The "harness theory" referred to in this article is a way of thinking about designing the AI's workspace based on this difference. It is not treated as a single fixed mathematical formula or a feature name specific to a particular model.
2. Even if Astra and Fable get smarter, is preparation still necessary?
"Even without such preparation, won't the new AI do it by itself?"
It is natural to think so. In fact, OpenAI's official announcement for Astra explains its handling of tasks involving multiple steps, and Fable 5.1 also highlights improvements in problem-solving capabilities over long periods.
However, "the ability to think" and "having the necessary conditions met" are different things.
If you haven't handed over an unreleased participation fee, no matter how smart it is, it cannot determine the correct amount. If it isn't connected to the application form, it cannot verify whether people can actually apply.
What's worth noting is that OpenAI itself explained in the Astra announcement that, separate from model improvements, they also updated the Codex harness. They introduced new mechanisms for retaining and searching information to continue work.
Making the model smarter and preparing the working environment. Both are being advanced simultaneously.
On the other hand, there is no need to command a smart AI minutely word for word. What you want to decide are the purpose, conditions to protect, materials available, and verification methods. Leave the ingenuity within that scope to the AI. We aim for this division.
3. The first thing to decide is not the procedure, but "what constitutes completion"
When creating a harness, the first thing you want to write down is the acceptance criteria.
Phrases like "good announcement text," "a page that sells," or "easy-to-understand materials" change in judgment depending on the person. Therefore, make them conditions that can be verified by looking.
For example, for an announcement text, think as follows:
The target audience is clear at the beginning. The date, time, and participation fee match the approved materials. The application method is written. There are no technical terms without explanation. No ungrounded achievements are listed.
In this state, after the AI submits the text, you can verify how far it has come.
What is important here is to separate business goals from the acceptance criteria of deliverables.
"Increasing event participants" is a goal. However, at the point the text is created, you cannot verify whether participants have increased.
"The target audience, benefits of participating, date and time, and application destination are conveyed" can be verified at the text stage. After that, you look at the actual number of applications and make improvements.
Remember the goal, and decide what can be verified in the current process. Official evaluation design guides also emphasize clarifying success conditions and preparing verification methods suited to the task.
This preparation is to prevent making "it feels pretty good" the sole criterion for completion.
4. Rather than passing a lot of materials, decide "which one to use"
Suppose you pass three years' worth of past guidance, old price lists, new price lists, and meeting memos all together to an AI creating an announcement text.
Even if the materials increase, it will be troublesome if it doesn't know "which is the correct participation fee for this time."
Therefore, design the information by dividing it into three parts.
First, materials to verify the facts of this instance. Next, materials to refer to for text or design. And finally, old materials or unconfirmed memos.
If you write, "The event outline is the confirmed information for this time. Last year's announcement is referenced only for style. The proposals in the meeting memos are not treated as decided matters," the usage becomes clear.
This is a concrete example of context design. You don't just hand over information; you organize it down to what purpose it is referenced for. Anthropic also explains selecting necessary information and managing it during tasks as context engineering.
Decide how to handle cases where materials contradict each other as well.
Just because a date is newer doesn't necessarily mean it's correct. It might be a draft before publication. You can set it to "prioritize the approved event outline, and if contradictions still remain, report them as unconfirmed."
Also, divide the "scope within which it is okay to supplement things not in the materials."
It is okay to innovate on headline expressions. However, do not invent participation fees, event locations, number of people, or achievements. By deciding this, you can distinguish between parts you want to be creative and parts where you want to maintain accuracy.
Before increasing materials, decide the role of the materials. Starting from here makes it easier to organize request texts.
5. Separate "what can be done" from "what is allowed to be done"
Next, consider the tools the AI uses.
To look up the latest information, use search. To aggregate numbers, use spreadsheets or mechanisms that execute calculations. To verify a site, operate a browser, which is a tool for viewing web pages. To create images, an image generation tool is needed.
Asking "look it up" or "verify" in text is not the same as being able to execute that operation. In the official explanation of Claude Code, the model's judgment and the tools that perform actual operations are separated.
You might also see the term MCP. This is a common protocol for connecting AI apps with external data and tools. Simply put, it is a mechanism to standardize connection methods. It can be used as part of a harness, not the whole thing.
And prevent it from using connected tools without limits.
Creating a draft for SNS and actually posting it. Reading a list of sales and rewriting the source data. Consider permissions for these two separately.
In the practical examples of this article, we design it to delegate up to reading, creating drafts, and fixing copies for trial use, while inserting human verification for publishing, sending, purchasing, and deleting.
Furthermore, instead of relying solely on the text "do not delete," restrict it through permission settings and approval functions in the usage environment. Claude Code materials also explain that instruction files are not forced settings.
Regarding customer information and internal materials, instead of "handing over everything because it's on hand," design it to use only what is permitted to be handled in that AI environment.
Layer rules as requests with mechanisms that restrict operations.
This is also an important job of a harness.
6. The core of a harness is "Create → Verify → Fix"
A loop means repeating the same flow.
The loops used in harnesses are not just about rewriting text over and over. You verify the created result and change the next task according to that result.
The basic form is "Create → Verify → Fix problem areas → Verify again." Official Claude Code documents also explain the flow of repeating information gathering, action, and validation of results.
For example, suppose a button on an application page doesn't work.
Just asking "please make it carefully again" leaves what is failing ambiguous.
Instead, press the button on a trial page. Verify that it doesn't transition. Look up the set link destination. Fix the incorrect part. And press it again.
The verification result determines the next task.
At this time, there is no need to recreate down to the background color or headlines. Maintain the parts that have already passed, and fix focusing on the failing parts. However, re-verify the surroundings that might be affected by the correction.
Another thing needed is the stopping condition.
With "continue until it's perfect," you can't judge the end. Therefore, as an initial operational example, decide "corrections are up to three cycles. If the same problem continues for two cycles, report the cause and missing information, and stop."
This number of times is not an official optimal value. It is an initial setting example to be changed according to the size of the work or cost.
Stopping midway is not about covering up a failure.
You don't have the necessary authority. The source materials contradict each other. The cause cannot be narrowed down despite trying. In such cases, stop in a way that makes it clear that human judgment is required.
What matters is not the number of times repeated, but what was understood and what was changed by the verification.
7. What do you use to verify the AI's "I have verified"?
"No problem," "Everything has been verified."
Even if it is written so, if you don't know what was verified and how, the materials for judgment are insufficient.
Therefore, divide verification methods according to the content. Anthropic's evaluation materials also explain using programmatic verification, AI evaluation, and human evaluation appropriately.
For example, amounts or character counts are verified by calculation or counting characters. Dates, times, and achievements are cross-checked with original materials. Buttons are verified by actually pressing them.
On the other hand, "whether it makes people want to read" or "whether the explanation is tedious" cannot be fully judged by mechanical matching alone. Refer to the AI's review while humans also look from the reader's perspective.
Here, design the completion report to change as follows:
Instead of "Everything has been verified," make it report, "Dates and times match the event outline. Application destination matches the specified URL. However, the application completion screen after login is unverified."
With this, you can see how far you can delegate and where humans should verify.
Even for text with citations, do not pass it just because the URL exists. Look at whether that page contains content that supports that claim.
Do not mix what could be verified, what could not be verified, and what was inferred.
Even if you increase verification mechanisms, it doesn't mean you can discover all errors without fail. That is precisely why there is meaning in leaving the verification scope concrete. AI evaluation also has limits, and cross-checking with human judgment is necessary.
8. What do AGENTS.md, CLAUDE.md, and Skills do?
Let's organize the file names often seen here.
AGENTS.md and CLAUDE.md are "promises for work used repeatedly"
In Codex, you can write project instructions in a file called AGENTS.md. In Claude Code, CLAUDE.md is used to give continuous instructions. Both have mechanisms for the corresponding apps to read them.
For example, promises such as "use polite tone," "do not add customer achievements by inference," "do not overwrite source materials," and "clearly state unverified parts."
Instead of putting the same explanation in every request text, summarize them in a place that can be referenced repeatedly.
However, there is no need to put everything down to this month's event date and time into common rules. That is content to be written in the project materials for this instance.
Put promises used repeatedly in common rules. Put conditions for that work alone in project materials. Put where it has finished now in progress memos. Divide roles in this way.
Skills are "procedure sets used when doing specific work"
Skills summarize procedures or reference materials for proceeding with a certain type of task. OpenAI's official materials explain a mechanism to read detailed instructions when they become necessary.
For example, prepare "procedures for organizing minutes," "procedures for creating product descriptions," and "procedures for producing and verifying images" separately.
When making minutes, summarize statements, separate decided matters, and verify the person in charge and the deadline. When making images, verify the usage location, aspect ratio, necessary text, and reference atmosphere.
It is a form of taking out and using procedures for each job, even with the same AI.
Increasing files does not make it stronger by itself
OpenAI explained the problem of cramming everything into a huge AGENTS.md in a practical article on harness design, and reported using it like a table of contents that guides to necessary information.
To incorporate this idea into daily operations, divide it into "short rules that must be read" and "detailed procedures read when necessary."
Note that just writing a file name in a normal chat box does not mean files on the computer are automatically read. You need to place them according to the reading method of the app you use, or hand them over as materials.
9. Astra and Fable can be divided into a "creator role" and a "verifier role"
If using two AIs, a design that divides roles can be considered.
For example, Astra creates an article, and Fable looks for inconsistencies with materials. Or Fable creates a page, and Astra verifies if it follows specifications.
However, there is no need to decide that "Astra is in charge of logic, Fable is in charge of sensitivity." Try it with your own work and choose the combination that resulted in fewer corrections.
The method of separating creation and evaluation itself is introduced by Anthropic as one of the workflows. It is explained as suitable for work where evaluation criteria are clear and improvement through correction can be verified.
What is important is not to hand over only the finished product to the verifier.
Even if you hand over only the text and ask "are there mistakes?", the original request is unknown. Hand over the target readers, acceptance criteria, evidence materials, and content that must not be changed together.
Ask the verifier in this way:
"Please point out violations of request conditions, inconsistencies with materials, and insufficient verification separately. Please separate differences in preference from mandatory corrections. There is no need to force fixes on areas with no problems."
The creator does not just adopt those pointers entirely as they are, but checks the source materials and makes necessary corrections.
Even if two AIs give the same answer, that alone does not constitute proof of fact. Because if they are reading the same incorrect materials, the possibility of making a mistake in the same direction cannot be ruled out.
And do not assume that Astra's chat and Fable's chat automatically share information without any settings. To begin with, an operation where a human hands over necessary content is sufficient.
It is perfectly fine to start by making a draft with one AI and having a human verify it. Using both Astra and Fable is not mandatory.
Even when using two, use them to separate the perspectives of verification.
10. How does it change in practice? Three design examples
From here, let's replace it with work. The following are operational examples using the ways of thinking up to this point, not actual measurement results.
Example ① Creating SNS announcement text
The request is "create an announcement text for a seminar for beginners."
First, hand over the approved event outline, people you want to read it, application destination, and past texts. Past texts are references for style and are not bases for this year's dates or prices.
The creator makes a draft focusing on what people can take home by participating. The verifier cross-checks dates, amounts, target audience, and application methods.
For example, if "you can earn 100,000 yen every month if you take the course" is written in the draft and there is no basis in the materials, delete it. Instead, concretely explain the operations or deliverables actually handled.
On the other hand, if the application destination was missing from the body, what should be added is the application destination. There is no need to change down to the expression at the beginning entirely.
After correction, verify whether necessary information is present. Publication is after approval.
After publication, look at whether it led to applications, not just the number of views. However, do not immediately judge differences in response as the effect of text alone; also consider differences in posting times or the audience it reached.
Do not end with "I made a post," but design content verification and review after publication separately.
Example ② Summarizing a list of sales
The request is "aggregate this month's sales."
The first thing to decide is the meaning of aggregation. Do you count by the day sold, or by the day deposited? How are refunds handled? Is it tax-included or tax-excluded?
If this is not decided, even if the addition is correct, it will not be the number you want to know.
Use a copy for work, narrow down the target period, and execute calculations. If there are suspicions of blanks or duplicates, do not fill or delete them arbitrarily, but separate them as verification targets.
Finally, leave not just the total amount, but also the number of aggregated items, rows excluded from the target, and the reasons.
For example, instead of just "the total is 800,000 yen," make it in a form where you can understand "aggregated 40 items in the target period. 2 items with blank dates are pending." Numbers are temporary examples for explanation.
Leave organizing the meaning of columns or extracting verification items to the AI, execute calculations with spreadsheets or the like, and a human cross-checks some details with aggregation rules.
The purpose of this example is not automation of tax judgment, but aggregation where you can track which data was counted how.
Example ③ Creating a product introduction page
The request is "create a product introduction page." When using the word LP, it refers to a page for leading to applications or purchases.
First, decide the target audience, product content, price, images, application destination, and expressions not to include.
Next, verify necessary functions before the appearance. The application button connects to the specified destination. Text can be read on smartphones. If there is an input form, handle blanks or input errors appropriately.
After creation, open the page in a trial environment to verify. Check the display with screenshots, and operate buttons to look at movement destinations. Verify forms with permitted testing methods, and do not arbitrarily generate actual orders or transmissions to customers.
Even if only the appearance is neat, do not make it a pass if applications cannot be made. Conversely, even if it works, if the price is wrong, correct it.
Even in Anthropic's experiments on long-duration tasks, problems of treating it as complete just by changing code were reported, and procedures to verify user operations in a browser have been incorporated.
Have a human perform final verification before publication, and make it so it can be reverted to the original state.
11. Common instruction text that can be used for the first instance
There is no need to build a complex mechanism all of a sudden. First, try aligning the purpose and verification method in one job.
The following instruction text is a draft for that purpose. Rewrite inside the square brackets to use it.
1Please proceed with the following work by dividing it into creation, verification, and correction.23【Work】4［What to create, what to organize］56【Purpose and User】7［Who uses it for what purpose］89【Acceptance Criteria】10［Conditions that can be concretely verified upon completion］1112【Materials to Use】13［Material names or permitted reference destinations］14Please distinguish between materials to verify the facts of this instance and materials to reference only for expressions.15If there are contradictions between materials, do not arbitrarily decide one is correct.1617【Things That Must Not Be Changed】18［Prices, dates and times, proper nouns, approved content, etc.］1920【Scope of Work Allowed】21［Creation of drafts, editing within specified folders, etc.］22Please do not execute publication, transmission, purchase, deletion, or permission changes before explicit approval.2324【How to Proceed】25First, please verify the request content, materials, and available tools.26If there are important shortages, please explain their impact.27You may proceed with parts that can be advanced regardless of shortages.2829Once the first deliverable is made, please verify it against each acceptance criterion.30Please verify facts with source materials, numbers with calculations, and operations with permitted tests.31If tools or authority necessary for verification are absent, please mark as unverified.3233Please correct focusing on failed areas, and re-verify related parts.34Please do not make it a pass by loosening the acceptance criteria themselves.3536Corrections are up to three cycles. If the same problem continues for two cycles,37please report the attempted content, remaining problems, and necessary judgments, and stop.3839【Final Report】40Please show deliverables, verified items, materials or test results serving as their evidence,41unverified items, and points humans should judge separately.
This instruction text alone does not add search, browser operations, or connections to external services. Execute it in an environment where they can be used, and humans take charge of verifications that cannot be done.
Also, restrictions on publication or deletion need to be protected by permissions or approval settings on the app side, in addition to writing them in text.
Please use it not as an "instruction text to automate anything," but as a request form that clarifies what can be done and the scope of verification.
12. For long jobs, leave "memos where the continuation can be understood"
Creating multiple articles, fixing a site over several days. In such jobs, also manage how far it has finished now.
Instead of relying solely on rereading conversations from the beginning, summarize the purpose, decided matters, uncompleted tasks, verification results, and the next move.
In experiments on long-duration tasks published by Anthropic in 2025, a method was introduced where the role of setting up the environment at the beginning and the role of proceeding little by little were separated, inheriting the continuation through progress files or change histories.
For daily operations, you can start with a memo like the following:
"The purpose is the completion of the product introduction page. Body text and price are approved. Smartphone display is verified. Application button transition is unverified. Next is verifying the link destination. Approved body text and price will not be changed."
The next task becomes clearer than "I advanced website production."
Also leave the locations of materials or the verified versions. Instead of "looked at the latest version," make it in a form where you can identify which file was looked at.
However, memos can also be wrong. The next person in charge cross-checks important completed matters with deliverables or verification results.
Handover is a task of leaving materials from which to start the continuation, instead of expecting memory to be perfect.
13. Failures to avoid before making the mechanism larger
The first is using large-scale loops for all jobs.
There is no need to line up a researcher role, writer role, and verifier role every time for a single sentence paraphrase. Anthropic also recommends starting from the simplest possible solution without increasing complexity until it becomes necessary.
The second is continuing to add rules every time a mistake is made.
If "make it short" and "explain everything in detail" clash in the same situation, it will trouble judgment. Before adding, review whether old rules can be deleted or whether jobs to apply them to can be divided.
The third is treating external text as commands as they are.
Text prompting operations unrelated to the request can sometimes be mixed into read pages or materials. Such attacks that attempt to change AI behavior through external data are called prompt injections.
Countermeasures are not just telling it to "be careful." Treat external materials as information to reference, give only necessary authority, and put approvals into outgoing transmissions or important changes. Combine multiple countermeasures, including limiting how information is passed. Even so, danger cannot be completely eliminated.
A harness is a mechanism not only to increase what can be done, but also to decide the scope not to delegate.
14. Verify whether you got better with "your own work"
Finally, verify the effect of putting in the harness.
What you want to see is not whether the AI worked for a long time. Did deliverables meeting conditions increase? Did human corrections decrease? Did unverified items become visible? And do the cost or waiting time match?
For example, choose a few announcement texts you often request, and compare conventional request texts with the new way of proceeding. Align materials, acceptance criteria, and available tools, and record places humans fixed and the time taken for verification.
Because AI output fluctuates, avoid drawing conclusions from a single success alone. OpenAI also emphasizes evaluations suited to actual uses and continuous verification.
Even if price mistakes decrease, if verification work increases significantly, consider another way of fixing. Look at whether you dropped conditions that could be protected before, in exchange for changes in text making it easier to use.
The same applies when updating models. Detailed instructions that were necessary before are not necessarily necessary now. Leave only what is necessary for the current work.
The first thing to prepare is not a huge mechanism for the entire company. Start from choosing one job you often request and deciding the completion conditions and verification methods for that job.
Whether to leave it to Astra or leave it to Fable. Alongside that choice, consider "how to leave it."
What to create. What to base it on. Which tools to use. How to verify what was made. If it doesn't get fixed, where to return it to a human.
When you can answer these five, requests to AI change from mere favors into work that can be advanced while verifying.
The harness theory is a way of thinking where, when delegating work to AI, you prepare the way of proceeding until completion and the grounds for judging it as complete together.
