--- title: How to set up your first process for an AI agent metaTitle: How to set up your first process for an AI agent description: The four parts an agent process needs, the one person who accepts the result, and how to choose and set up the first process you hand over. date: 2026-10-29 tags: [ai-agents, business-processes, ai-native] cover: cover.webp coverAlt: Pink-haired woman hands a desk clock to a colleague draft: false sources: - https://www.youtube.com/watch?v=Z3JyAqh4ixg - https://www.ycombinator.com/people/tom-blomfield --- The first repeatable process you hand to an AI agent rests on four parts and one person. The parts are a source of events the agent can access, a standing rule, a list of allowed actions and a check of the result. The person is responsible for the outcome and accepts it. When all of this is in place, you can start the process and watch how it works. ## Four things an agent needs to work repeatably An agent needs four things to do the same job reliably: a source of events it can access, a standing rule for the work, a set of allowed actions and a check of the result. These four parts become a real working process when one person accepts the result of the whole process, not just of one step in it. Here is what each part means. The event source is how the agent learns that it is time to work. It can be an incoming email, a new record in a database, the notes from a meeting or a timer. Without a clear source, the agent waits for you to bring it a task, and you are still the one who keeps everything moving. The standing rule is an instruction that stays the same from one run to the next. It describes what counts as a result, which order of steps to follow, which decisions the agent makes on its own and which ones it passes to a person. If the rule exists only in the head of the person who owns the process, the agent starts from zero every time. Allowed actions define what the agent may do by itself, such as creating a draft, updating a record or sending an email. The same list sets explicit limits. At Majento, a person always approves spending, publications and promises to clients, even when the agent has prepared everything needed for them. This is a deliberate choice about where people keep control, rather than a limit on what the agent is able to do. Every cycle of work ends with a check. The finished result is compared with the source data and the rules in force, and then it goes to the person assigned to review it. The agent that does the work also checks its own output along the way. That is useful and cuts down on obvious mistakes, but significant results are accepted by a specific person named in advance. If the agent stops before finishing, it records where it stopped and why. A recorded stop is part of the result, not a missing result. ## How memory, checks and stop messages turn tasks into a process A one-off request to an agent and a repeatable process are different things. A request ends with an answer. A process keeps going, builds up knowledge and gets better over time. What connects the runs is working memory. This is a store that holds three kinds of entries: the owner's decisions about how work should be done, the standing instructions for specific tasks, and records of what happened in past runs. Each kind has its own purpose, so they are easy to keep apart. Suppose the agent is working through the notes from a later meeting. It checks its memory and sees that last time a similar question stayed open for three days, and that the owner then decided such questions should not wait longer than two days. The agent does not need that decision to be made again, because it is already stored. When the agent runs into a situation that its instruction has no rule for, it records where it stopped and why, and then hands control to a person. The recorded reason becomes the basis for updating the instruction. The team looks at the real case and adds a rule that covers it. This way the instruction improves through situations that actually happened, instead of through guesses about what might happen. ![Phone displaying a message beside an open instruction binder](/blog/ai-native-company-workflows/fig-check-message.webp) ## Examples from Y Combinator and from our own work Tom Blomfield, a general partner at Y Combinator, described one approach in his talk at Startup School in Paris, which is available as a [video](https://www.youtube.com/watch?v=Z3JyAqh4ixg). In his example, a daytime agent answers questions from people at YC about the company's internal data, and a night-time agent goes through the day's sessions and proposes fixes as pull requests, which are proposed changes to the code that have not yet been applied. Blomfield argues that the quality check should rarely be a person and can often be a second model; he notes that a person occasionally has to step in when a loop goes wrong. Majento takes a different approach here. We recommend that a person reviews such pull requests before they are applied and decides whether the changes go into the product. The talk also describes a second example. Transcripts of recorded office hours with founders become the basis for an updated internal guide. The agent finds recurring patterns in real sessions and updates the team's shared memory. As a result, the experts' experience becomes available to the whole system instead of staying in one person's head. Majento is a team from Tashkent that builds and deploys AI agents and trains teams in Uzbekistan, and we also work with an international audience. Inside our own system, an agent called pi coordinates the work and links tasks to the owner's decisions. Team leads give clearly bounded tasks to executors and accept their results. Watchers track any stops and pass them to a person in time. The Vault, a single store of linked notes, keeps notes about projects, decisions and tasks. Iva is a separate product and Sergey's personal assistant. When a team lead starts a task, they first check the Vault for a decision that has already been made on a similar question. If there is one, the work builds on it. If there is not, the approved result is saved in the Vault after the check, and it becomes the current reference for the next tasks of the same type. ## A worked example with meeting notes Below is an invented example with made-up data. No real run took place. The example is here to show what an agent's work under a standing instruction looks like. In this first process, the event source is simple: a person attaches the meeting notes by hand, and that starts the run. Standing instruction for the agent: > Source: the meeting notes, attached by hand. No task tracker or email system is connected. > Rule: separate what was agreed from what was only proposed. Prepare a short, neutral email with one question. Keep the open questions, each with a responsible person and a check time. Until sending is confirmed, produce only drafts and a summary. > Owner who accepts the result: Natalia, the coordinator. > Next check: 29 October 2026, 10:00. Attached notes: > Meeting notes, 28 October 2026. The deadline for the documentation is agreed for 15 November. Anton suggested adding a section on integrations, which is waiting for Marina's decision. The format for handing over files has not been chosen. Expected reply from the agent: *Summary of what was agreed:* The documentation is due on 15 November 2026. *Draft email to Marina:* > Hello Marina. At the meeting on 28 October, Anton suggested adding a section on integrations to the documentation. Should we include this section in the current version of the documentation? *Open questions:*
QuestionResponsibleCheck
Add a section on integrations?Marina29 October 2026, 10:00
Format for handing over filesNot assigned - needs an owner29 October 2026, 10:00
*Status:* the email is ready as a draft and has not been sent. Waiting for Natalia's confirmation. Now a person checks the reply against the notes. The 15 November deadline comes straight from the meeting notes, where it is recorded as agreed. The email asks one question and words it neutrally. Anton appears in the notes as the person who made the suggestion, but the question goes to Marina, because she is the one who makes the decision. The file format is still open. Nobody is responsible for it yet, so the agent did not fill in a name and marked the question as needing an owner. Nothing was sent, and there is only a draft. This is what the example shows. The agent kept the agreed deadline apart from the proposal, left the question without an owner unassigned, and kept the email as a draft until Natalia confirms sending. ## How to choose the first process A good first process is one that already has an expected output and a clear deadline. Examples are a weekly summary of open tasks, draft replies to standard requests, or an update of an internal register after meetings. Each of these produces a specific document at a specific time. Before you start the agent, write down three things: what it should produce, by when, and why it may stop early. The last one is the most valuable. If the agent stops and does not report it, you find out by chance. If a stop is written down as an expected event, you see it straight away. Assign one person to accept the result. Not "the team" and not "everyone involved", but one person. This person notices when the deadline has passed and there is no result, and this person decides what to do next. A simple way to notice a stop is to set up a single notification. If the expected output has not appeared by the set time, the responsible person gets an alert. This does not need complex infrastructure. Any ordinary program with a scheduler can do it. ![Yellow card in a separate tray beside a phone notification at night](/blog/ai-native-company-workflows/fig-separate-overdue-task.webp) ## Frequently asked questions ### How is an agent different from the automation we already have? Automation that follows fixed rules handles unambiguous steps well, and often that is enough. An agent built on a language model is useful where the input is text, such as an email or meeting notes, and needs to be interpreted. The model chooses a suitable step within the allowed actions. Memory between runs and stop messages are set up separately, and both approaches can have them. ### What happens when the agent meets a situation it cannot handle? The instruction sets out clear behaviour for uncertain cases, which is to stop and report the reason. The team tests this behaviour on specific examples at launch, and an external watcher checks that either the result or a stop message arrives by the expected time. When a stop does happen in real work, the recorded reason points to a gap in the rule. The team looks at the case and updates the instruction. ### How do we train employees to work with agents? Start with the process you chose for the first rollout. People learn better on their real work tasks than on abstract examples. We explain how to organise this in more detail on our [team training page](/ai-training/). ### How can we tell whether a process suits an agent or is better left to people? If the result of the process is a specific output, the steps repeat from run to run, and the input can be passed on as text, the process probably suits an agent. If the result has to be agreed again every time and depends on informal context, start by documenting the process itself. We wrote [a separate article](/blog/ai-agents-for-business/) on how to choose a suitable business task. *If you want to work out which process would suit your company, write to us on [Telegram](https://t.me/shimaoz) or at [hello@majento.ai](mailto:hello@majento.ai).*