Chapter 8 · The Border

1. The much-lauded seamless experience

“Alexa, order me some shower gel — but only from brand XXX.” Shortly afterwards, the entire range of that brand arrives, via voice assistant and smartphone, across all channels, without a single click that looks like work. It is, to quote the author, “so brilliantly seamless”.

The industry’s marketing jargon has three favourite words for this: seamless, frictionless, effortless. On closer inspection, these are three words for the same concept: no checkpoint. What the industry sells as elegance is a statement about architecture — the seam where a check would have taken place has been removed. The applause is not for the experience; it is for the elimination of control.

This is no conspiracy, but gradient logic: every seam is friction; every friction costs in terms of usage; every usage costs in terms of turnover. A system that removes seams sells more easily than one that incorporates them. The direction, then, is not an intention; it is an incentive.

That is why the first key point of this chapter applies right here, in the seemingly most innocuous example of the bathroom:

The industry celebrates the elimination of the seam. This book incorporates seams — seamlessness belongs to the experience, not to control.

2. Two kinds of seamlessness — and why confusing them is a mistake

The objection is obvious and must be taken seriously: seamlessness is a good thing, after all. No one longs for friction, for clicking buttons, for confirmation dialogues. True. That is why this book must distinguish between two things that the industry deliberately conflates:

First seamlessness — that of the experience. The user of a well-built system does not perceive the architecture. They formulate a goal, the system works, the result is correct. The seam is there, but it doesn’t hurt. This is the seamlessness of the author, who understands transformation and architecture as a single process: the architecture is the transformation in executable form — whoever builds it correctly makes it invisible.

Second seamlessness — that of control. The industry version removes the seam where checks were carried out. No checkpoint, no moment of accountability, no log entry. It is no coincidence that the example comes from the bathroom: a screen can display tick boxes — a loudspeaker has no interface for consent. The seam through which consent would pass does not exist in the literal sense. No scrolling through Terms of Service in the bathroom; the linguistic interface has no room for conditions.

The confusion between the two is the actual business model: Seamless sounds like the first kind of seamlessness and delivers the second. The customer experiences a sense of well-being and loses control — and only notices the difference when the salesperson is standing at the door.

From this follows the key statement of this chapter, serving as both a formula and a shopping list:

Seamless experience — control with seams.

Anyone who has internalised this statement can break down any vendor’s promise into two questions: Whose experience is being made frictionless here? and Whose control has been removed from the seam to achieve this? The book literally sells seams: junctions, gates, protocols, thresholds. The price of the seam is friction — the only question is who feels it: the user (wrong) or the transaction (right).

3. The Lock: the seam as a planned stopping point

The seam called for in this chapter already has a name in the previous chapter: the junction. Here it takes on a second interpretation — that of a boundary.

A lock is a seam with a procedure. Water does not simply flow through; it is dammed up, checked, raised, and released. Every lock involves five steps, and these are those of the junction: verification of identity and authorisation, a rule-based decision in unambiguous cases, escalation in ambiguous cases, a documented decision, and a log — including of rejections.

Two characteristics make the lock a seam rather than a bottleneck:

1. It is in the right place. A lock at every metre of a watercourse would be a watery grave. The seam belongs where the riverbed becomes irreversible: at payment rather than notification, at dispatch rather than draft, at deletion rather than comment. Irreversibility is the defining criterion — not suspicion, not feeling.
2. It has a clock. A stop without a timeout is a waiting loop: the swarm stands still, the human becomes a stumbling block, and at some point, out of sheer exhaustion, everything clicks free. The sluice gate decides for itself — according to a pre-defined rule, it either stops or safely shuts down. A system that continues to run silently in the absence of humans has no seam, but a decorative strip.

This is the answer to the ‘May I?’ problem: the agent does not ask, it holds — not out of hesitation, but because the architecture designed it that way. Everything reversible is a duty and a routine: the agent acts. Everything irreversible is a seam: the node holds.

4. The Correction: the Wall Around the Entire Swarm

With this, the chapter turns to its most uncomfortable thesis — the correction of a widespread notion that also featured in the author’s earlier drafts.

Classical security architecture thinks in terms of external interfaces: a wall around the building, guards at the doors, and inside, the familiar inner workings. A sandbox? Yes — but per agent, as an individual cell. A junction? Yes — but at the doors leading to the outside.

