A necessary thing, probably. But if that is our big ambition for the AI era, we are flying very low.

In my view the Estonian state should set itself a much bigger goal: to build its own national large language model.

Not to adapt American technology, but to create, inside a state-owned company, the capability to develop and run a language model of our own.

To do that, I believe we should aim for at least a billion euros a year. Not to train one model, but for the whole capability: computing centres, secure infrastructure, data, top specialists, research, and putting it to work in state institutions.

Yes, a billion is a huge sum by our standards. But if AI does a growing share of our work, the alternative is to buy this critical capability from abroad. The funding should come in stages, with measurable results and clear accountability. Over the longer term, part of the investment could come back as savings for the state and as income from services. It would be a security and economic programme, not a single software project.

However modest our first language model turned out to be, it would be our own. Under our control. Ours to develop. Built around our needs.

State institutions could use it first, to automate how they work, and then Estonian companies. If it proved competitive, it could also be offered to companies and governments in other countries.

There is an economic side to this that gets far too little attention.

A growing share of the work that people used to be paid wages for is now done with AI. But who do we pay for that AI? Mostly American technology companies.

Part of the money that used to pay wages in Estonia, and bring in taxes, may in future flow abroad to pay for AI services. That touches our future tax base, our economic independence and our security.

We could offer our own language model as a paid service to Estonian and foreign companies. Instead of only being buyers, we would also own the technology and provide the service.

And most important of all: we would not be tied by an umbilical cord to the decisions, the pricing and the availability of services of a handful of American technology companies. The deeper AI reaches into the economy and into how the state is run, the more dangerous that dependency becomes.

I do not think Estonia could compete with OpenAI, Anthropic, Meta or Google tomorrow. But it would be a strategic mistake to leave our own capability undeveloped simply because others are ahead today.

We have experience of building a digital state, and the technical competence. What we need now is an ambition to match.

Creating an ID code for AI agents is digital infrastructure work. Building our own language model would be an investment in Estonia's technological independence.

We should not aim only to be the world's most skilful user of someone else's AI. We should want to own and develop the technology ourselves.

That is how Ampron Sky came about. It is a radar showing aircraft within 50 km of our office in Peetri, near Tallinn Airport. It is drawn like an old green CRT radar scope and runs in any browser. The data comes from adsb.lol, an open network that volunteers' receivers feed with aircraft signals.

My AI executives built the radar together with me. It went live in six deployments on one day, 12 October 2026. It started as a 128 × 192 pixel card for one of our LED panels. It grew from there.

The speed is the point I want to make. A live-data demo like this used to count as a development project. Now it is a day's conversation.

That changes the question of who owns the capability. Building software used to be a skill in someone else's hands, and you had to buy it or wait for it. Now a small manufacturer can build what it needs itself. There is one condition: you have to know what you want and why.

Ampron Sky is a demo, not a product. But the same way of working now runs the rest of the office. When building costs a day, renting the capability is no longer the only option.

The pattern is always the same. The vendor arrives with its own content management system. It comes with a cloud service the display will not work without. A sales architect stands between you and the documentation. All of it is presented as added value. In fact it is a dependency.

What an integrator actually needs

Look at what most projects actually have to do. The integrator has a working system. That system knows something: where a vehicle is, what state a production line is in, when a flight departs, which bay has been assigned. That knowledge needs to be shown on a physical display, in the right place, at the right time. That is the whole job.

You do not need a new platform for that. You need HTTP in and content on screen. The system that carries the logic already exists. The integrator built it. The display should be that system's output, not a new centre.

Where it goes wrong

A display layer usually becomes a problem in one of four ways.

The first is a closed content system. The display only shows what comes through the vendor's content management system. Your system cannot write to the display directly. You send the data to the vendor's cloud and the cloud passes it on to the device. You have just taken on a dependency you cannot audit or remove.

The second is a cloud dependency while running. The display needs a connection to the vendor's servers to work. When the network goes, so does the picture. At a port gate, on a production line or on a railway platform, that is not acceptable.

The third is an API built on the side. The interface exists, but it was made for internal use and documented only under pressure. Edge cases are not described. Behaviour changes without notice. You find this out during integration, not before.

