How to prepare a work process for an AI agent: ten checks

The company has rolled out ChatGPT and Copilot, automated a couple of reports and set up a chatbot. Yet the work runs as before: a person receives a task, gathers the context themselves, moves data from one system to another, makes the intermediate decisions and passes the result on. AI speeds up individual employees, but the way the company works does not change.

Handing a real process to an agent takes more than a good prompt. Departments stay, but the work starts to move along a path that people, agents and services travel together. The task needs a defined result, an owner, context, permissions, a check and stop conditions. Below are ten checks that help you find the gaps before you hand a process to an agent. They are based on Sergey Pimenov's model of the "ten loops of an AI company". It is a working model for diagnosis, not an industry or scientific standard.

Why a list of traits is not enough

The model grew out of a discussion of a list of 30 traits of a company built around AI: a process map, corporate knowledge, routing between models, agentic development, financial forecasting, quality evaluation, access control, gradually expanding autonomy.

The discussion was a limited sample: a thread on X ranks the replies, and some of the comments are marked as AI-assisted.

But the main point is clear anyway: the list puts things of different levels side by side — technologies, management principles, metrics, scenarios, security requirements, cultural attitudes and hypotheses about the future.

For example, corporate knowledge belongs to architecture, the principle "every employee becomes a builder" belongs to culture, the cost of an accepted code change is a metric, and a swarm of advertising agents is a scenario.

Without the links between them, it is easy to go wrong. You can generate thousands of ad variants that have nothing to do with sales. You can build search without agreeing who counts as an "active customer". You can give employees agents without deciding who is responsible for their mistakes. That is why it is more useful to group the traits into ten linked checks — one for each side of the process.

1. Result: what should change

Work starts with a change for the customer or the business. A result has a recipient, an owner, acceptance criteria, a baseline, an expected effect and a condition under which the experiment is stopped. Without this, an agent will quickly produce a lot of things nobody needs. The unit of work is an accepted result: a published piece, a resolved request, a verified code change, an agreed contract.

Question to check: what result for the business or the customer does the process owner accept?

2. Path: how the task actually moves

Reconstruct the real path: where the task comes from, what data is used, what decisions are made, where exceptions occur, who receives the result and what counts as done. Buying a tool before examining the process often means speeding up the existing mess. At the same time, the agent itself can help uncover the real hand-offs, exceptions and hidden manual coordination.

Question: can we trace one real task from intake to an accepted result?

3. Context: what the agent knows and where from

The agent needs to understand which version of a document is current, what each term means, where the information came from, who may change it, why an earlier decision was made, when knowledge goes out of date and how to correct or remove wrong information. If two departments understand "active customer" differently, the agent will consistently reproduce that contradiction.

Anthropic calls this context engineering: managing everything the model sees — instructions, tools, history and external data. For long tasks, selecting and compressing context, structured notes and durable working documents all help.

Question: can we explain the origin, meaning, owner and lifespan of the knowledge the agent relies on?

4. Execution: can the process be repeated

A good prompt on its own does not make a process repeatable. Write down what needs to be done, which tools may be used, where to take data from, when the task is complete, in what form to hand over the result and what to tell the next person or agent about how the work went. This role is played by the agent's execution environment — the thing that ties together the model, tools, instructions, constraints and checks.

OpenAI describes an agent as a system that runs a workflow, uses tools within set limits, knows when the work is complete and, when necessary, hands control back to a human.

Question: could another agent or person repeat the process from the saved description without piecing everything together from message threads?

5. Access: what the agent is allowed to do

An employee's permissions are usually broader than an agent needs, and giving the agent a person's full access is an unnecessary risk. It is safer to have:

• a separate account for the agent;
• time-limited permissions;
• access only to the data of the specific task;
• permission for specific actions;
• separate rights for preparation, execution, review and publication.

If the agent will work with customer data, a company in the EU separately checks the GDPR requirements for that processing.

OWASP recommends the principle of least privilege for agents, checking permissions on every request, minimal rights for connections to external systems, and an operations log.

Question: can we say exactly what this agent run is allowed to read, change and send?

6. Accountability: who is responsible for the outcome

An agentic process has at least four roles: the result owner, the process owner, the executing agent and the reviewer. One person can hold several roles, but the roles must not disappear. The agent does the work, while organisational and legal responsibility stays with the people who set the goal, granted the permissions and accepted the result.

What this looks like in practice. In an editorial team where agents help with research, structure, text, illustrations and the technical side of the website, a piece goes through separate states:

1. Idea.
2. Research.
3. Structure.
4. Full text.
5. Review.
6. Confirmation of the write.
7. Draft in Notion.
8. Publication decision.
9. Check of the published result on the website.

The agent prepares the piece, but the decision to release the text stays with a person. Saving a draft and publishing are different actions, and each transition requires a separate decision and a verifiable result.

Question: who is responsible if the agent followed the instruction exactly but the company got the wrong result?

7. Observability: can the course of the work be reconstructed

Saving the final answer is not enough. Reconstruct the course of the work from the log:

