---
title: "Human in the Loop: how to transform a job with AI"
description: A visual guide to sharing tasks among people, agents and tools,
  preserving expert judgement and testing the results through a proof of
  concept.
author:
  name: Walter Jerusalinsky
  title: AI strategy and implementation
  url: https://www.linkedin.com/in/walter-jerusalinsky/
date: 2026-11-12
canonical: https://www.idoneos.com/en/articles/human-in-the-loop-transforming-a-job-with-ai/
image: assets/01-tareas.png
source: articles/human-in-the-loop-transforming-a-job-with-ai/index.md
---

When we think about applying AI to a job, it helps to look closely at what the person does: what they observe, what they connect, how they decide and what they need to act on. From there, we can imagine a different way of organising the work, combining human capabilities and tools.



## A job consists of many tasks and decisions

Let us observe someone at work. They look for information, interpret what they find, prepare something, check whether it is right and decide what to do next. What we call a job brings together many small, related tasks and decisions.



![A person at the centre connects to icons for finding information, preparing, communicating and recording. Two diamonds represent decisions: what to do and whether the result is right. The drawing separates the components of the work rather than showing a sequence of steps.](<assets/01-tareas.svg>)

The same person performs tasks and makes decisions. The drawing breaks down their work; it does not establish a single sequence.





We usually recognise a job by its name or by the outcome we expect from it. Yet to understand how that work is done, we need to distinguish the actions that make it up. What does the person receive? What information do they seek? What leads them to choose one path and discard another?

Some actions transform information; others produce something in the physical world. Decisions connect what we know with what should happen next. Breaking down that set of activities helps us recognise where each capability contributes and what we need to preserve when reorganising the work.







## What capabilities does each part of the work require?

Once we distinguish the tasks, we can ask how to carry them out. Some follow known rules; others require recognising patterns or interpreting language. And some still need a person's judgement, experience or ability to act.



