Business process automation
Goal: move routine business processes into systems people use every working day. Each one covers a process end to end — from the moment a task appears to the report on it.
Examples already in use
Corporate portal. The organisational structure as a living document: headcount by department, org charts, spans of control. For every position, a set of role documents: position card, authority matrix, reporting order, escalation order. The quality of those documents is assessed by AI: it points out where a description is incomplete or contradicts itself and suggests what to work on. Alongside sits a single store of company documents with search, a task module with delegation, and meeting minutes.
Quality control. The movement of requests into the quality department: a request travels an approval route through neighbouring departments and lands in reporting.
Warehouse yard management. Vehicles registered in and out at the gate, passes issued, release of vehicles and cargo cleared with customs.
3PL shipment management (B2C logistics). Batches from receipt to hand-over: statuses arrive from neighbouring systems on their own, analytics on transit time and volumes, profitability of the line.
Billing system. Invoicing by stage: a counterparty directory, tariffing, SLA control, and the invoices due are created automatically on a schedule.
Common to all of them: the process no longer lives in email threads and spreadsheets. Data is entered once, everyone involved sees where things stand, and the report assembles itself. What could not be seen before becomes visible: who is holding up an approval, where a batch is standing, how much the line earned.
Self-run automation teams inside business units
Goal: teach a business unit to automate its own processes by itself — without an IT department, without contractors, and without handing the task elsewhere. The code is written by the people who know the process from the inside, with the help of AI.
The work follows the same order as professional development: a task is opened and described, the work is done on its own branch, changes arrive as a pull request. An AI agent runs the review against the project's standards and returns a verdict, while the decision to merge is taken by a person — the head of the department, as the owner of the process.
How it is set up
- a way of working, the same for everyone, written down so that both people and AI agents read it
- infrastructure: repositories, protection of the main branch, separated access, distinct environments for checking and for live work
- the rules of each project inside the project itself — a single contract for the employee and for their agent alike
- automatic review: every change is checked by an agent against the project's standards before it reaches a person
- training for the staff — not in programming, but in the way of working
- the owner of the process — the head of the department: they set the tasks and decide on release.
The model is tied neither to an industry nor to particular people: it rests on the way of working, not on someone in the department knowing how to program.
Virtual employees and assistants
Goal: hand virtual employees the work that today takes people's whole day. A virtual employee is not a program you open when you happen to need it, but a role with a standing area of work: its own schedule, memory of its own subject, and the right to come to a person when a decision is needed.
What can be handed over
- taking in the incoming flow — letters, requests, enquiries — and turning it into tasks
- watching the system: noticing a failure and giving warning before a person notices it
- regular reporting and summaries that assemble themselves instead of being prepared for a meeting
- checking work against set rules — from code review to whether documents are complete and free of contradictions
- taking part in the working conversation alongside colleagues and where that conversation already happens: in a messenger, in email, in the task itself.
A separate role is the personal assistant: tasks are set by voice, email arrives as a digest instead of a list of letters, reminders and meetings create themselves, a summary is ready in the morning, what is needed is found in a personal archive, and a document is explained in plain words.
Every area has its own employee — with its own rules and its own memory, rather than one universal helper for everything. That is why it answers to the point, does not confuse contexts, and does not repeat a mistake that has already been worked through.
The agents run on their own server: speech recognition and the handling of personal data happen there, and only what genuinely calls for a large model goes outside. More about how that is built — in the last block.
Work that used to require a person's attention every day now runs without them. A person steps in where a decision is needed.
Products for people
Goal: carry an idea all the way to a published app. Automating a process ends inside the company. A product lives differently: people find it on their own, it has to explain itself and work without anyone standing behind it. That is a different set of tasks — the idea, the design, development, publication in an app store, payment, support for real users.
Example already in use
Planometer — an app that measures the quality of planning. It runs on iPhone, iPad, Mac and in a browser.
Ordinary planners store tasks. Planometer examines how a person plans: how often things get moved, how much unplanned work turns up in a day, how densely the day, the week and the month are laid out. Out of that comes a discipline index — a single number that shows whether planning is getting better. On top of that there are assistants: you can talk to them by text and by voice in real time — set a task, go through the past week, plan the next one.
The app connects to calendars and task lists and speaks Russian and English. The app itself is free; the features with artificial intelligence, assistants included, run on credits — a user buys them only if they are needed.
The idea, the design, development, publication and support — all of it in one pair of hands, with the help of artificial intelligence.
Systems integration
Goal: remove the boundary where data passes into human hands. A single system solves its own task and runs into such a boundary: beyond it, the data is carried by a person — by hand, by email or in a spreadsheet.
What this involves
- exchange between internal systems: data entered once appears everywhere it is needed
- connection to the external systems of partners and contractors through their interfaces: statuses, documents and reference data arrive on their own
- single sign-on and shared reference data: one person — one account, one list of counterparties across all applications
- email as a working channel: a letter becomes a task, the reply goes back into the same thread, the correspondence remains as history
- the messenger as a workplace: notification, command, report and discussion where the person already spends the day.
What to keep in mind: a neighbouring system can go silent, answer with an error, or send the wrong thing. So retries, protection against duplicates and a clear signal to a person — what exactly did not go through and what to do about it — are built into the link from the outset. Without that, an integration holds while everything works and breaks at the first failure — silently, and it will not be noticed straight away.
When systems are connected, a whole class of work disappears: reconciliations, retyping from one window into another, and letters asking someone to confirm a status.
Monitoring outside information
Goal: sift out of the outside flow the few things that need a response. Every day brings more events than anyone can keep up with. Decisions are made on a handful of them, while the time goes on scanning two hundred headlines, half of them about the same thing.
What is done
- collection from sources of different kinds — feeds, service interfaces, sites, research publications — on a schedule and without a person
- merging duplicates: several outlets write one story in different words, and it is recognised as one rather than five
- translation, if the source is in another language
- a short account — the substance in a few lines instead of the whole article
- an assessment of importance: the flow is ordered by weight, not by time of publication
- a digest in a convenient channel: by email, in a messenger, or on your own page.
What to keep in mind: the value comes from the filtering, not from the collecting. A source can go silent, change its format, or start reprinting others. Without merging duplicates and weighing importance, within a couple of weeks the feed turns into the same noise it was set up to escape — only now in your own interface, and people stop reading it.
The subject is set during setup: the market and competitors, changes in regulation, mentions of the company, industry publications, technology — or anything of your own, outside work. The mechanics stay the same — only what to watch changes.
A few lines instead of two hundred headlines — and what matters is learned while it can still be influenced.
The fleet of agents: how it is built
Goal: keep dozens of agents running with one person to look after them — so that the same task is solved the same way rather than however it happens to go. One helper in a chat is not yet a system. As soon as there are several agents and they work all the time, the question shifts: not “what can the model do”, but how all of it is governed, limited, and kept from breaking unattended.
What it is made of
- each agent has its own place of work — on a local machine, on a server, or in the cloud; chosen by the task, not by fashion
- its own permissions: an agent can do exactly what it is allowed to do, and no more
- its own skills — reusable procedures carried out the same way every time instead of being invented anew
- starting on a schedule and on an event, not only when a person asks
- passing work between agents: the heavy part can go to a separate performer and come back as a result rather than a pile of intermediate output
- automatic checks on every action — they fire before the action takes place
- watchdogs that keep an eye on the agents themselves and report if one has stalled or started consuming too much
- control from where the person already is: the terminal, a messenger, email.
The tools themselves vary: agent environments — Claude Code, Codex, Hermes — and models from different providers, cloud and local. There is no lock-in to any one of them: how the fleet is built does not depend on the provider, and a tool is chosen for the task and replaced when something better appears.
What to keep in mind: the main danger is not that an agent will fail to do something. It is that it will do something confidently and wrongly — and report success. Hence limited permissions, checks that fire before an action, and the habit of an agent showing what its answer rests on. Without that, a fleet works right up to the first expensive mistake.
Built this way, the system works without daily supervision and says for itself when someone needs to step in.
Project memory and knowledge
Goal: give people and agents one memory they can trust — and keep it where the work happens, not in people's heads and not in a folder nobody opens. In a department, knowledge lives in people's heads. Why it was decided this way, who agreed to an exception, what has already been tried and turned down — people remember that, not documents. Someone goes on holiday or changes job, and part of what everything rested on goes with them. The same is true privately: holding everything you deal with in your head is impossible — and unnecessary, if the system remembers.
What is done
- standing memory for a project and for a department: decisions, reasons, constraints and the mistakes already paid for are written down where the work happens, not in a separate folder nobody opens
- search by meaning, not by exact word: text is turned into vectors — embeddings — and what is close is found by meaning rather than by matching letters. What is needed turns up even when the question used other words
- an answer from context, not a list of links: the system finds the relevant pieces itself and answers in plain words, showing where it took them from — so that it can be checked
- the index sits next to the data, in a compact local database (SQLite), and the vectors are computed on your own machine: the contents of documents do not go outside in order to be searched
- one memory for people and for agents: an agent relies on the same source as an employee, not on a separate base of its own
- a new participant gets the context at once — a person as much as an agent, instead of three months of getting up to speed.
This mechanism is usually called RAG: the model answers not from what it once learned, but from your data, found for the specific question.
Memory is divided into levels. Each project has its own — the decisions and constraints of that project alone. A department has a shared one — rules, agreements and accumulated experience, the same across all of its tasks. A person has a private one — what only they need. The levels do not mix: an agent for a project carries nothing extra, while what is shared is available to everyone entitled to it.
What to keep in mind: memory lies silently. A stale fact looks exactly like a fresh one, and this comes to light at the moment a decision has already been taken on it. So a record about a state carries a date for rechecking, anything unverified is marked as unverified, and the memory itself is reviewed regularly. Without that it turns into a dump that people stop trusting — and becomes useless while still being complete.
Knowledge stops being personal: it does not leave with a person and is not lost between tasks.
Own infrastructure on own hardware
Goal: answer the question that gets asked last and needs settling first: where does all of it run, and where does the data go.
The base is a server of one's own — an ordinary desktop computer, not a rack in a data centre. The agents live on it, along with schedules, databases, search indexes and watchdogs. What must not leave the perimeter is done there as well: speech recognition, building the vectors for search, handling work and personal documents.
Only what the cloud is actually for goes to the cloud — large language models. This is a deliberate division rather than a forced compromise: keeping a model of that size at home is expensive and pointless, while sending the contents of documents outside merely in order to search them is not needed at all.
What it gives
- the data stays with its owner: what is sensitive is processed on your own hardware
- costs are predictable: the server is bought once, and only the models are paid for month by month
- nothing is lost when a provider changes: a model can be replaced, while the memory, the indexes, the schedules and the accumulated knowledge stay where they are
- independence from other people's decisions: a service closing down, raising its price or changing its terms does not stop the work.
What to keep in mind: your own hardware is your own responsibility as well. It needs to start itself after a reboot, it needs backups, and it needs watchdogs that notice something has stalled and say so. Without them, “my own server” turns into a computer under the desk that people remember about once it has already been down for a week.
That is why everything described above is not a set of subscriptions to other people's services, but a system you own.