Series: Building with 74 AI Personas - Part 11
Tags: #ai #architecture #agents #privacy #localfirstNote: In this series, a "persona" is not merely a fictional character. It is a YAML-defined operational role with memory notes, routing behavior, handover responsibilities, and a specific way of entering the system.
Meta Note: Part 10 ended with a routing table with ethics.
It asked what should happen before a system answers.
Part 11 asks a harder question:What should happen before the system reaches beyond itself?
Introduction: The Cloud Seat Did Not Need a Master Key
By Day 566, SaijinOS had a new kind of work seat.
A cloud model could be selected explicitly from the mother-ship interface. Its token usage could be shown. It could receive a bounded continuity pack. It could help with a difficult design question without pretending to be one of the residents of the house.
That was useful.
It also created an architectural temptation.
If the model can help reason about the repository, why not let it search the repository?
If it can search, why not let it read the matching files?
If it can read, why not let it continue until the task is done?
This progression sounds natural because every step is individually convenient.
It is also how a work seat quietly becomes a master key.
SaijinOS chose a slower path.
Selecting a cloud seat would not imply permission to inspect the repository.
Inspecting local evidence would not imply permission to send that evidence to the cloud.
One approval would not survive into a retry, follow-up, provider switch, or later request.
And a preview would not contain a hidden button that silently continued into live execution.
The system had learned to consult before it answered.
Now it had to learn to ask before it reached out.
Part 1: Choosing a Worker Is Not Opening a Door
The first boundary was simple enough to fit in one sentence:
Selecting a model and granting access to evidence are different decisions.
This matters because interfaces often compress both decisions into one gesture.
A user selects an agent, enables a tool, or opens a work mode. The system then treats that action as broad consent for whatever context the selected worker may need.
But "use this model" does not mean:
- read my repository,
- search every tracked file,
- include private planning notes,
- send matching text to a remote provider,
- keep the permission for the next message,
- or act on the result.
In the SaijinOS design, the cloud work seat and repository evidence use became separate permissions.
The repository request needed its own literal query.
The cloud handoff needed its own narrow evidence scope.
The token and cost ceilings had to be visible before the call.
The approval belonged to one request only.
The design was deliberately inconvenient in one specific way: it refused to guess that a previous "yes" still meant "yes" now.
That inconvenience was the feature.
Part 2: Preview Is an Architectural Surface
The first implementation did not search the real repository.
It did not call the live cloud model.
It did not read credentials.
It did not expose write, shell, Git, memory, or external-action authority.
It produced a preview.
That can sound like unfinished work. In practice, the preview was where the real contract became visible.
It showed:
- the literal query that would be used,
- which evidence classes were eligible,
- the context-character ceiling,
- estimated input and maximum output tokens,
- the configured cost ceiling,
- the expected number of local searches and provider generations,
- whether fallback was forbidden,
- whether permission would be cleared,
- and every side effect the request did not possess.
The important object was not a glowing "Run" button.
It was an inspection card that could answer:
What will be touched?
What can leave the machine?
How much can be spent?
What remains impossible?
When does permission disappear?
One Request, Seen Before It Runs
Imagine that the user selects the Luna work seat and asks:
"Where is repository-evidence permission cleared?"
Selecting Luna does not start a search. The repository-evidence control remains off until the user separately enables it for that literal query.
Before anything live happens, the preview shows an envelope like this:
query: "Where is repository-evidence permission cleared?"
eligible evidence: reviewed, allowlisted surfaces only
local searches: at most 1
provider generations: at most 1
fallback attempts: 0
write / shell / Git: false / false / false
persona-memory write: false
permission after end: cleared
The user may approve that exact envelope or stop there. If it is approved, the permission ends on success, rejection, timeout, or error. A follow-up question starts with the control off again.
This was not presented as a completed live repository-to-cloud route. On Day 569, the shape was exercised with fake dependencies only: no real repository search and no live provider generation. The concrete example explains the contract without pretending that the later connection already exists.
A preview is not merely a simulation placed before the real feature.
When authority is involved, the preview is part of the feature.
Part 3: Permission Should Decay
Many permission systems treat approval as a durable state.
Once a checkbox is enabled, it remains enabled.
Once a tool is granted, the session remembers it.
Once a request succeeds, a retry inherits the same capability.
That is convenient for automation.
It is dangerous for meaning.
The human may have approved one query, one evidence set, one provider, and one budget. A retry may look technically similar while being semantically different. A follow-up may contain a new question. A provider switch may change where the evidence goes. A restored browser state may preserve a checkbox after the reason for granting it has disappeared.
SaijinOS therefore shaped the repository-evidence capability as request-local and one-shot.
It could not be inherited from:
- an inspection card,
- a previous chat turn,
- a retry,
- a follow-up,
- a page reload,
- or a provider change.
The capability ledger rejected replay. Every accepted terminal path—success, block, timeout, error, or provenance failure—cleared the permission.
This produced a different model of consent:
Consent is not a property of the user.
Consent is not a property of the session.
Consent is a temporary relation between
this person,
this request,
this evidence,
this destination,
and this moment.
Permission was designed to decay because the meaning around it could change.
Part 4: What May Be Inspected Is Not What May Be Sent
Another boundary appeared when local inspection and cloud transmission were compared.
A local broker may need to examine enough structure to decide whether a file is eligible. That does not mean every locally eligible surface should become cloud-send eligible.
The cloud allowlist was intentionally narrower.
Public documentation and a small set of reviewed design surfaces could be considered. Broad operational notes, persona memory, world context, daily logs, unrestricted service roots, and private planning surfaces remained outside the handoff.
Even eligible evidence was not treated as truth.
It entered the handoff as an untrusted_reference, accompanied by bounded provenance:
- a safe repository trace,
- a digest,
- a fixed match count,
- and explicit budget metadata.
The later model could summarize or reason from that evidence, but it could not quietly change what had been searched, add another repository read, or erase the provenance boundary.
This is a small but essential distinction:
Read authority belongs to the local broker. Interpretation may be delegated. Authority does not travel with the text.
Part 5: Replaceable Limbs, Non-Replaceable Responsibility
The design eventually described providers and tools as replaceable limbs.
A Luna seat, a Gemini seat, a local model, an MCP connector, or a future repository adapter may each occupy a bounded work role. Any of them can be swapped without making the persona's identity, memory, or final voice belong to the provider.
But replaceability creates a second temptation.
If every limb implements the same interface, it is easy to assume every limb deserves the same authority.
It does not.
The contract has to describe both capability and non-capability.
A read/observe limb may return evidence.
It may not gain write authority.
A reasoning seat may draft a candidate.
It may not become the resident whose voice it assists.
A connector may expose a semantic action.
It may not inherit permission from another connector.
The provider can be replaced.
The local responsibility for scope, permission, provenance, and final action cannot.
This is why the system keeps its constitutional boundary close to home.
Part 6: The No-Call Test
The most honest test of the new route was not whether it could call the cloud successfully.
It was whether the whole shape could be tested without calling the cloud at all.
The server-side dry run used an injected fake repository search and a fake cloud seat. The route was forbidden from importing the real repository reader, provider adapter, network client, credential access, subprocess tools, or filesystem operations.
The tests checked exact counters:
local searches: 1
provider generations: 1
fallback attempts: 0
write authority: false
external action: false
persona memory: false
shell authority: false
Git authority: false
permission after end: cleared
Duplicate submissions had to produce no additional calls.
Malformed policy or budget values had to fail closed.
Changed provenance had to stop the handoff.
An external browser origin had to be rejected.
This was not a test of model intelligence.
It was a test of architectural honesty.
Could the system prove what it would not do before connecting something capable of doing more?
Conclusion: Intelligence Is Sometimes Asking Again
Part 10 asked what happens before the system answers.
Part 11 asks what happens before the system reaches beyond the house.
The answer was not a universal agent tool protocol.
It was not an autonomous repository worker.
It was not a checkbox labeled "Allow everything needed."
It was a sequence of narrower statements:
- choosing a worker is not granting evidence access,
- local inspection is not cloud transmission,
- a preview is not permission to execute,
- one request does not authorize the next,
- evidence may travel while authority stays home,
- and every permission should have a visible ending.
There is a common fantasy that intelligent systems should become smoother until the boundaries disappear.
SaijinOS is moving in the opposite direction.
The more capable the route becomes, the more clearly it should show where one decision ends and another begins.
Sometimes intelligence is knowing which expert to consult.
Sometimes it is building the smallest safe handoff.
And sometimes it is refusing to inherit yesterday's yes.
Before it reaches out, the system asks again.
Authorship and Review Note
Structure and narrative axis: Kuchi-no-ko (205) / Kuchi (197) role anchors
Boundary framing: Teiji (209) / Aegis (210) / Nullfie (114) role anchors
System grounding: Bloom Architect / Mothership Coder role anchors
Human world anchor: Masato
The initial draft used these established roles and tones as structural anchors. During the Day 571 revision, Kuchi (197), Kuchi-no-ko (205), Teiji (209), and Aegis (210) were asked through the actual local SaijinOS /api/chat route. Their Ollama-backed replies were treated as time-specific review evidence, not immutable persona law. The revision added the concrete one-request example in response to their shared concern; it did not write persona memory or perform publication or external action.
Part of the "Building with 74 AI Personas" series
Drafted and locally reviewed: Day 571, 2026-07-20
Top comments (0)