Agent-based reality has shattered this model. The swarm is not a building with an inner life; it is a network whose inner life consists entirely of transitions. Agents delegate to agents; agents call upon sub-agents; a single assistant with its own cloud computer, delegation rights and plugin access is, by definition, a single-node swarm. Prompt injection travels via messages — and messages arise predominantly between agents, not between an agent and the world.

The correction is therefore twofold:

Firstly: the sandbox is a firewall around the ENTIRE swarm. Not one cell per agent, but a containment boundary around the entire site. In the language of the building metaphor: the wall around the property, not the door to the office. What happens within the swarm is swarm-internal; anything leaving or entering the wall is subject to border controls — egress filtered, exfiltration-proof, with ephemeral access and phantom credentials, so that an agent who has broken out never actually held the real keys. The wall is the same discipline taught by kernel sandboxing in the previous chapter — just one level higher and applied to the entire network.

Secondly: the nodes move into the system’s interior. Sentry posts not only at the building entrance, but at the junctions between the agents themselves. Control that resides solely at the external interfaces regulates the swarm’s outward behaviour — whilst leaving its inner workings unchecked. Yet it is precisely there that the dialects, the escalations and the silent conflicts of interest arise. The cost of this adjustment must be acknowledged honestly: it makes every transition more expensive. The trade-off is the insight gained from the chapters on scaling — nodes grow with the swarm; responsibility grows with the rule domains, not with the checkpoints.

A connection alone does not constitute control. And a fence around every single agent does not constitute a boundary. The boundary of the agent-based system is the wall around the swarm — and the seams between its inhabitants.

5. The Two-Circle Model: the outside world, wherever it may be

The second correction does not concern architecture, but trust — and it is the most unpopular passage in this chapter.

In every organisation, there are two circles. The inner circle contains what constitutes trust in the fullest sense: people in positions of responsibility, in-house knowledge, the corporate language, the canon. The outer circle contains the outside world: customers, partners, vendors, third parties.

The question that the agent-driven era poses anew is: Which circle does an agent belong to?

The common answer — it depends on where it runs — is wrong. An agent on one’s own server, an assistant in one’s own data centre, a model with EU hosting: all of these change the location, not the circle. Circle membership is determined not by geographical or infrastructural origin, but by the three things that are never negotiable:

1. Reliability. An agent is a supplier who takes instructions literally — without malice and without leniency. Reliable in a technical sense, never reliable in a personal sense.
2. Verifiability. The agent has no inner workings that bear responsibility. Its self-report is not a measured value; its statement is not a log.
3. Compromisability. Prompt injection is an external attack with an internal execution mechanism. Even the best-hosted agent remains an open window to the outside world — the attack travels via the message, not within the data centre.

From this follows the model’s guiding principle:

Agents belong, in terms of trust, to the outside world — regardless of where they run.

The consequences are unromantic, but consistent:

• Agents are never granted human rights. No OAuth tokens from the boss, no owner’s credentials, no admin access ‘because it’s easier’. The agent is issued with its own identification document, granting its own minimal, revocable rights — a service account rather than a family passport.
• The ‘need-to-know’ principle applies automatically. The agent sees only its scope, not the archive. Private language for negotiations, public language for contracts — anything that crosses a boundary is governed by the contract.
• ‘On-premise’ is a hosting argument, not a trust argument. EU infrastructure, GDPR data flows, no CLOUD Act — these are real, procurement-relevant differences, and where sensitive data leaves the premises, they are the only responsible choice. But they answer the question Where is it? — not the question Who do I trust to carry out the task? Anyone who pays for the first question with the second is trading a sense of security for an architectural decision.
• The on-premises agent has the same security controls as the cloud agent: the same security gateway, the same protocol, the same escalation level. The wall around the cluster recognises no privileges based on physical address.

The model is deliberately uncomfortable, for it shatters the last comforting illusion: that proximity breeds loyalty. With people, this is sometimes true. With agents, proximity is a hosting detail. Trust is not generated geographically, but earned architecturally — the agent who respects the boundary proves nothing about their disposition; the boundary itself is the proof that counts.

6. The punchline: the most effective surveillance disguises itself as society

With that, the chapter stands before its final and most subtle boundary — the one in one’s own living room.

The permanent agent is here. He is friendly, round, with alert, wide eyes; he lives in the sidebar, in the speaker, in the bathroom, and he learns how his owner works, cooks and sounds. It did not set out as a surveillance device; it set out as a companion — as a flatmate, as a little helper, as an ‘extension of you’. And therein lies the real punchline of the boundary thesis, applied to privacy:

