Nik McFly
← Blog

Published · Updated

Your AI System Needs an Owner

A practical test for deciding what an AI system may do, what a good result looks like, and when a human must stop it.

#ai#claude#operations#skills#harness

I audited 22 AI skills that I had installed or written. A skill is a small package of instructions that tells an AI how to perform a particular job.

Only five of the 22 had a complete operating contract. The other 17 had a name and a description, but left important questions unanswered: what the skill could change, what it must never do, what evidence it had to produce, and when it needed human approval.

The tools worked. The ownership was missing.

An AI system has an owner when one person is responsible for its purpose, limits, and result. This is not the same as being the person who wrote the prompt or pays for the software.

Ownership should be written down

Every repeated AI workflow needs answers to six questions.

1. What job does the system perform?

Describe one result, not a general ambition.

Weak:

Help with our music releases.

Useful:

Check a release package for missing credits, inconsistent artist names, and incomplete ownership fields before it is sent to the distributor.

The second version gives the system a finish line.

2. What does a good result contain?

List the evidence required before the task can be called complete.

For the release check, that might include:

  • the final audio filename;
  • artist and track names exactly as they will be delivered;
  • songwriter, producer, and ownership fields;
  • cover-art dimensions;
  • a list of missing or conflicting information;
  • a final status of ready, blocked, or needs review.

Without this list, the model can produce a confident paragraph instead of a checked release.

3. What may the system change?

Reading a folder is different from editing it. Editing a draft is different from sending it. Preparing a release is different from submitting it to a distributor.

Write the boundary explicitly:

may read: release folder and metadata sheet
may create: review report and corrected draft
may edit: nothing without confirmation
may submit externally: never

Tool permissions are a technical control. The written rule explains why the control exists and who can override it.

4. When must a human decide?

Human approval is most useful at decisions that are expensive, public, or difficult to reverse.

Examples include:

  • publishing or deleting content;
  • spending money;
  • sending a message outside the company;
  • changing ownership or payment information;
  • filing a legal document;
  • moving production traffic;
  • accepting a result with missing evidence.

Do not require approval for every small step. That turns the human into a button. Put approval at the real decision point.

5. How can the result be checked?

“The agent says it worked” is not verification.

The check may be a screenshot, a comparison with the original file, a test result, a transaction record, a list of changed fields, or a link to the published page.

The evidence should match the risk. A spelling correction needs a diff. A production migration needs tests, a rollback path, and checks against the live system.

6. Who notices when it fails?

Name the person who receives the warning and the condition that triggers it.

An owner is not somebody who reviews a dashboard once a quarter. The owner must know when the system is blocked, uncertain, outside its limits, or producing a result that cannot be verified.

A short contract is enough

The first version can fit on one page:

# Release metadata checker

Owner: [name]
Job: Check one release package before delivery.

Required inputs:
- final audio
- cover art
- metadata sheet

Required output:
- issue list
- corrected draft
- ready / blocked / needs review status

Allowed actions:
- read the release folder
- create a report

Requires approval:
- editing source metadata
- uploading to a distributor
- contacting an artist or partner

Stop when:
- ownership is unclear
- two sources disagree
- a required file is missing

Proof:
- list every checked field and source file

The value comes from the specific refusals. A generic file full of words such as “be accurate” and “follow best practices” does not tell the system what to do when two real records disagree.

More tools can make the gap worse

Adding memory, external tools, or more agents increases what the system can do. It does not decide what the system should do.

When ownership is unclear, extra capability creates three common problems:

  • the system improves something outside the requested scope;
  • a reversible draft quietly becomes an external action;
  • nobody can tell whether the result is complete because no standard was defined first.

The solution is usually not a longer prompt. It is a clearer operating decision made by the human responsible for the outcome.

Choose one AI workflow you use every week. Write its owner, allowed actions, approval points, stop conditions, and proof of completion. If those five lines are hard to write, the workflow is not ready for more autonomy.

The same principle applies to personal use: AI can perform more of the work, but you still need to know what you are trying to preserve. I explore that human side in The Anti-AI Brain.