Examine your working day first, then build an AI agent

A customer's request came in by message, the details were clarified over the phone, and the document stayed in an email. To carry on with the work, you have to piece the task together from several conversations. You would love an agent that remembers and keeps track of everything. But before building one, take one such case from request to result and answer a simple question: how does your working day actually go right now?

This kind of review will show where agreements get lost and why you have to rebuild the context the next day.

What lies behind the wish to automate everything

The person may know their job very well and already use AI: drafting documents, discussing ideas, preparing proposals, comparing options. But they keep the next step on each project in their head, because there is no clear order between the individual actions. Keeping that order takes constant attention.

Yet the phrase "I need an agent" says little about what should change. Perhaps the first step is learning to record agreements quickly. Or gathering one project's materials in one place. Or deciding where the latest accepted version of a document is kept. Or perhaps the process is already clear enough and genuinely ready for automation. You find out once a specific task appears behind the general wish.

One task shows more than a description of the ideal system

It is more useful to examine one specific example than to spend a long time discussing what the whole company will look like in a year. Say a request has come in from a customer. Go through what was in the first message, how you understood the desired result and what you had to clarify. Where those clarifications ended up, and at what point it became clear who was taking the task further.

Then follow the same task through to the result: where you used AI, what you checked yourself, who you handed the prepared materials to and why you had to come back to them. When a task is traced from the first contact to an accepted result, the real structure of the work emerges: who receives the information, who the next step depends on, where you have to go back for clarification. You can look at the company as a task graph — a network of steps and hand-offs between people — and start by describing one task, even if you are not planning to automate anything yet.

Along the way, you can see where attention really goes. Sometimes preparing a document takes a lot of time. Sometimes the document comes together quickly but is redone several times because nobody agreed on the result at the start. And sometimes the difficulty comes after the work is done: the outcome stayed in a chat, and a week later someone is searching for it or putting it together again. These situations call for different solutions, even though the original request sounds the same: "I want to automate work with AI."

Sometimes the capabilities you need are already at hand

A useful next step may lie in learning what is already available in ChatGPT or Codex, and in bringing order to your own work.

People come with different experience: some have already found a convenient way of working with documents, some are experimenting with agents and want to bring what they have found into the company, and some are only beginning to understand what it makes sense to discuss with a model at all.

That is why the advice "start using AI" is too general — you need to understand what the person already does and where their difficulty lies.

For example, after a conversation you can dictate the agreements by voice, ask the model to turn them into a clear record and check that nothing has been lost. Or describe the requirements for a recurring document once, so that the next conversation does not start with restating the same conditions.

For a large task that has not yet taken shape, a "brain dump" helps: first say everything you think about it, then ask the model to retell how it has understood it. After a few clarifications, you get a description you can work with.

Next to demonstrations of autonomous systems, such changes look modest. But you can test them on your next task and see whether things have become easier.

Complexity should answer a specific need

Simplicity is not a goal in itself. Some tasks really do need integrations, automatic information gathering, scheduled runs and several connected tools.

But every added layer of complexity needs a clear reason. If you connect email, you need to know which emails to process and what to do with the result. If you ask an agent to keep track of tasks, it has to be defined where it learns their status from. If the system prepares documents, you need a person who knows how to check them.

First walk this path on one example together with AI. Then you will see which actions repeat, where an existing tool is enough and what genuinely requires separate set-up.

This matters especially if a team will use the system: a manager's handy personal technique still has to be turned into clear work for others — explaining what they receive, what they must do and where to pass the result. Otherwise even a successful experiment will remain one person's personal tool.

What counts as a good outcome of the review

A good outcome is when it is clear what to try next and how to judge whether it helped. For example, take one stream of incoming requests and test a way of recording tasks. Gather one project's materials and see whether you can find the agreements you need. Go through the preparation of one document from request to accepted result, marking the places where manual work is still needed.

If the review shows that the process is ready for automation, you can move on to a limited pilot: choose the process, prepare the data, define the checks and compare the result with the previous way of working. After that, you have grounds for the next decisions — continuing the set-up, connecting new sources, handing part of the process to the team, or changing the approach if the idea did not work.

Examine one task before automating

Take a recent task that you remember from the first request to the result. Remove customer names and confidential information. You can dictate the story: where the request came from, what you did, who you handed the work to and how you knew it was finished. Then give AI this prompt:

Help me reconstruct how one of my recent tasks went and choose
a small way to make repeating it easier. Work only with the story
and materials I give you. If the episode itself is not there yet,
ask me to describe it from the first request to the result — this can be
free text or a voice transcript.

First assemble the sequence: what came in as input, what
decision was made, what was done, who received what, how the result
was checked. For each step, give a short supporting excerpt from the story.
Do not add participants, tools, deadlines or actions that
are not in it. If the task has not been accepted yet, say so.

Separately mark the places where information had to be looked up again, where someone
waited for a reply, redid work or kept an agreement in their head.
Distinguish a difficulty that is described directly from your own hypothesis about its cause.
Do not infer how often a problem occurs from a single case.

If a gap changes the understanding of the process, ask up to three specific
questions and leave the remaining gaps visible. Then propose one
reversible experiment on the next similar episode: what to change,
which observable result to compare with the current one and when to drop
the idea. If there is no baseline measurement, suggest collecting it first.

Return a short map of the steps, the main confirmed difficulty
and a plan for one experiment. Do not design the whole system, do not connect
services, do not create tasks and do not send anything. I will first check
whether my work has been reconstructed correctly.

You should get: a map of one episode with supporting evidence, one confirmed difficult area and a small, testable experiment. Check that:

• every step is supported by the story, and unknown participants and acceptance are marked;
• the cause of the rework is separated from the fact of the rework itself;
• one experiment is proposed, and the original case is not declared typical;
• no permission to automate or change working systems has appeared.

A single story may leave out part of the work. The check helps you choose what to observe, but it does not prove time savings or that the company is ready for automation.

Where to start the conversation about an agent

AI's capabilities keep growing, so it is increasingly important to understand which work to hand to it. A verified review of one task gives you grounds for choosing the next step: bringing order to the work, setting up a tool you already have, or moving on to a limited pilot.

Read next: how to prepare a work process for an AI agent: ten checks and how to hand over a task without everything staying in the manager's head.

If you are looking at agents but are not sure which part of the work to hand over to them, we will start with one real task in a free 30-minute meeting with Simplit. Discuss your task