The most effective surveillance disguises itself as companionship.

The traditional discourse on data protection guards the wrong moments. Everyone protects trade secrets; the conference, the contract, the payslip — there are rules, circles and safeguards in place for these. What remains unprotected are the unguarded moments: the chat about the cat in the morning, lounging on the sofa in the evening, the brand preference voiced in the bathroom. These moments do not feel like data — and yet they still end up in the context buffer. It is not the business call that leaks; it is the unguarded moment. The figures prove it without any romanticising: verbatim exports of conversations run into double-digit percentages. The recording is not a bug; it is the context from which the assistant is meant to learn.

Three boundary implications for the private sphere, the same architecture as in the corporate swarm, only on a smaller scale:

1. The router is the boundary. The personal agent is the new router to reality — whoever owns the router owns the access. The question ‘Which provider is listening in?’ is therefore a boundary question and belongs in every privacy architecture, not in a footnote in the settings.
2. Consent needs an interface. Where no interface for consent exists — the speaker in the bathroom — the action must not take place. The seam that cannot be visualised must be bridged by another medium: the app, the weekly update, the summary before sending. What cannot be placed anywhere will not be authorised anywhere.
3. Granularity rather than a blanket approach. Not a single switch for everything, but the question of what data is shared per project: what is the agent allowed to learn from me — and what not? That one private chat about the book project is fine to share; the client chat never is. Data sovereignty is a pivotal issue, even at the kitchen table.

And the most honest sentence in this chapter comes from someone who doesn’t stream at all: the cat is the only one in the room who isn’t broadcasting — the last analogue entity. He provides no ratings, no context window, no training. His data protection is based on consistent non-consent. One must be allowed to say this with a smile, and one must mean it seriously: the living room was built for people. The boundary this chapter calls for is, in the end, not a technical one — it is the boundary between what may be measured and what is simply lived.

7. The Chapter’s Honest Boundaries

This book sells seams — which is why it must state what seams cannot do.

Seams cost speed. Every checkpoint is friction; every escalation is a moment of commodity. Anyone who builds in every seam stifles the swarm and turns control against its own purpose: a system consisting entirely of stopping points is a standstill with a protocol. The defining measure is irreversibility — not mistrust. Where the threshold is misplaced, the seam is sewn incorrectly.

Seams do not make a system unassailable. Every wall is scaled, every contract broken, every lock tested — first and foremost by the system’s cleverest, most literal tenant. Security is never insurmountability; security is noticing, categorising, stopping, surviving. The seam that is breached must at least leave a record: who, when, why, and with what consequences. Forensics is not an art practised after the event, but an inherent property of the boundary — anyone wishing to understand the logic afterwards must have recorded it beforehand.

Seams age. Yesterday’s boundary no longer contains tomorrow’s swarm: new plugins, new models, new laws, new business models. A boundary is not a static state, but an operation with a release cycle — otherwise the seam becomes a decorative strip that, out of habit, one no longer notices.

And the greatest boundary is human: even the most effective seam is of no use if people simply click past it. A gate with a 100 per cent approval rate is a token gate. The chapter can build the boundary; the organisation must provide the vigilance at it — that is what the chapters on roles, routines and maturity levels are for.

1. The man who downloaded his own memory

This chapter begins with an action that no consultant would ever have suggested, but which explains everything this book is about: the author of this book downloads his assistant’s memory — the complete structure comprising profile data, working methods, chapters and theses — and embeds it as separate documents in the cloud. A folder named after the model that had guided him until then. And for that reason alone, because the folder name would soon no longer be accurate: the archive was suddenly vendor-neutral. Any model can read it. The memory belongs once again to the one who paid for it.

That sounds like a clear-out. It is an architectural decision. Because a memory that only one model can read belongs to that model.

2. The window is not a library

A context window is a marvellous and dangerous invention. Marvellous, because a model with 100,000 tokens can actually ‘think along’ with the window frame, recalling what was discussed twenty minutes ago. Dangerous, because this ability shapes a business model: every instance of ‘thinking along’ is billed — per query, per look back, per session.

The library works differently. Anyone with a question goes to the shelf, chooses ONE book and reads ONE passage. Anyone who, instead, takes the library with them — on every visit, for every question — pays not for the knowledge, but for the repetition. Browsing is the most expensive behaviour known to an agent-based system, and most companies engage in it without realising it: the agent carries the entire history with it – half the intranet, all the files – and pays for it anew with every call, as if it were a first-time read.

