Tags: #ai #agents #architecture #localfirst
When someone brings a half-formed idea to an AI assistant, the fastest answer is not always the most useful one. They may need to see a few different ways to begin, understand what each way assumes, and keep the choice for themselves.
That is the small experience I am building with Aribito: a public-facing, local prototype of an AI team that helps a person choose one next step.
One request, three ways to begin
Imagine a developer who has a prototype and wants to show it to a first-time visitor. The goal is simple: make the first encounter understandable without promising features that do not exist.
Aribito gives the same request to three separately attributed roles:
- Kael looks for structure: what needs to be explained, and in what order?
- Sora looks for a small trial: what could the developer test with one visitor, and what should they observe?
- Hana looks for wording: what short introduction would help that visitor know what to expect?
Those are intended perspectives, not a guarantee that every model response will meet them. The following is an illustrative example, not a transcript of a live run:
Kael: Start with a one-page guide: purpose, what the visitor can do, and what happens after they choose.
Sora: Rehearse the explanation with one person. Ask where they hesitate before changing the prototype.
Hana: Write a two-sentence introduction that tells the visitor this is a local demo and that they may hold their decision.
The person can read the proposals, select one, or put the decision on hold. Selecting a proposal produces a receipt tied to that choice. It does not carry out the suggested work.
What the prototype actually does
The current Aribito MVP is a local CLI flow. It can make separate local-model calls for public roles, keep their contributions attributed, let a person choose or hold, and report that no save, send, connector, external action, durable memory, or model-weight update took place in the demonstrated flow.
The separation is at the application level. It is not a claim that each role runs in its own operating-system process or security container. The demo uses public profiles and session-only context; it does not load private persona memory.
One difficult lesson has already appeared in testing: a proposal can be well formed and still invent a button, menu, or interface the user never described. We do not treat a valid shape as a useful answer. If the evidence or role fit is insufficient, the candidate needs review rather than automatic promotion into something the person can select.
There is no public signup or production connector to announce here. The API, approval interface, and persistent memory flow remain future work. The useful question for this stage is smaller: can a person see genuinely different, grounded starting points and choose with a clear record of what happened?
Why I want to keep building it
I want AI collaboration to make a decision easier to understand without making the decision on a person's behalf. Aribito is my attempt to turn that idea into a product people can eventually use, beginning with one honest local experience.
If you were bringing one uncertain task to a small AI team, what would you want the team to help you decide first?
Author's direction and publication decision: Masato Kato. Structure and prose: Codex editorial assistance. The role descriptions and illustrative proposals above are editorial examples, not quotations from live model outputs or claims of stable role behavior.