Architecture is not a diagram but a set of boundaries. These are the boundaries that let a one-person company run on AI without AI ever being allowed to send, book money or publish anything.
In 2025 I wrote about how I use AI in practice: coding, troubleshooting, documentation. Everything I do with my hands, only faster. That still holds.
This is its sequel, and it is written as a system description: what the layers are, what each is responsible for, where the boundaries run, how information moves and what happens when something fails. The system is an internal tool I built for myself during 2026 to run the everyday business of a one-person company. A small whole, but the same questions as in any organisation wondering where AI belongs. The AI layer is built and ready, but its functions are switched on one at a time, and the model runs locally or in a service located in the EU.
Starting point: five systems, one person
The administration of a one-person company is the same as a larger one's, only without the people around it. Preparing outreach, writing content, booking receipts, following up invoices and logging hours are each small, but together they take a day a week.
At first I bought ready-made tools and ended up in the same situation I see in other organisations: five systems, five logins, and the same customer in three places in different shapes. The work did not shrink, it moved into the gaps between the systems.
I built one. Not because home-grown is always better, but because I wanted to decide for myself where AI is allowed to act. In an off-the-shelf product someone else draws that line, and they rarely tell you where.
Four principles of the structure
Before a single function, I decided four things that I have not changed since.
- AI for judgment, code for logic. Classifying, drafting and summarising are AI's work. Routing, arithmetic and retries are code's work. If code can answer, code answers.
- One gate for side effects. Nothing is sent, booked as money or published without passing through the approval queue. Approving is a separate event from preparing.
- Memory is compartmentalised by structure, not by prompt. Personal and customer work live in different compartments, and the boundary is implemented in the API. AI is not asked to "keep quiet about" something, because a request is not a boundary.
- Every AI call is observable. Which model, for what purpose, what it cost, how long it took, with which settings. Without this you know neither what AI does nor what it costs.
The principles sound obvious. In only a few environments I have seen is even one of them implemented in the structure. They exist as guidelines. Guidelines are followed when there is time.
The layers and their responsibilities
The system has six layers. Each has one responsibility and does not reach into another's territory.
| Layer | Responsibility | What it does not do |
|---|---|---|
| API | Receives the request, checks its shape, returns the response | Holds no business logic |
| Services | Business logic by function: customers, outreach, content, finance, time | Does not call external systems directly |
| Integrations | Fetch information from outside: registers, websites, email, calendar | Decide nothing, interpret nothing |
| AI layer | One route for every model call, model-agnostic; the model runs locally or in the EU | Does not know who is calling it or why |
| Memory | Compartmentalised store of what the system knows | Does not mix compartments |
| Approval queue | Gate for every side effect | Executes nothing; approval is a state change |
Two of these matter most for the architecture. Integrations are dumb pipes: they fetch and return and never decide. And the AI layer is one: no model call is made around it, so switching from one model to another is a matter of one layer, and every call passes through the same logging.
The boundary: where AI is placed
AI is not a layer the others use freely. It is placed at precisely named points, and each point has a name, a purpose and a switch that is off by default. Today most switches are still off: the layer is built and tested, and the points are opened one at a time as the log shows they work. The model is local or in the EU, and it can be swapped behind one layer. Below is what each point does when its switch is on.
Outreach preparation. Code gathers the public facts about a company: the basic register data, the financial statements, the website and the open positions. AI reads them and writes a hypothesis about where the company's IT is probably stalling, plus one opening question. I make the call myself. Automated email I dropped entirely: a precise guess on the phone works, a mass message does not.
Content. AI proposes an article outline, writes the first version, translates, and drafts a LinkedIn post from a story bank where my own cases are written out. Publishing is the approval queue's business, and on LinkedIn I post myself.
Finance. Code reads the amount and the vendor from a receipt. AI only suggests the category. An invoice that matches none of the layouts code recognises, AI reads and proposes a booking for, and that too sits behind a switch. It summarises the month's figures into one paragraph. The figures themselves, profit, VAT, receivables ageing and cash runway, are computed in code, and AI may not touch them. A figure that is almost right is more dangerous than no figure at all.
Time. At the end of the week AI tells me where the time went, gathered from computer and browser use and from hours logged per customer. The answer is not always flattering.
One line, one answer. When I type or dictate one line into my phone, AI fetches the answer from the application's data or prepares a matter for me to decide. It has named tools at its disposal, each marked as either reading or preparing. There is no executing tool. Calls have a count and time limit, and if the limit is hit, it says so and does not retry.
Data flows: how a request travels
One example is enough, because the others travel the same route. This is how a request moves when the point's switch is on.
- I dictate into my phone: "draft a check-in message for this customer".
- Speech becomes text through the AI layer. The call is logged.
- The service layer fetches the customer's data from the customer compartment of memory. The personal compartment is not even reachable at this point.
- AI drafts the message. The call is logged.
- Code checks the draft: no personal content, no figures absent from the source, no forbidden phrases.
- The draft goes into the approval queue. My phone shows a "ready" notification.
- I read, edit or reject. Only approval opens the send, and the send is its own step, logged separately.
Seven steps, of which AI does two. The other five are code or me. That ratio is deliberate.
When something fails
Architecture is measured by what happens when something does not work. In a diagram nothing ever fails.
- The model does not answer, or answers empty. Every call has a time limit. An empty answer is an empty answer, not an invented one. The request is marked failed, not left hanging.
- Work is left half done. If a background job crashes, a separate check finds the unfinished ones and marks them. Nothing runs twice, because every request has an identifier, and the same identifier a second time returns what was already done.
- AI produces something it should not. A check in code before the queue. If it is caught, the request does not proceed, and the reason is visible.
- A compartment leaks. It cannot, because the boundary is in the API: customer handling has no path to the personal compartment.
So failure has a named handling, and it is code. AI is not asked to fix its own mistake.
What is measured
When the switch is on, at the end of the month I see to the euro what AI cost and for what purpose. I see which function uses the most calls, which model handles what, and how many drafts were approved as they were, edited or rejected. The last figure is the most important: it tells whether a point deserves more autonomy or not.
In most organisations where AI has been "rolled out", that figure does not exist. Then there is no measure of whether it works. The bill arrives all the same.
Decisions I made deliberately
Architecture is the sum of decisions. I wrote these down so that later I know why things are the way they are.
- Automated email out. The whole sending chain was removed, not just switched off. If it ever returns, it is a new decision, not the reopening of an old one.
- One user, but the structure does not assume it. Every data row has an owner, even though there is one owner. The price was small, and it saves a later rewrite.
- Switches off by default. Every function with a side effect is off until I switch it on, and the switching leaves a history.
- Arithmetic is never AI. This is the only rule I have not even considered breaking.
Next steps
The direction is bounded autonomy. AI gets to do low-risk things without a separate approval: log dictated hours, move an outreach contact to the next stage once the call is marked made. Every action stays in the log, and the limit is raised one step at a time as the approval rate shows that no errors appear.
After that, summaries across functions: "show me everything about this customer", from customer data, hours, invoices and messages in one place. And observations about my own way of working: where the time repeatedly goes and what would be worth changing.
The next integration is outbound: finance files a return with the tax authority straight from the tool. That too passes through the same gate, and its implementation is boring from an architecture standpoint, which is the point.
The order does not change. AI prepares, I decide.
What to take away
The structure is not a one-person-company peculiarity. The same three conditions hold before AI is worth letting into anything, whatever the size:
- Data has a source. If the same customer is in three systems in different shapes, AI summarises the contradiction more elegantly; it does not remove it.
- The process has an owner. AI can prepare a decision, but someone's name has to stand behind it.
- Side effects have a gate. Sending, booking and publishing pass through a person until the log shows the gate can be opened a step.
The conditions are boring, and that is exactly why they go undone. Choosing a model is more interesting. I wrote separately about why data and processes still come before AI: First clean data and clear processes, then AI.
AI prepares, a person decides. The order sounds cautious. It is architecture: the only order in which a mistake is caught before it costs something.