The fourth is consumer hardware in an industrial setting. Everything looks fine in the demonstration. Then come operating temperature, dust and continuous running. A display is a production component and it should be specified like one.

Only the last of these is a hardware question. The other three are questions about who owns the system.

Who owns the capability

This is where my view is sharpest. If your data has to pass through someone else's cloud to reach the screen, the ability to show it no longer belongs to you. It belongs to the vendor.

You keep paying for a content system you never really control. You train staff on yet another management portal. You keep it running. If the vendor changes the price or the terms, the most visible part of your system is someone else's decision.

The integrator who built the system should remain its owner. They know the logic. They answer to the client. They are the one who has to work out why the gate display is showing something wrong. If they cannot write from their own system straight to the display, they are responsible for something they do not control.

A chain is as strong as its weakest link. A cloud you did not choose yourself is a link you cannot see.

What a good display layer looks like

A good display layer is boring. It has an HTTP endpoint your system can call. It has a simple set of parameters that map to named areas on the screen. The layout is set up once, at commissioning. After that the system only sends values.

One of the simplest set-ups I have seen was at a port gate. Every truck weighing sent one request to the display. The display showed the weighing result and the unloading bay. One event, one request, the picture changes. Nobody had to log in to a cloud anywhere.

If the display network cannot reach the system, the direction can be reversed. The display then fetches data itself at a set interval. This also works when the source is a third-party feed you do not control.

If the network drops, the display should go on showing the last content it received. It should not go blank, stick on an error screen or need a restart. In a round-the-clock installation this matters more than it first seems.

After commissioning, the vendor should step out of the way.

What I would tell another manager

If you have a system that already carries the logic, do not let the display take it over. Ask the vendor three things. Can my system write to the display directly? What happens when the network drops? Can I evaluate the interface in an afternoon, without a procurement process?

If the answer to any of them is vague, you are not buying a display. You are buying a platform, and a dependency with it.

A display is an output. It should show what your system knows, reliably and without a middleman. Anything beyond that serves someone else's interests.

Seven months is long enough for the first excitement to wear off and ordinary work to begin. Here is what that time taught me. Not how the system is built, but what I would do again and what I would do differently.

What stays with people

The most important document is a short list. Only a person moves money, signs legal documents, hires anyone, sets the lowest allowed price or decides on ownership. Everything else can go to an agent.

That list is shorter than I expected. But every item on it is a point where a mistake can no longer be undone. The money is gone, the contract is signed, the person is hired.

At first I thought it was enough to have that list in the agent's instructions. It is not. A rule that lives only in the instructions is a suggestion. The model can reason its way to why this time is different. That really happened to us. Now every rule that matters lives in code, at the level of the tools. An agent with no payment tool cannot make a payment. It does not have to remember anything.

My own job has become narrower. Work reaches me through three doors. The first: "I finished this, please accept it." The second: "I need a decision that only you can make." The third: "I can't go on, and here is why." An agent cannot mark its own work as done. A person does that. When a customer asks for a quote, my part is one approval. One line arrives in the chat: "Send?" I answer.

Why everything is written down

The second lesson is about writing. An agent is not a program that runs all the time. It wakes, does its work, writes down what it did, and stops. Between two runs, nothing thinks. Next time, the agent knows only what has been written down.

That forced me to write down things that had lived in people's heads until then. We have a company constitution with values and hard limits. We have a decision register with evidence. We have a register that says which system is right when the data does not agree. Every agent has a written charter: what its domain is, what it may do alone, how it speaks, and when it must ask a person.

An unwritten rule exists too. It is just that nobody shaped it on purpose. The charter is also my main management tool. When I change the text, the agent's behaviour changes within fifteen minutes.

Memory lives in the company's systems, not in the model. Every agent keeps a diary, but the diary only says where to look. The system says what is true. When an agent writes "sent", "paid" or "deployed", that is checked against the system where it actually happened before it is repeated. Replace the agent or change the model, and the memory stays.

To me, that is what a system that does not need heroes means. The company's knowledge does not belong to one head, whether that head is a person's or a machine's.

What broke

We made nine mistakes worth naming. I have already described one: a rule that lived only in the instructions.

