A good AI conversation is not an operating system

I do not want AI only to help me write an article in the current chat. I want it to remember what the article is trying to do, which claims are still open, what sources can support them, which draft was rejected and what has to happen before anything gets published. Another session or another model should be able to resume the job without asking me to reconstruct it.

That is a different kind of leverage from getting a good answer in a chat window.

In an ordinary AI conversation, the user still carries most of the operating system in their head. They know the history, the quality standard, the exceptions and what should happen next. The model may produce useful work, but the decisions and corrections often remain trapped in that conversation.

Technical users have another option. They can ask AI to build applications, databases and automations, then inspect the machinery when it fails. From the outside, the apparent choice is to stay inside consumer chat or become technical enough to build an elaborate system.

There is a useful layer between those two. A person without a technical background can put a recurring job around an AI agent using files that carry context, instructions, tools, outputs, state, logs and review rules. The resulting system can be elaborate in what it coordinates without requiring its owner to design and code a conventional software product.

This does not make setup or integration disappear. It changes the division of labour. The person explains the work and judges what comes back. AI can author much of the scaffolding, while a technical specialist remains available when security, infrastructure or difficult integrations demand one.

Put the job around the model

Take a recurring marketing job. An experienced marketer does not simply ask for “three Facebook ads.” They bring a view of the audience, the offer, the evidence, the claims the business can defend and the difference between a new variation and the same appeal wearing another headline.

A job-specific system can preserve those inputs, assemble a brief, generate bounded variants, format the output and record what was tested. When results return, it can update the experiment history and prepare the next decision. The marketer no longer has to transport every fact between tools or rebuild the briefing logic from memory.

The repeated handling can move to AI. The commercial judgment does not have to.

For any job, I now ask seven practical questions:

1. What does the worker need to know? That becomes memory and context.
2. How should the job be performed? That becomes instructions.
3. What must it read, write, calculate or operate? Those are its tools.
4. What does the work create? Those are the output files.
5. Where is the work now? That is state and pipeline.
6. What happened before? That belongs in logs and changelogs.
7. Who decides whether the result is acceptable? That is human review.

Under the surface, this might be a set of Markdown files, local agent instructions, command-line tools and connectors to other systems. The owner does not have to become a software engineer before beginning. Their contribution is to describe a real job and recognise what the generic procedure misses.

Nontechnical describes the person’s ability to build the machinery, not their ability to judge the domain. An experienced marketer may know exactly why an ad is wrong without knowing how to code the system that produced it. If the person is also new to marketing, an AI-generated procedure does not manufacture the missing expertise. The system needs reliable references, a capable reviewer or narrower authority.

Years of experience show up in small discriminations. A seasoned marketer may notice that three supposed ad variants all rely on the same promise. They may recognise that a cheap lead is attracting the wrong buyer, that a persuasive claim cannot be supported or that a channel result should not be read as a profit result. These corrections are hard to get from a generic prompt because the prompt writer may not know they need to be stated.

The marketer does not have to extract all of that knowledge in advance. Start with enough to run one bounded job. The first uses can expose omissions, exceptions and standards that an abstract interview missed. Each useful correction can then move into the context, procedure, example or review gate that the next run will actually read.

A complete-looking system can still be empty

I learned the limit of this approach on the first run of my own writing system.

The worker had the operating document, a detailed handoff, source boundaries, a content brief and a verification requirement. It returned a fluent section. It also marked three checks PASS. None of those checks had been exercised.

The prose compressed seven parts of my thinking into a neater four-part formulation. It made conclusions sound settled when they were still open. It wrote about “Brent” in the third person, as if I were a case study inside my own draft. The verification layer was supposed to catch that drift. Instead, it reported success.

The failed version remains preserved byte for byte. The checks now say NOT TESTED, and the article returned to argument framing.

The model made real errors. The assignment also asked one worker to index sources, design a router, form an argument, write prose, test another provider and verify its own work. Several kinds of judgment had been compressed into one return. A more capable model might have written better prose while leaving that control problem untouched.

This is the trap when someone uses AI to build beyond their own technical ability. AI can generate an impressive architecture faster than the owner can learn what it means. The folders look organised. The instructions sound authoritative. A demo works. None of those things tells us whether the system will recognise its own boundary on the next awkward case.

Make the system learn separately from the job

I find it useful to separate the work into a delivery loop and a learning loop.

The delivery loop closes the current artifact. It identifies the job, loads the relevant context, performs the repeatable work, checks the result and either accepts or rejects that version.

The learning loop begins with a consequential mismatch. The operator works out whether the likely cause sits in the context, instruction, tool, output contract, state or review step. They make the smallest plausible correction, say what should be different next time, then choose a case capable of showing whether that correction helped.

This distinction matters because useful work can survive borrowed clarity. A polished explanation may persuade the operator and everyone around them. The artifact may even work. But the operator still cannot reproduce the judgment, repair an exception or explain where the procedure stops applying. The debt arrives when the work must be adapted, handed over or defended.

Reality does not turn every experience into learning. Someone still has to notice the relevant mismatch and resist encoding the first convenient explanation.

This makes “human review” more demanding than placing a person at the end of a workflow. The reviewer has to recognise what matters, locate the likely source of failure, predict what a correction should change and know when the system needs narrower authority or outside expertise. Without that ability, the human gate is decoration.

Close only what the work has earned

That is why version closure and epistemic closure have to remain separate. A current artifact can be good enough for its stated purpose while the underlying understanding stays provisional. A sales deck can close as version one, go into a real call, meet an objection and return with one weak slide exposed. The next version carries a better explanation. After enough use, parts may become stable enough for another person to run. Other parts remain open.

This approach works best when mistakes are reversible, visible and reviewed by someone competent. A Markdown file is cheap to edit; validation may still be expensive. Medicine, finance and other high-consequence work need stronger evidence, authority limits and escalation before early versions touch real decisions.

For someone without a technical background, the practical beginning is one recurring job. Define what the job produces and the consequence of getting it wrong. Give the agent only the context, instructions and tools needed for that job. Review the output against visible criteria. Record one consequential mismatch and place the smallest correction where the next run will find it. Then choose a case that could prove the correction wrong.

This does not automate away the person. It automates repeated handling so they can spend more time selecting, judging and correcting. When they do have years of domain experience, that experience stops living only in their head or inside yesterday’s chat. It begins to shape how the work runs tomorrow.

My writing system is still in that process. Its failed first section is part of the evidence. This revised article is another run. The process repair earns a place only if a fresh session can resume without asking me the same questions and a different kind of note can use the system without acquiring a pile of unnecessary files.

AI can help a person without technical skills build the machinery. Real work decides which parts deserve to remain.