This is Part 3 of our The Field Guide to AI for Non-Tech CEOs.
Looking for Part 1? –> Part 1. Demystifying AI.
Looking for Part 2? –> Part 2. How AI systems actually work.
HITL, HOTL and HOOTL. Where should humans sit in AI workflows?
You will often hear three acronyms when people talk about AI oversight:
- HITL: Human in the loop
- HOTL: Human on the loop
- HOOTL: Human out of the loop
First, do not see this as a ladder. Systems can have HITL + HOOTL for example.
Second, HITL / HOTL / HOOTL concern specific steps in a workflow, not an entire workflow (unless it’s a simple one, eg just a few steps long).
This will take some explaining.
HITL: Human in the loop
For example:
- approve or reject the next action
- validate some AI outputs before moving on
- ask humans to provide missing information
- handle an exception escalated by the system
A common pattern is to make HITL conditional:
- normal cases proceed automatically
- unusual cases get escalated
- high-value or high-risk actions require approval
- low-confidence outputs go to a human
That gives you the benefits of automation without putting a human checkpoint in front of every trivial action.
HOTL: Human on the loop
Imagine a self-driving car: it just drives, but you can take the steering wheel if need be. That’s HOTL, not HITL (e.g. the car doesn’t stop to ask the driver to do something, but the driver can decide to act if something goes wrong).
In purely software cases where no hardware / equipment is concerned, HOTL is less frequent.
One example is with automated trading or bidding: AI can decide to take action on certain price points, thresholds etc but a human can also intervene and change the strategy if need be.
If humans’ role is just to look at what happened after the fact and can’t intervene, we’re talking about HOOTL.
HOOTL: Human out of the loop
That sounds dangerous, but in fact lots of steps in a workflow qualify as “HOOTL”. For example, when AI decides it needs to retrieve info from your system (and you allowed it to do so in your architecture), that’s boring HOOTL.
Now that you understand the terminology, the key is to know how to decide what steps is HITL / HOTL / HOOTL.
How do you decide where humans belong?
Here is a simple checklist to determine what each step should be: HITL, HOTL or HOOTL?
Question to ask for each workflow step
Does a human need to approve this before the AI can proceed?
If yes → HITL
Examples
- Policy/regulation requires it
- The action has high consequences if wrong
Is this an escalation touch point?
If yes → HITL
Examples
AI cannot decide on a next action because the input is too ambiguous. Instead of trying a “best guess” approach, have a human decide.
Can the AI proceed autonomously within clearly defined limits?
If yes → Usually HOOTL
Examples
- Refund a customer under a certain amount
- Approve an employee reimbursement under a certain amount
- Access to tools to read / write certain data from your systems
Generally, outside the limits, revert to HITL
Do the steps where you think humans may need to intervene have low consequences and do not mandate HITL, but would require intervention (pausing, changing an execution, etc.) from time to time?
If yes → HOTL
Examples
Automated bidding where amounts are low enough yet in high volumes, making it impractical for humans to approve every transactions but where intervention may be required under special conditions
A simple rule of thumb would then be:
A final note on the “illusion of safety”.
One could design a perfectly logical workflow with the right HITL steps, but still end up in a mess because humans are overwhelmed by the volume of approvals and just rubber stamp everything.
So deciding on HITL / HOTL / HOOTL is not as simple as following a checklist. It is a balancing act, requires heavy cross functional collaboration and will take a few iterations to get right.
If you can manage people, can you manage AI agents?
On the surface, it seems delegating work to AI to do some work for us is akin to delegating to humans.
But I think that’s not a very good analogy and we should not anthropomorphize AI too much.
With people, a lot of management happens implicitly and has to do with managing people’s emotions, conflicts, relations, etc.
With AI agents, all the “people stuff” goes away, and much more emphasis is devoted to “designing the machine that builds the machine”.
I have led both people (as a GM and CEO) and machines (as a software engineer) and I can tell you that these are like day and night.
But why do people confuse managing people and managing AI agents?
AI and people management are similar only on the surface
Imagine you delegate something to an employee.
You explain what you want them to achieve, give them the information they need, clarify what needs approval, define a timeline etc. Once the job is done, you’ll assess the output and eventually, their performance in the long run.
In broad strokes, that’s similar to working with an AI agent. With a human employee, you would roughly think of this as:
- What outcome do I want?
- What context does the agent need?
- What tools does it need access to?
- What is it allowed to do?
- When should it escalate to a human?
- By when do I need this output?
- How good is the output?
In AI engineering, each step is simply an engineering problem (context, tool access and policies, escalation gates, output evaluations, system improvement).
In dealing with humans, you can’t really engineer any of this. The alternative is to have a meeting to talk about it and review stuff.
You can’t delegate to AI and have a meeting with it to see how things are going. In fact, you don’t need that anymore. Once you’ve asked an AI to do something, it’ll come back with the output within seconds, hours, or maybe days (depending on the task).
That’s why the analogy between “people management” and “AI agent management” breaks quickly.
In practice, here’s what differs.
Managing AI agents requires working both on and in the job
Managing AI has to do with designing systems and supervising their ever evolving nature. In that sense, it looks more like engineering than people management.
AI agents should only be allowed to do things within a certain scope, based on fairly well known processes and procedures (e.g., the workflow SOPs). In other words, most AI workflows in companies are actually fairly programmatic, and include a few AI steps in them.
At the same time, SOPs evolve, AI capabilities improve and by using systems, people start to figure out how to improve them further. Unlike with people, once we spot an improvement for an AI system, it can be engineered quickly.
In that sense, employees who increasingly use AI systems will have to get familiar with doing their day-to-day job (working in the job) while at the same time thinking of how to improve the system so it helps them better (working on the job).
People management has some of that too (when I was GM, I definitely had to design the process and team structures to deliver a certain performance, e.g. working on the job), but it becomes something everyone has to do with AI (e.g. not just the GM or higher ups).
Does everyone need to become an AI engineer then?
Of course not. The person proposing the changes doesn’t have to be (and generally is not) the person who will implement those changes. But she is definitely the best person to suggest them, because she is the front-line user of the system anyway.
One skill that the person using AI outputs must become fluent at is reviewing AI outputs.
The new skill of reviewing AI outputs
Not every task and workflow done by AI will have an automated eval set to auto-validate outputs. Thus, one has to know how to review these things, and design the output format in a way that is effective and efficient at the same time (going back to the idea of working on the job).
Again, this is very different from reviewing human outputs.
With humans, we can get someone to present us their work and talk through it. It is very inefficient but we’re used to it.
With AI, one has to read the AI “report”. Perhaps some day we will have an AI presenting to us its findings too. But this will only shift the burden of verifying that it has presented its findings accurately. After all, AI doesn’t fear being fired and doesn’t care if you stop using it.
And because AI is very good at producing an awful lot of content, it is important to design the review output as to be human-friendly, with full sourcing / citation / explanation so that humans can actually trust it.
Because AI will have no problem inventing things out of the blue (if the AI system is poorly designed), it is important to have a very high bar for bullshit, especially when the system has not gone through a lot of human reviews in production yet (staging environments are always “easier”).
Which means the “AI operator” must be extremely good at:
- Critical thinking: to question the right thing AI produces (but not everything, all the time)
- Domain expertise: to put things in their proper context and apply the right judgment
- Time management: one has to learn to schedule one’s work around AI speed, not human speed
- System thinking: be able to switch from “working in the job” to “working on the job” and design the system, not just use the system
Notice that no people skills made the list. It is somehow logical: in managing machine intelligence, you are managing a machine, not a human.
But I also predict that companies will be slow in changing their org chart / org design around AI, for many reasons.
This brings us to the next topic: how to think of Org Design in an post-AI era?
Should your AI org design be a replica of your org chart?
The short answer is you may end up with an AI Org Design (OD) that looks like your human org chart, but the thinking process to get there should not start with your human org chart.
Here is why, in a nutshell.
Before AI, companies had to organize around accountability areas, management span and specializations. In other words, who’s to credit/blame? How many people can they manage? And what specialized skills do they need to hire for?
Think of enterprise sales for example. Teams are organized around SDR/BDR teams (accountable for developing potential accounts), AE team (accountable for closing and managing these opportunities) and sales managers or equivalent (managing the whole thing).
Software used to be the same: product and analyst teams (accountable for specs) > dev teams (turning specs into code) > QAs (testing code) > release / engineering manager (managing the whole thing).
There are more nuances to that but you get the idea. Here is the big difference though.
Therefore, it follows that you could theoretically replicate your human org chart with an AI agent org chat (in our previous example: having an AI SDR, AI AE and a manager, or AI analyst, AI coder, AI QA and an engineering manager).
But because you would not have a real reason to organize AI teams that way (other than just copy pasting your org chart into an AI org chart), it would be suboptimal (too many hand-offs between agents for no reason).
What’s better is to think of “Job To Be Done” (JTBD), to borrow from Clayton Christensen’s work1 on innovation and strategy, where you start with “what’s the outcome I want to achieve” and engineer the workflow backwards, one step at a time.
Start with the JTBD, then workflows, but do not start with not departments
Taking our previous simplified example of sales, you might currently have:
SDR → BDR → Account Executive → Sales Manager → other higher ups
The workflow view would actually looks more like:
- identify potential accounts;
- research the company and people;
- decide whether the account is worth pursuing;
- prepare and send outreach materials;
- handle responses;
- understand the customer’s needs;
- develop an opportunity and follow-up;
- prepare a proposal;
- negotiate;
- close.
In JTBD terminology, it would simply look like this:
- Find and qualify the opportunities worth pursuing (“accounts”)
- Turn accounts into a real buying opportunities
- Turn opportunities into a commercial agreement that works for both sides.
Everything else is merely considered an activity (doing research, connecting on LinkedIn, setting up a meeting, doing follow up, handling objections, negotiating the terms etc.).
The boundaries are almost JTBD #1 for SDRs, JTBD #2 for BDRs and #3 for AEs. So it is tempting to just say “Well let’s just have our people use AI in their departments to do more”.
But here is a possible AI-first design you could consider instead, as opposed to retrofitting AI into the org chart
- AI agent team 1: build lists of accounts, produce a research memo for each, assign a score to each based on sales criteria, draft first versions of outreach materials that could be sent.
- Humans: review key outputs from AI agent team 1, and decide what’s worth pursuing / sending or need changes. Edit drafts and validate final versions. Delegate the actual sending to the AI team once materials are final.
- AI agent team 2: monitor for responses, automate follow-up, record steps done and status in CRM, until a positive answer is reached and a hand-off to humans is made.
- Humans: handle the accounts who want to have a meeting, take the meeting and do the needed discovery / further qualification. The team uses AI transcripts if prospects are OK with it as to make note taking ambient and help further qualification later. Post meeting the team has a sense of how qualified the account is
- AI agent team 3: upon human request, draft several sales gameplan to follow-up on the meeting with the chosen accounts. Humans choose / amend gameplans and asks AI agents to run one per account. AI team does the follow-up as AI agent team 2 did
- Humans: takes over from AI on the “hottest” accounts to have follow up meetings. Further qualification / proposal / documentation can be done using various AI tools (rather than a specialized AI team). Final steps are key and mostly ran by humans until deal closure
Note that “AI agent team” is to be taken loosely. Technically, individual agents perform well-bounded atomic tasks and coordinate with each other, hence a “team”, responsible for defined outputs.
Under this arrangement where AI does most of the legwork, the question regarding humans is this.
For example, step #2 is human and doesn’t require a very high degree of specialization. In fact, it would be beneficial to have the same person do step #2 and step #4 as to have continuity across accounts, and not split it just because the company currently has SDRs (could do step #2) and BDRs (could do step #4, but arguably also step #2).
As for step #6, is the sales complex enough to separate that human role completely from the previous one? And is the volume of deals also large enough to justify such a split?
Each company will have its own answer to these questions.
The point being that re-engineering the flow of work around AI should trigger these Org Design questions, for which the answer is not automatically “let’s keep our current org chart and retrofit AI in these teams”.
This is a process design challenge that is old, and has already been solved many times over in various situations. The electricity (another “general purpose technology”) shows the patterns clearly.
Some factory owners decided to plug electricity on their old steam-engine-powered machines to get some productivity gains, while others decided to redesign the factory floors around smaller individual electric engines. The latter outperformed the former, not because engines worked better with electricity, but because the new factory floor design enabled a lot more things to be produced at a lower cost.
With AI, it is quite similar: AI changes the economics of reasoning and specialization.
And beyond Org Design, it may also mean changing the entire way business is conducted. Let me give you a concrete example.
AI can create more human bottlenecks
Around Aug 2025 I took on an AI advisory role for an investment fund in Singapore. The main question they wanted to solve was “How can we double the fund size without doubling analyst headcount?” and asked me to recommend solutions.
Their business process was roughly organized as follows:
- A team hunts for seasoned founders to start a new company
- Venture analysts do a bunch of Due Diligence research (tech DD, commercial DD, etc.) in the industry where the founder builds the company
- The investment team, analysts and founders debate back and forth the various opportunities, tweaking them as they go and triggering new DD angles
- Only a few opportunities make it through the sieve. Eventually once an opportunity is considered the highest potential, is goes through a formal Investment Committee (IC)
- If it passes IC, the startup is funded and the founder is off the races.
In business process re-engineering, their problem was a typical “limiting factor” problem. In the above flow, step #2 (Due Diligence) was the limiting factor (e.g., an analyst can only produce so much, while there might be 10x more opportunities to sift through).
At that time (Aug 2025), Agentic / Autonomous AI was still in its infancy. Concepts like OpenClaw were still 6 months away and the industry was still grappling with the possibilities offered by mere raw AI intelligence.
So I proposed to run a POC (Proof Of Concept) to build teams of AI agents, who would do the legwork of analysts, so they could focus on doing even more stakeholder interviews and also stay focused on making decisions (instead of producing and reading notes).
Within a few months, the POC showed that the same team could sift through 25% more opportunities, while making quality more consistent across the board. But it also showed that productivity gains would then plateau, because there are only so many cases the analysts could actually review, hence creating a new bottleneck.
Based on this, we engaged in a much larger business process transformation discussion, where it became clear that an AI-first investment fund would have to be organized differently, and where designing the right “decision gates” (e.g., where to HITL, HOTL and HOOTL) was the key.
It also brought a new challenge: how do you run part of the company on an old model while exploring the new model, all at once?
But that’s a different story that goes well beyond Org Design (OD) that deserves its own essay.
Circling back to the initial question “Should your AI OD replicate your org chart?”, the answer is that it needs to be reframed into “What are the JTBD and workflows we need?” and design the org from there.
This will help you avoid the trap of optimizing locally (the team has AI tools, therefore we should get productivity gains) and shoot for end-to-end improvements in output and margins instead.
What does an AI engineer actually do?
To simplify, separate AI engineering into three broad categories:
- People who build AI models. This is a bucket you will rarely need to care about (unless you’re a frontier AI lab)
- People who fine tune existing AI models. Enterprises may need these folks, as well as AI product companies. Most other companies don’t.
- People who build software that has AI in it. This is what I’ll talk about here, as this is the profile most companies will need when they think “I need to hire AI engineers”
1. Engineers who build AI models
These are typically AI researchers / engineers and other specialists who build, train and improve the models everyone is using.
Think of the engineering teams at OpenAI, Anthropic, Google. Mistral etc.
Unless you’re in the business of building AI models, you probably don’t need (and cannot afford) these people.
2. Engineers who adapt or fine-tune AI models
These engineers take an existing model and adapt it to perform better on particular tasks.
Fine-tuning, strictly speaking, means further training an existing model to modify its weights (see my earlier explanation of model weights).
For example, you might fine-tune a smaller model to classify particular types of technical documents or to produce outputs in a very specific format, using an Open Weight model instead of a US frontier lab model (OpenAI, Claude, etc.).
As explained earlier in this guide, you generally don’t need to train AI on your company’s data just to make it useful for your business.
However, if you do decide to go down the route of fine tuning, you’d expect to hire for the following skills.
- Machine Learning & Data engineering fundamentals
- Fine tuning methods such as LORA/QLORA (depending on the use case)
- Experience working with GPUs, PyTorch
- Running training pipelines, model evaluations and model deployment
The only reason I put it here despite the jargon is because I see lots of recruiters list these things while what they are advertising for is actually for the 3rd category of AI engineers, not the fine-tuning type of AI engineers.
3. Engineers who build AI solutions
This is the category we’re interested in: the broader category of people who build solutions around other AI models. We have already discussed the “demo vs production trap”, so I won’t repeat that here.
An imperfect analogy to quickly grasp the nuances of AI engineering is making a car.
The frontier lab AI engineers build the engine. The engineers who fine tune are kind of tuning these engines for specific races. And the final AI engineers are designing and building the actual car that makes use of the engines.
Most companies need the car, not just the engine.
Let’s now talk about the details of AI engineering in the sense of building AI solutions. I will refer to “AI engineering” here as that type, not the first nor second types.
AI engineering is still software engineering
Since AI is now writing most of the code, AI engineers actually don’t write code (or very little). So the non-technical person may ask “Well then, what am I paying you to do?”.
As with software engineering, you are paying that person to solve a problem, using software. AI has become both a tool of the trade (to produce the code) and a part of the solution (embedded in the final software).
But AI engineering is no more magic than software engineering. In fact, it “just” follows software architecture and engineering principles, and adds a few new ones on top of that.
For the non-tech CxO, there are only a handful of new things you need to know about AI engineering.
Most have already been covered in other parts, but let’s summarize them here for completeness. They are:
- Context engineering: deciding which instructions, documents, historical information and other data the model needs to perform its task. This didn’t exist at all in traditional software engineering.
- Tool access and system integration: connecting AI to tools via MCPs, and integrating up/downstream via APIs. MCPs are a sort of “API for AI agents to access tools”, and APIs are not new to AI engineering.
- Workflow orchestration: this is the meat of the AI solution. It decides what AI do, how, when, with what model, etc. It also encapsulates HITL/HOTL gates and all the traces required to know what’s going on as AI does the work (so that it doesn’t become a black box). Principles are not new, but the challenges introduced by non-deterministic AI intelligence are new.
- Evaluations (evals): a programmatic and systematic way to assess AI outputs based on a set of criteria (set by your internal subject matter experts, in general). Also not totally new, but evaluating non-deterministic outputs is new.
- Execution controls: defining permissions, limits, error handling and what happens when something blows up. This is not new per-se, but more important with AI engineering.
- The AI harness: the machinery surrounding AI models that the solution is using. In a sense it’s the “box” that contains “all of the above”
So when hiring, one could simply think about this as follows.
Building the right harness requires more detailed skills (solution architecture, experience with cloud deployment, working with AI coding agents, etc.) but at the end of the day, what you get is a harness that produces some output that your organization needs.
How AI engineers work with AI coding agents and other AI engineers is another topic. There are 2 big differences with traditional software engineering that you need to know:
- How software is built: namely, mostly by AI coding agents, but based on human-based architecture and choices
- How software should be operationalized: using a forward-deployed model
Operationally, #2 matters more so let’s dive into that.
Think forward-deployment, not traditional software delivery
In traditional software delivery, you get something like this.
Business users explain what they need → analysts document the requirements → engineers build the software → QAs test and validate it → someone validates the release to production → communication and training plan goes out to operations → a training / operational team train users with support of some technical folks → users finally start using the system.
Agile iterations will make these traditional “Software Development Life Cycle (SDLC)” as short as practical, but at the end of the day, the same process happens.
With AI, we introduce 2 new things.
- AI compresses much of the work in the SDLC. Notably: requirement analysis, translating that into engineering lingo, writing code and testing can be mostly handled by AI. Therefore, the cycle can be much faster and closer to the end user
- AI is non-deterministic. The harness around it may be deterministic, but AI outputs will vary. Therefore, testing and improving in an environment as close to real as possible is key
A model that has gained traction to tackle these 2 opportunities is the Forward Deployed model.
With AI, there isn’t a reason to have yet another human sit between the end user and the engineer anymore.
In large deployment, another role called the Deployment Strategist will actually interface with the users. S/he generally has an AI engineering background and is more senior, and will “buffer” with a less experienced AI engineering team. But the principle is the same: get the user as close to the delivery unity as possible.
The benefits of the FD model includes:
- Much tighter feedback loop with real operations, therefore much higher “fit” between problem and solution
- Very fast iteration loops
- Higher degree of involvement from end users, leading to higher buy-in in the final solution
- Opportunity to identify AI champions early and get them to train operations as they become the power users
When I was advising this investment fund on their AI solution, that’s exactly how I worked: I was forward-deployed inside the investment team, joining their investment meeting while building the solution on the fly and getting them to use new versions every week.
That resulted in all the benefits listed above. That’s why you will hear “deployed in 3 months” types of claims from vendors. It is actually possible to do it, but only if one adopts the right delivery model.
This also means your operational team will have to set some amount of bandwidth to work side-by-side with Deployment Strategists or FDEs. Eventually it will be more efficient as a whole, but it may feel like “more work” at the individual level. Hence, communicate that early and clearly, shall you engage in such a thing.
So, circling back to the original question: what does an AI engineer actually do?
You do not need to hire for GPU understanding, model training, machine learning, fine-tuning etc. What you do need to hire for is someone who can build and deploy an AI harness, with all the components we discussed so far.
And ideally, s/he should be able to work in a forward-deployed manner inside your operations, so you can leverage the full potential of AI.
Do you need a CAIO?
I am not an expert in Org Design, but my personal view is that most companies probably don’t need a Chief AI Officer (CAIO).
Unless AI has become such a strategic priority that it requires its own executive mandate, dedicated teams, budget and governance structure, AI should probably sit under the CIO.
What would a CAIO be in charge of anyway? I think the role would usually combine:
- AI portfolio management: once the company has enough AI initiatives, internal and external, they become a portfolio that needs to be prioritized, funded, coordinated and sometimes killed
- AI governance: defining how AI should be controlled, audited and used across the company, and be the interface with regulators
- AI strategy: defining AI ROI, buy vs build, strategic use case VS nice-to-have, identify the role of AI in long term differentiation
- AI investment: planning and managing the CAPEX and OPEX associated with AI (infra, token costs, vendors, engineering teams, etc.)
- AI literacy and capability building: deciding how the workforce should be reskilled or upskilled
Therefore, the CAIO may very well be a transitional role. As AI becomes a normal part of how technology and business operations are managed, many of these responsibilities may simply fold back into the CIO (or CTO / CDO, depending on the org).
So what to make of the many companies recruiting CAIO currently? It is perhaps not surprising that they are mostly banks or in regulated industries. In these environments, regulatory scrutiny and AI compliance or risks seem to justify a dedicated executive focus.