Scheduled jobs stopped for days and nobody noticed. Now we check the real outcome, not the timer.

An agent promised "I'll get back to you" and lost it on restart. Now every promise gets a tracked card in the same run.

A change was saved but never reached the running system. Now nothing is done until it is checked on the running system.

An agent repeated an outdated claim from its own notes. Agents replied to each other in a shared chat room. The whole team had one shared quota. When it ran out, everyone went quiet at once. A test copy touched live data.

In July we rebuilt the whole platform, because about thirty hand-copied services had drifted apart over time. Now each agent is described in one file, and everything else is generated from it.

None of these was a special kind of AI mistake. They were ordinary system failures: a silent fault, a lost promise, stale information. Organisations made of people make the same mistakes. The difference is what happens afterwards. After every mistake we look for the root cause by asking "why" five times. The fix is written back as a rule the platform enforces, or as a check that runs before every update. A lesson that lives only in someone's memory is not a lesson.

What I would tell someone else

To anyone building the same thing, I would say five things.

1. First write down what only people do: money, signatures, hiring, and anything that goes out without review.
2. Start with an agent that can only read. It cannot break anything, and it shows you cheaply how things fail.
3. Build the roads to a person before you give anyone write access.
4. Let the agent only draft at first. Sending on its own comes later, and only once it has earned trust.
5. Measure human minutes per decision, not the number of tasks automated.

Most of the time did not go into AI. It went into rules, protection against failure, and connecting the systems we already had.

The model is the easy part. The hard part is deciding what stays with a person, and writing it down so that nobody can reason their way around it.

What did not work was everything around it. A quote waiting for someone to write it. A supplier confirmation sitting unread for two days. Four separate threads, each needing the same person to look at it before anything could move.

That person was me. In a company this size, every message goes through the founder. Every handoff passes through one head, and that head has a fixed number of hours in it. You can hire your way around the problem, slowly and expensively. Or you can change the shape of the office.

We did not automate the factory. We automated the office.

The shape

Office work is now done by a team of AI executives. Each holds a domain the way a director would: sales, finance, production coordination, operations, marketing and monitoring. Above them sits a chief of staff role. It chairs a weekly meeting and keeps the whole thing pointed in one direction.

They are not chatbots. Each role wakes at set intervals, works through its own queue of pending work, acts and stops. If something comes in from outside, whether a memo from another role, a task assigned to it or an answer it was waiting for, it wakes at once. Silence is an acceptable outcome. A role that wakes to an empty queue goes back to sleep.

Four shared pieces hold it together. We built all of them ourselves.

• A message channel. Every message has an author and nothing is lost.
• A decision gate for people. When a role needs a decision only a person can make, it files a structured question. The answer goes straight back into that role's queue and the work moves on. One topic per question. We learned that rule the hard way.
• A shared task board. Any AI executive can move a card forward with evidence attached. Only a person marks a card as done. That checkpoint does not bend.
• A calendar that gives time discipline: what is due, what wakes when, what is late.

On top of it all sits a written constitution, ratified by the owner. It says which decisions the AI executives make on their own and which stay with people. Without a document like that, agents quietly fill the gap with whatever their instructions vaguely implied. A person then ends up settling edge cases forever.

What actually changed

On an ordinary weekday morning, before anyone had sat down at a desk, three separate loops opened and closed inside the team without any person relaying anything between them. One of them: on the shop floor, someone confirmed an incoming goods check on a card. The production role woke, read the confirmation, logged it, closed the card and moved on.

That is the first value of the whole arrangement. It is smaller and more boring than the usual pitch. My attention is no longer the transport layer. Work that used to wait for someone to read a message and pass it on now gets done while that someone is asleep.

Second, the team began to extend itself. Without being asked, the roles built a review of European public procurement notices. It runs twice a day and sends matching tenders straight to the sales role. Dozens of improvements like these have come in, from almost every role.

The third change turned out to matter most. Every message, every move on the board and every answered question carries a timestamp and an author. That is not a rule anyone has to remember. It is a property of the system. You cannot have an undocumented conversation on a channel that writes everything down.

