Human-Friendly, AI-Optimized: designing AI for the person still in the loop

Much of the effort in AI work goes into the machine: the prompts, the pipelines, the agents and the checks on what they produce. It has to. But every one of those loops still has a person in it, someone who approves, takes the exceptions and answers for the result, and that person is often designed last, or not at all. Traide’s tagline is Human-Friendly, AI-Optimized, and it is also how we work. This post sets out what the two halves mean, the six principles we work by, and the five questions we ask before an AI loop goes live.

Why both halves

AI-optimized is not optional. A loop built for a model works in small, well-specified steps. It gives the model the context it needs in a form the model can read, uses the right model for each job, and checks the output automatically. Skip that, and no amount of care at the human end will rescue the loop.

But a loop that is only AI-optimized fails at the human edge, and it fails quietly. Approvals get rubber-stamped, because nobody can read what they are approving. Exceptions land in a queue nobody owns. The one question the system needed answered sits at the bottom of a long report, where nobody reads it as a question. When the loop surprises the person in charge, trust drops, and a loop nobody trusts tends to get switched off.

So we design every loop for two users: the AI that does most of the work, and the person who stays accountable for it. When the two pull apart, the person wins. We would rather ship a slower loop a person understands than a faster one they cannot.

Six principles

1. Every loop names its person

Before we automate anything, we write down who it answers to: who approves, who takes the exceptions, and who is accountable when it is wrong. A workflow with no named person is not finished, however well it runs. In our own engineering, that person is a senior engineer, who reviews every change our AI writes.

2. Machines take the volume, people take the judgment

AI does the sweep: the drafts, the reviews, the tests and the triage. A person’s time goes to the calls only a person can make. Automated review runs first on every change we ship, so the review a person gives goes to what the machines could not settle. We judge a loop by the attention it saves, not by how much of it is automated.

3. Decisions arrive as decisions

When a system needs a person, it asks a question they can answer in seconds: the options, a recommendation, and what each choice changes. Not a wall of output that ends in “let me know”, and not a line in a summary that nobody reads as a question. Our own AI works under this rule: when it needs a decision from us, it asks a multiple-choice question, with its recommendation first. When it slips back into a paragraph that ends in a question, we correct it.

4. People hold the irreversible

Spending money, changing production, granting access and speaking for the business are where a person signs off. The agent tools we build for marketplace operators work this way. An AI agent’s request over the limit the operator sets, or of a kind a person must always see, is held. A person approves it, and only then does it run, once, with the arguments it was held with. The approval lifts the hold. It never lifts a limit or a rate cap. In our own work, a change to production infrastructure reaches it as a plan that a person reads and applies, and what our AI drafts for publication, a person edits and puts out.

5. Show the work

Every automated step should leave a record a person can read: what it did, on what evidence, and what it changed. A failure should read as plainly as a success, because a loop that hides its misses teaches its person to stop looking. Each approved call in those operator tools records what it made or why it failed, and says so if that record cannot be written. Every change we ship starts as a written plan and passes automated checks and review.

6. Write for both readers

People get short, plain words. Machines get structured, typed and complete data, written from the same facts. This site has pages for people and an llms.txt file for AI answer engines. Our operator tools answer an agent with a sentence a person can read and structured data the agent can parse, in the same response.

Five questions before an AI loop goes live

These are the questions we put to a loop before it goes live. They work for any team:

1. Who is the person in this loop, by name or by role, and what do they see?
2. What can the AI do without asking, and where exactly is the threshold?
3. When the person is needed, what do they get: a decision, or a document?
4. Can they see why it did what it did, from the record alone?
5. Can they stop it, take over or undo it, without calling an engineer?

If any answer is “not yet”, the loop is not finished. Guardrails enforced in code answer the second question; the other four are design work, and they are the part teams often skip.

What this means for you

If you are putting AI into a workflow your team depends on, the machine half is the part everyone will help you with. The person half is where loops are won or lost, and it is the part we design first. You can read the short version on our About page. And if you want both halves right in your own loops, talk to us.