![Four icons distinguish software rules, machine learning, generative AI and a person's capabilities. Each connects to a function: compare, recognise, interpret, or decide and act.](<assets/02-herramientas.svg>)

Work brings together different capabilities. We choose the tool after understanding what needs to be resolved.





Comparing two quantities may require no more than a conventional application. Recognising a pattern may justify machine learning; interpreting a request or preparing an explanation may benefit from generative AI. The choice starts with understanding what transformation is needed and what information is available.

The ability to carry out a task also depends on conditions. A tool may work well with complete data and need help when a reference is missing. Alongside allocating tasks, we therefore need to recognise when each part can proceed and when someone else must intervene.







## We can organise those capabilities in a loop

Now imagine that the agent proceeds until it encounters something requiring human involvement. It hands over what it has gathered; the person decides or acts and returns a result. With that information, the process can continue. This is how shared work takes shape.



![An agent, represented by a chip with a gear, connects to a person. The outward path carries a proposal and context; the return carries a decision or result. The process continues with that contribution.](<assets/03-bucle.svg>)

The person receives context and returns a decision or result that changes the course of the process.





We call this human involvement within an automated process Human in the Loop. The expression becomes meaningful when we can identify where a person is needed, what they receive and what they must return for the work to continue.

The agent uses a model and tools to look up information or carry out actions. The person contributes the capability that this part of the process requires. For the exchange to work, both must meet around a comprehensible task: what remains unresolved, what makes it possible to resolve it and what changes with the response.







## AI can prepare what the expert needs to review

There are tasks that AI can carry out even though we still need to check the result. It can prepare an analysis or a reply and gather its references. The expert examines that proposal and decides whether to approve it, correct it or investigate further.



![An agent prepares a document with references. An expert reviews it with a magnifying glass and chooses among approval, correction or further investigation, represented by a check mark, pencil and magnifying glass.](<assets/04-revision.svg>)

The expert can approve, correct or request further investigation. Their judgement determines how the work continues.





Consider a reply that requires expert knowledge. The agent can find information, connect it and prepare a draft. The person's work changes: they receive a proposal accompanied by the material needed to understand it and judge whether it addresses the issue.

For that review to have value, it must be able to change what happens next. If an action requires approval, it waits for the decision. A correction returns to the process; uncertainty may call for another enquiry. Keeping a record of those interventions allows us to review how the system works, although the model does not automatically learn merely from receiving them.







## Other tasks require acting on the physical world

We can ask AI to indicate where a box should go, but someone has to move it. The same applies to attaching a label. The person performs the action, and the system can help check it using the signals available to it.



![A person moves a box towards shelving. A system indicates the location and receives a scan or photograph. The evidence is checked; if it is insufficient, human review is requested.](<assets/05-accion-fisica.svg>)

The warehouse illustrates this particular case: a person acts, and the system checks the available evidence.





Here we encounter a human capability different from expert judgement: acting on material objects and situations. In a warehouse, for example, the agent can indicate a location and the worker can move the item, record the result or report what prevented them from doing so.

We then need to understand what the system can verify. A scanned code confirms that a label was read; on its own, it does not prove where the box ended up. A photograph may provide another signal. We design the check around what we need to observe and turn to a person when the evidence is insufficient.







## One person can contribute to the work of several agents

What happens if agents only need help occasionally? The same person could handle exceptions from several processes. To work out how many, we need to observe how often they request intervention and how much work each case takes to resolve.



![Three agents send exceptional cases to a queue. A person reviews them and returns each decision to its originating process. A clock indicates that the frequency and duration of reviews determine the workload.](<assets/06-una-persona.svg>)

The number of concurrent processes depends on the human attention their cases require, including cases that arrive together.





If most cases can proceed within the expected conditions, human involvement concentrates on matters that need additional judgement. Rather than resolving every case from beginning to end, the person can attend to situations arriving from several executions.

That possibility depends on a concrete relationship: how much attention is requested and how much the reviewer can provide. It also matters whether enquiries can wait and whether they arrive simultaneously. A visible queue, with owners and priorities, helps organise that workload and recognise when more help is needed.







## One agent can also work with several people

We can imagine the reverse relationship. An agent prepares work very quickly, but each result needs human involvement. It can then assign tasks to several people according to their capabilities and availability, and gather what each returns.



![An agent prepares a task queue and assigns work to three people. The icons distinguish reviewing, supplying missing information and acting. Results and obstacles return to the process.](<assets/07-varias-personas.svg>)

The agent prepares and coordinates; each person makes a contribution and returns its result.





The agent can gather information, prepare cases and maintain their state while different people contribute what is needed: a review, a missing piece of information or an action. This combines the system's speed of preparation with the team's capabilities.

Preparing a task and being able to perform it are different capabilities, however. If the system generates more work than people can handle, the backlog grows. Organising assignments, allowing obstacles to be reported and limiting how much work is started are all part of the same design.







## Those exchanges can form networks of work

So far, we have imagined simple relationships. We can go further: several people and agents contributing different capabilities, consulting one another and passing on results. To understand that network, we need to follow each case: what is resolved, what remains and who needs to contribute.



![A network of two people and two agents exchanges tasks, enquiries and results. The state and owner of each case are maintained at the centre.](<assets/08-red.svg>)

The network combines people and agents. Its connections show what each part needs from the others.





A person can request an analysis, an agent can consult another tool, and an expert can resolve a question before the process continues. These exchanges connect because the result of one task provides what the next one needs.

The network remains meaningful when we can reconstruct those relationships. Each case needs to retain its identity, its state and responsibility for the next step. We can start with a small exchange and connect others once we understand what they contribute and how to check their results.







## It all starts with understanding how the work is done

To design those exchanges, we need to return to the person who knows the work. An interview about a real case allows us to ask what they did, what information they recognised and why they decided as they did. The recording preserves an explanation we can revisit.



![An expert explains their work to an interviewer, and a recorder preserves the audio. AI organises tasks, data, criteria and exceptions. An arrow returns the interpretation to the expert for validation.](<assets/09-conocimiento.svg>)

We listen, organise and interpret; then we return to the expert to check what we understood.





When someone says “it depends” or “you can tell straight away,” there is something worth understanding. What does it depend on? What detail are they recognising? We can reconstruct a case, preserve the explanation and use AI to distinguish tasks, data, criteria and exceptions.

The interpretation we develop goes back to the expert: we need to check whether it expresses their judgement or whether we have connected something incorrectly. These iterations help us reach sufficient understanding for our purpose. What someone usually does still needs to be discussed before it becomes a rule in the system.

[How to capture expert knowledge with audio and AI](https://www.idoneos.com/en/articles/capturing-expert-knowledge-with-audio-and-ai/)







## A small test lets us check our interpretation

With that understanding, we can choose a task and try out the exchange. Does the agent receive what it needs? Can the person resolve what they are asked? We test routine situations and exceptions to check whether the loop produces the result we want.



![A flask identifies a test of a single task. Four icons represent a routine case, missing information, uncertainty and a delayed human response. The result is compared with the current way of working.](<assets/10-prueba.svg>)

The test checks our interpretation against concrete cases and criteria agreed in advance.





A proof of concept turns our interpretation of the work into something observable. We choose a limited scope and agree on what would need to happen for us to consider it successful. We then try cases comparable to those in the current process.

We include a routine situation, missing information, an uncertain case and an intervention that does not arrive in time. We measure quality, total time, review workload and cost. This lets us distinguish which parts of the design work, what we misunderstood and what needs adjusting before we expand its scope.







## What we want to improve is the work as a whole

The agent's speed is only part of the result. What a person waits for, the time they need to understand an enquiry and the corrections they must make also count. Improvement emerges when those parts work together to produce a useful result.



![A clock accompanies the path through agent processing, waiting, human review and correction. A final check mark represents a useful result. The diagram has no numerical scale.](<assets/11-medicion.svg>)

We observe the time and effort of the whole process to identify what capacity becomes available.





A faster step can pass the difficulty on to the next one. We therefore need to measure the journey: from the start of a case until we obtain a result of the required quality. This helps us recognise whether we have freed capacity or merely moved the backlog elsewhere.

We then need to ask what we can do with that capacity. Handling cases that currently wait, improving a reply or doing more work are different possibilities. Financial savings depend on how the change can be put to use; they cannot be inferred solely from the time an AI takes.







## What we learn allows us to keep transforming the work

Working through this process gives us more than automation: we understand the work better and have tools to reorganise it. People take part in building that understanding. If the result justifies it, we can expand the loop and check what happens again.



![A person takes part in a cycle of understanding, testing, measuring and adjusting. A book and a gear represent the knowledge and tools available for further work.](<assets/12-evolucion.svg>)

Understanding, testing, measuring and adjusting leaves a foundation of knowledge and tools to build on.





The job changes as we redistribute its tasks and decisions. Some interventions are no longer needed; others require more judgement, knowledge or ability to act. The people who do the work need to participate in that design and be able to learn to use what is introduced.

The first test leaves knowledge, criteria and tools that we can reuse. On that basis, we decide the next step: adjust what still does not work, apply what we learned to another task or connect a new exchange. Each advance expands our possibilities from something we have already understood and been able to check.





## Further reading

[How to capture expert knowledge with audio and AI](https://www.idoneos.com/en/articles/capturing-expert-knowledge-with-audio-and-ai/)

The situations illustrated are hypothetical; they explain ways in which people and agents can collaborate.

<section class="next-step" aria-labelledby="first-test-contact">
  <p class="eyebrow">Next step</p>
  <h2 id="first-test-contact">Choose a task for a first test</h2>
  <p>We can start with a concrete case to understand how the work is done, recognise where human involvement is needed and choose what to test with AI. At Idoneos, we can help work through that process and define how to evaluate the result.</p>
  <div class="action-group"><a href="/en/contact/" role="button">Discuss a first test</a></div>
</section>
