AI Should Start the Job
Most companies put AI in the wrong place in the loop. Here is where it belongs, and the trigger schema to put it there.
Last updated on this site: · Imported text preserved; publication date shown above.
If a person has to start the job, AI is not doing the work. It is waiting to be asked.
Every company I talk to has AI in the building. Most have it in the wrong place.
The tool is fine. The model is fine. The problem is where the work begins, where it ends, and where the human sits in between.
Ask is a habit. Do is a decision. If you decide AI should do the work, here is how to wire it so it actually does.
The wrong place in the loop
Picture the loop as a line. Something happens. Someone gathers context. Someone decides. Someone acts. Someone checks. Someone records what happened.
In most companies, a human does the first step and the last step. AI sits in the middle, answering when poked.
That is not an AI employee. That is a very fast intern who only works when you walk over to the desk.
Six mishaps I see again and again
These are patterns, not a survey. I have not measured how common each one is. But I see all six in company after company, including good ones.
1. A human starts it. The work waits for someone to open a chat and type. If nobody types, nothing happens. The ceiling is how many people remember to ask.
2. A human is the courier. AI writes the answer. A person copies it into the system where it matters. The person is now a clipboard.
3. AI is the advisor. It summarizes, suggests and explains. Then it stops. Advice is cheap. The job is still sitting there.
4. Approval sits in the middle. A person signs off on every step. The loop moves at human speed, so the AI adds almost nothing. Put the approval at the end, on the finished work.
5. Many owners, one job. Three teams each build their own version of the same agent. Each has its own memory, its own rules and its own way to fail. Fixing one fixes nothing else.
6. No record, no measure. Work is handed off through chat memory. Nobody logs runs, edits or failures. The only number is hours saved, and it is a guess. What you measure is what you get. Measure hours saved and you get a faster ask culture.
One more thing sits under all six. The agent often runs on a person's logged-in browser. The person signs out and the job stops. A job that depends on a person's session is not unattended.
What a loop looks like when AI is in the right place
Not X. Y.
Not "a person asks, AI answers." An event happens, AI starts, AI finishes, a person approves.
The agent owns everything between the trigger and the finish line. It gathers context itself. It takes the actions itself. It checks its own work against a written standard. It hands a finished package to a person for one decision.
The human does not disappear. The human moves to the end, where judgment is worth the most.
The trigger schema
Here is the schema I would put in front of any team building an AI employee. Every job gets one. If you cannot fill in a field, the job is not ready to hand over.
| Field | The question it answers |
|---|---|
| event_source | What system or clock tells the agent that work exists? |
| trigger_condition | What exactly must be true to start? What must be filtered out (tests, duplicates)? |
| context | What does the agent pull before it acts? From where? |
| owner | Which agent owns the job, and which human owns the agent? |
| actions | What may the agent do on its own? In which systems? |
| limits | What is read-only, what needs approval, what is never allowed? |
| human_checkpoint | Where does a person look, and what do they decide? |
| done_when | What proves the job is finished? |
| escalation | What does the agent do when it is stuck, wrong or out of its limits? |
| record | Where is the written handoff and the run log? |
| learning | How do human edits and failures change the playbook? |
As a block you can copy:
job: <name>
event_source: <webhook | queue | schedule | threshold | message>
trigger_condition: <what must be true; what to ignore>
context:
- <system and record to read before acting>
owner:
agent: <one agent per function>
human: <named person accountable for it>
actions:
allowed: [<what it does without asking>]
limits:
read_only: [<systems>]
needs_approval: [<external sends, deletes, bulk changes>]
never: [<hard stops>]
human_checkpoint:
where: end_of_loop
decides: <approve | edit | reject>
sampling: <how often a person spot-checks approved work>
done_when: <observable proof of completion>
escalation:
on_stuck: <who, how fast>
on_limit: <who, how fast>
record:
handoff: <ticket or account ID, what was done, what is next>
run_log: [<runs>, <human minutes>, <edits>, <failures>]
learning: <how edits become playbook changes>
Three examples
None of these are mine. They are generic on purpose.
A new customer signs up (event).
job: set up a new account
event_source: signup webhook
trigger_condition: new, paid, not a test, not a duplicate
context: [signup form, plan, account record]
owner: {agent: onboarding agent, human: head of customer success}
actions: {allowed: [apply the standard configuration, draft the welcome email]}
limits: {needs_approval: [sending anything to the customer]}
human_checkpoint: {where: end_of_loop, decides: approve the package}
done_when: configuration verified and welcome email drafted
escalation: {on_stuck: owner within one hour}
A support ticket nears its deadline (threshold).
job: prevent a missed deadline
event_source: ticket system
trigger_condition: open ticket within a set window of breaching its response target
context: [ticket thread, customer history, relevant playbook]
owner: {agent: support agent, human: support lead}
actions: {allowed: [diagnose, draft the reply, propose reassignment]}
limits: {needs_approval: [send reply, reassign]}
human_checkpoint: {where: end_of_loop, decides: send, edit or reject the draft}
done_when: reply approved and sent, or ticket reassigned with a note
escalation: {on_limit: support lead immediately}
The monthly account review (schedule).
job: monthly review for each active account
event_source: calendar, first business day
trigger_condition: account active for at least one full month
context: [last month's results, open issues, the account's goals]
owner: {agent: review agent, human: account manager}
actions: {allowed: [pull data, write the report, draft recommended changes]}
limits: {read_only: [production settings], needs_approval: [any change]}
human_checkpoint: {where: end_of_loop, decides: approve recommendations}
done_when: one report per account, filed in the record
learning: rejected recommendations feed the next month's rules
Three triggers: an event, a threshold and a clock. Most jobs fit one of them. A job that fits none is usually not a job yet. It is a hope.
The ladder
I have watched this movie before. Toner to PCs. Shrink-wrap to SaaS. Each step looked like a tool change. It was a change in who starts the work.
| Level | Who starts it | Where the AI sits | Where the human sits |
|---|---|---|---|
| 0 | Human | A chat tab | Everywhere. Asks, copies, pastes. |
| 1 | Human | Inside a tool, drafting | Starts it, checks every output |
| 2 | A trigger | One step in a workflow | Sequences the steps, approves in the middle |
| 3 | A trigger | Owns the whole loop | Approves the finished work |
| 4 | The agent, from conditions it watches | Owns the loop and the trigger | Sets goals and limits, reviews samples, handles exceptions |
Level 4 is what I mean by Dark Factory. The lights are off. The work still gets done. People spend their time on exceptions, standards and decisions, not on pushing the work along.
Most companies I see are at level 0 or 1 and call it adoption.
What it takes to be at the top end
It is not a better model. It is discipline.
Codify first. AI does the work. Humans orchestrate. But first, humans codify. If the playbook lives in someone's head, the agent cannot run it.
Write the trigger for every job. Use the schema. No trigger, no job.
One owner per function. One agent, one named human. Not three teams building the same thing.
One writer per system of record. Other agents send results to it. They do not write on their own.
Drafts by default for anything external. A sent message cannot be recalled. Keep a person on that door until the agent has earned it. Reads and drafts are cheap to undo. Sends, deletes and bulk changes are not.
Run it unattended. Use proper service access, not a person's browser session.
Measure the loop. Log runs, human minutes, edits and failures. Time a sample. Replace the guess with a number.
What I have not tested
I have not tested this schema in every kind of company. A regulated business will put more steps behind approval, and it should. The checkpoint belongs at the end of the loop. How hard the end is to reverse decides how heavy it needs to be.
Ask culture has a ceiling, and the ceiling is the number of humans you have.
Continue the conversation
Have a perspective to share?