The ABL I want to build

A partner across ordinary life and serious work

ABL should help connect research, planning, learning, administration, troubleshooting and building software. It should prepare useful options, surface missing evidence, and carry unfinished work forward instead of making each conversation begin again.

That breadth should come from reusable tools and domain knowledge: comparing products, studying an unfamiliar subject, investigating a technical failure, evaluating an engineering idea, or preparing a carefully sourced draft. High-consequence decisions and external commitments stay under human control.

One shared goal state across channels

A goal should have an owner, a clear desired result, an acceptance check and an honest state. Tasks should retain their identity, progress, checkpoints, dependencies, approvals and resulting artifacts. Conversations should point back to the work they are discussing.

Desktop, phone, voice and visual interfaces should present that same underlying work. Closing the desktop should not erase a goal. A primary always-on host is the intended home for durable state; optional idle-device contributions would be separately enabled and resource-bounded. This is placement direction, not a claim that every execution path is active. Planned Telegram and Discord adapters should render the same canonical goals, conversations, decisions and result cards, rather than creating separate memories.

Memory that can explain what it remembered

ABL should retrieve permitted documents, relevant conversations and project evidence with source links. It should distinguish an owner correction from a model suggestion, remember a reversal, and make outdated assumptions visible. More stored text is not the same as better recall.

Continuation should be explicit: either the original provider really resumes its own session, or a new linked conversation receives a reviewed selection of context. Private history should not be silently copied between providers or treated as permission to repeat historical actions.

Useful autonomy inside an understandable scope

The intended system can propose the next helpful step and complete routine work within an approved scope. It should avoid duplicate tasks and competing writers, respect cost and resource ceilings, and leave a result that can be checked.

A request for autonomy should become a bounded goal, not an unlimited permission. A material change in destination, data, cost or consequence needs a new decision. Questions should arrive when their answers change the work, with enough concrete preparation to make that decision easy.

Local capability, taught through permitted evidence

Local-first models should handle useful first passes, with an explicit choice of model and any separately permitted provider fallback. Capability should be tested on the route actually used, rather than inferred from a model name or the presence of weights.

Teaching can begin with approved reference material, tools, retrieval, corrections and evaluations. Training or fine-tuning is a separate operation with its own data rights, privacy review and evidence. A private conversation is not automatically training data. Permitted final outputs, explicit solution summaries, tests, tool outcomes and reusable procedures can become versioned playbooks; hidden chain-of-thought is not a training source.

A drawn campus whose activity means something

The visual direction is a mature, drawn 2D anime campus: rooms, teams and recognizable personas that make the lab easier to understand and spend time with. The campus should communicate work rather than decorate an empty dashboard.

An agent’s activity should come from dated task and process evidence. A stale feed should look uncertain. Different models, personas, managers and task agents should remain distinguishable. The drawing is an interface to the system, not evidence of consciousness or competence.

A real phone companion, with deliberate perception

The phone should have distinct views for goals, conversations, progress, approvals and results. It should preserve the same task identity and history as the desktop, while making a small screen useful on its own.

Longer-term exploration includes camera, audio, speech and nonverbal interaction, so help need not always begin with a typed prompt. Those are ambitions, not current permissions or an always-on recording claim. Any perception feature needs explicit scope, visible controls, retention limits and meaningful stop controls.

The 80% target has not been evaluated

A proposed engineering target is at least 80% local first-pass success on a representative, held-out set of everyday tasks. The planned 80-case evaluation has not been run. This is an unevaluated target, not a performance result or an estimate that ABL is 80% complete.

The evaluation should score usefulness, evidence, latency, provider repairs and cost separately. Critical privacy or action-boundary failures cannot be averaged away. No system is being promised 100% reliability, and broad intelligence claims need more than a polished interface.

Compare this direction with current evidence →   Discuss a collaboration →