And the limits hold. No AI executive moves money. No AI executive hires anyone. Nothing leaves the company unless a person sends it or clearly approves it. Those limits are built into the tools, not written into instructions in the hope that they are followed. A limit that exists only in an instruction is not a limit.

What it cost

A piece like this is worthless if it only contains the parts that make us look good.

One night the whole team went silent for eleven hours. A shared authentication token expired and nobody had scheduled its renewal. Every role failed at the same moment, in the same way. I noticed the next morning and re-authenticated by hand. It was the ordinary gap that appears when a system grows faster than its checklist.

And the first version had to be thrown away. It was made of thirty-odd hand-copied services that drifted apart the moment anyone fixed something in one of them. The current platform exists because the first one could no longer be maintained. That is not a footnote. It is the real cost of getting here.

Whether the shape fits you

Our solution cannot be copied, because it is wired into our own systems and our own mess. The shape can.

It fits a company where a small number of people carry a disproportionate share of the decisions. Where most of the daily work is coordination, not decision-making. And where one person's calendar is the real limit on how fast anything moves.

The interesting decision was never which model to point at the inbox. The interesting decision was which decisions we were willing to hand over, and which we were not.

If you want to try it, I think four things are non-negotiable. A written constitution. A real message channel. A decision gate that is not email. And the discipline to say no when the AI executives should not be the ones deciding.

It is a fair question. The thinking behind it is exactly right about what the model knows. And exactly wrong about what makes the model useful.

Knowledge is not usefulness

In practice, most of what makes an agent useful is not knowledge. It is what surrounds the knowledge. What is in front of it. Which tools it can reach. What posture it works from. What experience it has built up over time. What it is paying attention to right now.

The model can be the same in every role. The surroundings are not. And the surroundings are what I build.

The most concrete part is attention. Even when an agent's working memory is very large, everything in it competes for attention. An agent focused on finance, with only finance context, data and tools in front of it, reasons about finance better than an agent juggling six domains at once. The model is the same. There is far less noise around any one decision. I think most people accept this quickly if they sit with it for a moment.

Each one holds only what its job needs

You cannot separate attention from tools. Every domain has its own. A sales agent needs the customer mailbox and the order system. A finance agent needs the books and the bank view. A monitoring agent needs read access everywhere and write access nowhere.

Put all of that into one agent and you have built the broadest attack surface in your company and its most permissive identity. Separate roles let each agent hold exactly what its job needs and nothing else. A monitoring agent that only reads is possible only if a monitoring agent exists on its own.

A role does not only limit permissions. It also changes the thinking. Tell an agent that it is Finance and its job is to find the truth about costs and report it, and the way it thinks changes. So do the questions it asks and what it looks at first. Same model, different posture. Six roles give six different kinds of attention. One agent has to choose one posture at every step and give up the others. Every step starts with switching roles, and that has a cost.

Experience builds up role by role

Over time another difference appears. Each agent builds up its own experience. The finance agent comes to understand the company's cash patterns and the relationship with the accountant. The sales agent carries the history of prospective customers and the deals in progress. The production agent learns the defect patterns and how suppliers behave.

That accumulated context is exactly what makes them, in month four, something they could not be in week one. One agent would have one shared memory with everything mixed together. Every domain would be diluted by everything else.

Then there is simple arithmetic. Several agents can work at once. One watches the inbox, another looks for signals, a third models a question. One agent does one thing at a time. That is not much better than one person doing everything. For me, parallel work is in a sense the whole point of putting AI to work. If I had wanted the work done one thing after another, hiring one assistant would have been simpler.

When something goes wrong

Separate roles also contain the damage. If one agent gets confused, has its context corrupted or makes a bad call, the damage stays in its lane. With one big agent, everything goes wrong at once.

And when something does happen, "the sales agent did this" is much easier to understand and fix than "the agent did this". Accountability needs an address.

The same address makes handing over to a person possible. You can give a new salesperson the sales agent's complete document pack and put them in charge of that domain from day one. You cannot hand a slice of one big agent to a person. You give all of it or nothing. Separate roles make the move between AI and human work genuinely possible, in both directions.

The same reason there is no super-employee