• the task and the context used;
• the model, the tools called and the actions taken;
• errors;
• who reviewed and who accepted the result.

A correct outcome does not yet prove that the process is safe and economical: the agent may have reached the answer by chance or taken unnecessary steps. Anthropic advises evaluating both the final state and the agent's path — tool calls and intermediate steps — and starting quality evaluation with clear success criteria.

Question: can we explain not only what the agent did, but also why the result was accepted?

8. Resilience: what happens when something fails

A process cannot be considered working if nobody knows what happens when it fails. Before launch, define:

• where the agent must stop;
• how many retries are allowed and how long it may wait for a response;
• when the task passes to a human;
• how the safe manual mode works;
• how to roll back changes and restore the last verified version of the context.

If the failure was caused by a wrong rule, an outdated instruction or corrupted context, restore the last verified configuration in full: instructions, data, tools, routing and permissions.

Question: what happens if the agent stops in the middle of the process or starts making wrong decisions again and again?

9. Economics: what an accepted result costs

The main measure is the cost of an accepted result. Alongside it, look at the share of rework, the cost of human review, the time from setting the task to acceptance, the cost of an error and recovery, and the impact on revenue, margin or throughput. An example of such a metric in software development is the cost of an accepted code change: generated code becomes a result only after it is reviewed and accepted. A piece of content, a report, a contract or a customer request is assessed the same way.

Question: which business metric will change if the process with the agent really works?

10. People: which decision stays with humans

Define exactly what stays with a person and why. A person chooses the goal and is responsible for the consequences. Their involvement is especially important in decisions about money, access and irreversible actions. Ethics, relationships between people, taste and an authorial position need particular attention, as do exceptions that are not yet in the data. Someone has to "sign off on taste" — decide which options match the company's voice. And a person keeps the right to refuse automation: sometimes a process first needs to be removed, simplified or rethought.

Question: which decision in this process must a person keep for themselves, and why?

How mature the process is: five levels

Each of the ten checks can be rated on five levels:

• level 0 — this side of the process is not described at all;
• level 1, personal — individual employees solve tasks with their own tools;
• level 2, repeatable — there is a process, instructions and a mandatory check;
• level 3, managed — there is an owner, permissions, an action log, quality evaluation, stop points and rollback;
• level 4, adaptive — the process improves on data from its own runs and gains autonomy earned through results.

An overall score says little here: an average hides imbalances. Advanced execution without accountability, access control or rollback remains unmanaged. The scale is a working hypothesis for diagnosis, not a scientifically validated rating.

A quick diagnosis of one process

Choose one process where AI is already used. Go through the ten questions above and mark which answers are confirmed by observation and which still need checking.

If you can answer confidently only the questions about tools and execution, the company has started using AI but has not yet changed how the work is organised.

You can examine the process together with AI. Describe the path from an incoming request to a result accepted by a specific person, and use this prompt:

Examine one of my processes against ten checks of readiness for an AI agent.
Use only the data below. Do not implement anything and do not assume
that you have access to the company. Treat unfilled fields in square
brackets as missing data.

Process: [start, main steps and final result]
Who accepts the result and by what criteria: [person, criteria]
Roles and decisions: [who performs the steps, who authorises actions]
Where the status is recorded: [system or document, one example]
Known failures, constraints and costs: [observations or "don't know"]

First check the inputs. An empty field and "don't know" mean missing
data. If the process boundaries or acceptance criteria are unclear, or
the inputs contradict each other, ask up to three essential questions and stop until I answer.

Return a table for the ten checks: result and purpose; processes
and tasks; context and organisational memory; execution;
identity and access; accountability; observability and quality;
resilience and rollback; economics; human involvement. In each row: what is known, an excerpt
from the inputs, what we don't know and one manual check. Do not infer
absence from a lack of information and do not give an overall score.

Choose one proven gap that prevents the result from being accepted,
and explain your choice. If there are no grounds for one, say so. Finish with a list
of what I need to confirm. Do not present proposed checks
as checks that have been carried out.

You will get a map of one process: what is known, what is missing and which check to do first. Compare each row with the process description: the model must not assign levels to unknown areas or invent a result owner. Such an analysis helps you find the question to check. It does not confirm the state of the whole company and does not replace observing the real work.

The main sign of readiness

When preparing a process for an agent, check whether you can hand it over in full while keeping the meaning of the result, the owner, current context, limited permissions, observability, review, resilience, measurable economics and a person's right to stop the system. A working process can be expanded and connected to neighbouring ones — this is how AI gradually becomes part of how the company works.

Read next: examine your working day before building an AI agent and how to hand over a task without everything staying in the manager's head.

If you want to examine your own process against these checks, you can do it together with Simplit in a free 30-minute meeting. Discuss your task

Primary sources: Alex Lieberman — 30 features of an AI-native company; OpenAI — A practical guide to building AI agents; Anthropic — Effective context engineering for AI agents; Anthropic — Demystifying evals for AI agents; OWASP Cornucopia — Agentic AI AAI6.