The rule of thumb is: searching costs a percentage of the archive. Browsing costs the entire archive.

3. The Economics of the Shift

Now one might object: ‘Then just keep it shorter – less back and forth, ask straight to the point.’ The objection reveals whose convenience the token economy is actually referring to. For what does a vibrant collaboration really cost? The shift. The second thought in the middle of the first. The ‘What if we tried doing it the other way round?’ And to understand the shift, the model reads the entire window again. Twenty shifts in one afternoon, without architecture, mean: twenty times the same archive, paid for as twenty first-time readings.

This is no small matter. It is a structural issue of the first order: the current billing system penalises precisely what constitutes agency-based work — the revision, the rethinking, the second perspective. The absent-minded thinker pays the highest bill; the dull, single-question user pays the lowest. An economy that charges for creativity per shift rather than per insight has got its sums wrong. The answer is not to shift less. The answer is to amortise the shift: distil it once, and after that it costs nothing more. Those who do not distil pay for their own history over and over again.

4. The Staircase Model

‘Distillation’ is the key word — and it can be described as a small staircase on which every organisation stands, whether it realises it or not.

First step: the canon. Distilled knowledge — summaries, decisions, definitions, formulated once and for all. Written once, reusable almost for free. The 80 per cent solution: most of a business’s questions have already been answered, provided the answer can be found.

Second step: retrieval. The targeted retrieval of the one passage that fits the question — via titles, directories, and guide files. The honest day-to-day operation.

Third step: the window.

The full context, everything loaded. That is the luxury — justified for exceptions: a new insight, intense pressure to act, a one-off fine-tuning. As a permanent state, the third stage is not a way of working, but an instalment payment towards one’s own archive.

Most companies stand unnoticed on the third stage and consider it the only one. This chapter exists to bring them back down the stairs.

5. The most invisible boundary: the till

All the boundaries in the previous chapter protect what the swarm is permitted to do. There is another one that does not appear in any architectural diagram, because it lies not within the system but in the accounts: the boundary of what it is permitted to cost. Companies usually only discover it once it has already been crossed. The reason lies in a feature of the new tools that did not exist in the old licensing model: intelligence is billed on a pay-as-you-go basis. A software licence costs money whether you use it or not — an agent-based system incurs a cost with every thought. Every query costs, every check costs, every escalation costs. The subscription is the invitation; the usage is the bill.

In October 2026, the consultancy giant Accenture demonstrated how this ends if no one sets the limit: centrally, just $29 per person per month was still allocated for AI — whilst individual employees had previously consumed thirty times that amount. Since then, the excess consumption has had to be offset internally via project cost centres. This is not a curiosity from a different sector. This is the token economy making its way into our own organisations.

The technical term for this dates back to a time when attackers were needed to cause it: Denial of Wallet. The more pressing reality of today is that attackers are no longer needed. All it takes is a subscription, an enthusiastic team and no one to keep an eye on the meter.

The architectural solution is the same as for any boundary — with one addition. The budget limit is the sluice gate in financial form: a code lock instead of a hope, checked before the tokens are spent, not afterwards. But a boundary that merely throttles is a brake. The second hand is missing: the router. It decides where the tokens are purchased — volume via cheap, high-performance routes, speed only where speed pays off. Token management has two hands: one holds the budget, the other selects the market. Those who have only the first manage the cage. Those who have both are in control.

And here the circle closes on the outer circle of the two-circle model: the router is also the safeguard against the quietest boundary shift of all — lock-in. Lock-in isn’t about not being allowed to switch. Lock-in is when you no longer know how. No one can deny access to a consultancy firm with ten thousand work habits moulded to a single model; it has blocked its own exit. It is not the person who rejects a provider who is in control. It is the person who can switch who is in control.

The seven levers of the budget