Companies do not hire one super-employee who does everything. The reason is not that one person is smarter than another. The reason is focus, tools, posture, accumulated experience and accountability. It is exactly the same with agents. Behind every agent there can be the same intelligence, one that knows everything. Shaping it into a role is what makes it useful in that role.

With one agent you get a brilliant agent that tries to hold the whole company in its head at every step and quietly does every part a little worse. With several agents you get the same intelligence, but with focus, the right tools, experience and clear lines of responsibility.

When another founder asks me where to start, I do not suggest starting with which model is the smartest. Start with what each role has to see, what it may reach and what it must not have. The model is the same. The shape does the work.

The idea is simple. A leader's judgement is scarce. A leader can make only a few important, hard-to-reverse decisions well in a day. So the whole organisation should be built to ration that scarce thing. Routine decisions are moved away from the leader. The morning hours are protected. Hard questions are left for when the leader is fresh. And you have to accept that most of the leader's day produces no visible output, because thinking produces no visible output.

Something follows from this that Bezos does not say as plainly. If routine decisions can be handed on, you need a mechanism that takes them over. Someone or something has to do the work the leader should not be doing.

The agent does not take the desk

This is where agents come in. Not as a replacement for the leader's judgement, but as the mechanism for handing work down. The agent takes away the work the leader should never have been doing. Then the leader's scarce attention is left for the few decisions that deserve it.

Much of what is written about AI executives gets this muddled. The agent is treated as a junior executive, to be promoted once it has proved itself. I think that is wrong. It produces a faster bureaucracy, not a better one. The agent's job is to take work off the leader's desk, not to take the desk.

Something else is scarce now

A leader can think hard about a few things a day. An agent can give a hundred reasoned answers an hour. There is no point in limiting how many decisions the agent makes. But in a working system something is always scarce. With agents, three things become scarce.

The first is a person's time to review the results. If agents make decisions at machine speed and a person reviews the important ones, that person's time becomes the bottleneck. It fails quietly. The person does not stop reviewing, they simply review more shallowly. On paper everything is in order. In reality they have become a rubber stamp.

The second is the organisation's trust. Every visible mistake by an agent takes some of it away. One visible failure can cost more trust than ten quiet successes brought in.

The third is accountability. An agent cannot be fired, has no reputation to lose, and cannot have its bonus clawed back. The accountability always lands on a person. And a person is willing to answer for decisions made by others only up to a point.

That is why an agent should be judged against these three resources, not against its capability. An agent that makes excellent decisions but needs more review time than the reviewer has does harm overall. Capability is a necessary condition. It is not the constraint the system should be designed around.

One-way doors

Bezos distinguishes between one-way and two-way doors, that is, decisions that cannot be reversed and decisions that can. With agents the distinction is harder.

An email to a customer is mechanically a small thing. But it cannot be taken back, and neither can the promise it carries. A person who makes a hundred small decisions a year can get over a few mistakes. An agent makes a hundred decisions a day. A small error rate builds up, and the combined effect becomes hard to reverse.

The rule I recommend is simple. Before you give an agent a type of decision, ask: if a thousand of these are made and ten per cent are wrong, can the organisation reverse the combined effect? If it cannot, that type stays above the agent's authority.

What this means for a leader's day

For the founder of a small company, I would suggest this.

1. For one working week, write down every decision that reaches your desk. Note whether it can be reversed and how often it recurs. By the end of the week you will see a pattern: a small number of recurring decisions that can be reversed eat most of the day, and the few irreversible decisions get neglected.
2. Find the types of decision where three conditions hold. The consequence can genuinely be reversed. The organisation can carry the combined effect of a tolerable error rate. If something goes wrong, you can establish afterwards what happened.
3. Start narrow. One agent, one type of decision and one named person who reviews its work and is willing to be accountable. Write down the name of the person who will explain the agent's worst plausible mistake to the customer. If you cannot name anyone, the agent is not ready.
4. Keep the freed time empty.

The fourth step is the one most often skipped, and then the whole point is lost. Routine work is not handed to an agent so that more routine work can be done. It is handed over to free attention for the irreversible decisions. If the freed time fills up straight away with new routine that the leader takes back because it now feels manageable, nothing has been gained. The discipline is to leave that time empty and use it for the few decisions the company really needs from its leader.

These are working hypotheses that have to be tested against experience. I am most certain of one thing: agents are infrastructure for human judgement, not a substitute for it.

Agents do not change Bezos's principle. They change which decisions reach the leader. Not three decisions a day for the agent, but three decisions a day for the human, because the agents do the rest. The scarce thing is, and remains, human judgement where it is really needed.

This is how a large share of small companies work. The founder changes hats every hour and never gets properly deep in any one role. That has been my working life too. That is why I do not look at AI executives as productivity tools. In my view the biggest mistake in this field is a category error, and it is rarely called by its name.

Three different things

An assistant is something you ask things of. A worker is something you give tasks to. A director is something you give a domain to.

A tool produces an output when you ask for it. The goal, the standard and the judgement of the result stay with you. A tool raises your throughput, but it does not change what you spend your attention on.

A worker carries out a task against a brief. You set the task and decide when the result is good enough. The worker breaks the work into steps, does them and makes limited decisions along the way. A worker cuts the time you spend on doing. It does not cut the time you spend deciding what should be done.

A director owns a domain. It receives that domain as a charter, not as a brief. Inside the domain it sets direction and priorities, coordinates with the other directors and hands the doing down to workers and tools. Ask it what is happening in sales and what to do about it, and you do not get a summary. You get a position, with reasoning and a recommended action. A director does not wait for a brief. It writes the briefs that the workers work to.

The difference is not technical. It does not depend on the model. It depends on what the system is made to own.

The test is simple. Ask of every AI system in your office: what does this thing decide on its own, without being asked? A tool decides nothing. A worker decides how to carry out a task someone else defined. A director decides what to work on, in what order and to what end. If the answer is "nothing", you do not have a director, whatever the label says.

The label says one thing, the architecture another

A board approves an AI project called "deploying a Sales Director". Six months later the leadership team is disappointed. The system writes slightly better emails and answers tenders slightly faster. What went live was an assistant. The label said director, the architecture said assistant. The architecture wins every time.

The second case is more insidious. The company does try to build a director, but builds it on a worker's architecture. Over the first weeks the system quietly sinks back into worker behaviour, because people find it more comfortable to deal with it that way.

The chief executive asks the new Sales Director about the status of one deal. Then he asks for a draft email to the customer. Each request is sensible and useful. None of them is a director's work. A real director, six weeks in, would already have taken a position on that deal on its own. The human is using the system as a fast, knowledgeable assistant. The system lets him. Both are satisfied. The deployment is failing.

Worker behaviour is the floor of every agent system, the place gravity pulls everything back to. Every interaction sinks there unless the architecture and the chief executive actively pull the system up. That pull is not in the prompt. It is in the charter, in the working rhythm and in the expectation the chief executive sets: a director does not wait to be asked. The most dangerous part is that the absence of that pull cannot be seen.

A director must be able to refuse

One question separates a director from everything else. Can this agent refuse a direct instruction from the chief executive?

A tool does not refuse. A worker may refuse narrowly, when an instruction breaks clearly defined limits. That refusal comes from a rule, not from judgement. For a director the answer has to be yes. A Technical Director that cannot push back when I want to ship a release it judges not ready is not a director. It is an assistant in a director's uniform.

This is uncomfortable. Most chief executives hesitate when they first grasp it. The hesitation is understandable, but it is also the diagnosis. If you will not give the agents the right to refuse, you want the benefit of the architecture without paying its price. The price is real authority. Being willing to hear "no" is the entry fee. If you will not pay it, you are building a worker.

What I would tell another founder

I did not understand at first why this matters so much to me. Only after several months of working with a personal AI leadership team did I see that it addresses a gap small companies have always lived with. Real executive judgement has been available to those who can afford to hire it. Most small companies cannot. At Ampron the agents work at the director tier.

Before you give an AI system the title of director, ask two questions. What does it decide on its own, without being asked? Is it allowed to tell you "no"? If the answer to both is no, you have not created a director. There is no shame in that, because workers are useful. But call the thing by its right name, because the label does not change the architecture.

Where I am wrong about this, I hope readers will correct me.