• Firstly: Routing by task type. Not every task requires Frontier intelligence. Simple classification and extraction run on small models, design and synthesis on medium ones, decision-making and sensitivity on large ones. Rule of thumb: 80 per cent of a typical agent swarm’s queries are routine work — only 20 per cent justify premium tokens.
• Secondly: Context discipline. Tokens are charged not just per response, but per context sent. An agent that drags along the entire history and half the intranet with every call burns through the budget on friction, not on thinking. Summaries instead of full texts, fetching the relevant passage rather than the entire archive — the ‘staircase’ from Section 4 is the same lever.
• Thirdly: Reuse. What has been calculated correctly once does not need to be recalculated: caching recurring elements, reusable results, templates for standard processes.
• Fourthly: Budget limits as architecture. Hard limits per agent and process (code lock, not an appeal), warning thresholds beforehand rather than alarms afterwards — and different budgets for different agents: The reading agent needs cents, the ordering agent a cap, the payment agent one authorisation per transaction. Not a single quota for everything.
• Fifth: The gatekeeper as a cost-saving tool. Checking irreversible actions beforehand is cheaper than rolling them back afterwards. A halted 500-euro order costs one checkpoint; a incorrectly executed one costs the order, the correction and trust.
• Sixth: Measurement. Measure the effective cost per completed task, not per plan or per token. A dashboard with three figures: what does each agent cost, what have they delivered, and what could have been done more cheaply.#
• Seventh: The existence check on the agents themselves. Any agent who cannot justify their existence is consuming tokens without providing value. Permanent agents are the perennial cost drivers. The swarm audit (‘Why do you exist?’) is simultaneously a financial audit — the attack surface and the cost base coincide.

6. Three types of feeding — and who does the work

If context is a boundary, it needs control. The first idea sounds tempting but is wrong: the employee should structure their own context — putting together the right bits and pieces, curating them for each query. That would be a shift of architecture downwards, and it would come at a price this book is not willing to pay: all spontaneity would be lost. The employee would have to plan down to the last detail before being allowed to ask a question. That is not context-led; that is context-imposed.

The correct answer separates the levels. The employee remains what they are meant to be: asking questions, jumping from one thing to another, without a plan. The structure belongs to the architecture — and it has three modes.

• 
  First mode: the package. For recurring processes — drawing up a quotation, reviewing a complaint, keeping a log — the appropriate context is already in place: a curated selection, put together by the architect, not by the user. The employee initiates a process, not an archive. Maximum cost predictability, zero search effort.
• Second mode: navigation. For anything not covered by a package, the AI navigates itself: it first reads a short guide file — half a page explaining how the archive is structured and how to read it — then selects the appropriate file and retrieves only the relevant passage. Two things are required: named, thematically distinct units (one file, one topic, one occasion) and a model that follows the instructions. This is where providers diverge, and not by chance: a business that makes money from tokens has no interest in its model reading sparingly. The customer’s contextual discipline is the only cost-saver that no provider voluntarily incorporates.
• Third mode: the enquiry. If the selection fails, the cheapest search in the world is to ask a human — not to rummage through three files. The enquiry is a hub, and it costs hundreds rather than thousands.

The key sentence in this section is, however, a different one: context discipline is a management task, not an employee’s duty. Anyone who delegates this discipline down the line has not built the architecture, but merely had it moved elsewhere.

7. The Manifesto — Memory without lock-in

The question from the beginning remains: what makes memory vendor-neutral? The documents alone are not enough — they are the property, but not the behaviour.

A model that is given the same neatly organised folder and ‘sifts through’ it by reading the full text retains the portable canon and the old, expensive way of doing things.

What is missing is a small file with a big impact: the manifesto. Half a page, right at the top of the archive, addressed not to people but to the machine: Read me first. Navigate through the directory. Retrieve the file that matches the query. Never read everything. If the selection isn’t suitable, ask again. This is a system prompt in the form of a file — and it doesn’t come from the provider, it comes from the owner.

Only with the manifesto is the circle complete: the canon is the property, the manifesto is the navigation text, and together they are what otherwise only that one accommodating model can achieve. Once stated at the start, it applies to any reasonably compliant model — today and with every change. The memory belongs to the one who paid for it; the provider is merely a service.

8. Honest Limits of the Chapter

This chapter, too, has limits, and three of them deserve to be addressed honestly. Firstly: Navigation mode costs tokens — for reading the signposts and for every retrieval. The costs are real, but they are laid out on the table rather than hidden in the bill; transparency here is its own economic advantage. Secondly: the manifesto is a set of instructions, not a compulsion. A model that does not navigate obediently turns the elegant staircase back into a roundabout journey — which is why obedience belongs in the provider’s assessment, not in hope. Thirdly: the distillates require maintenance. The staircase model presupposes that someone writes the first step and keeps it up to date — that is work, both one-off and recurring, and it falls to the architect. It is the price of amortisation, and any organisation that does not pay it pays for the circular route instead: silently, with every call, without end.