A personal AI agent that remembers how you learn—and keeps working between conversations.
Tell your agent what you are working toward. Give it the learning materials and permissions you choose. It remembers your attempts, prepares focused practice, plans around your commitments, and follows up—with you in control.
Coming Soon · Exploring demand. This repository contains a product proposal, proposed architecture, and AI-generated interface concepts. There is no runnable application, released agent, public beta, or installation package yet. Every capability below is planned. We will use GitHub stars and the substance of incoming feedback to decide whether to build, and what to build first. There is no committed launch date.
Would you use this? Star the repository or tell us your use case.
AI-generated concept, not a working product. Nomi is an example companion identity; all people, work, dates, and results are fictional.
- The idea
- The interaction: a personal agent first
- Interface previews
- Planned capabilities
- A day with your agent
- How the learning loop would work
- Proposed architecture
- Memory and data model
- Permissions, reliability, and family controls
- Scope and roadmap
- How we would evaluate it
- FAQ
- Help shape the product
An incorrect answer can be the start of an ongoing learning relationship. The agent should remember the original work, what the student tried, what explanation helped, and what still needs checking. When the conversation ends, the learning goal should persist.
Our proposed starting point is a mistake-driven personal learning agent for students, with a focused first pilot for families with children studying grades 4–6 mathematics. The longer-term direction is a student's own agent across learning materials, revision, exams, and study commitments.
| A student or family needs… | The intended agent behavior |
|---|---|
| “I keep making a similar mistake.” | Connect evidence across attempts, propose an explanation, and check it with the student. |
| “I don't know what to review today.” | Prepare a short session from recent evidence and reviews that are due. |
| “My exam is next Wednesday.” | Draft a plan around the student's actual availability and ask before changing connected tools. |
| “Help me keep going without constant prompting.” | Work in the background, follow up at an agreed time, and adapt after new attempts. |
| “What actually changed this week?” | Summarize independent attempts, unresolved topics, and next steps with links to evidence. |
The ambition is continuity: one student, a persistent agent identity, long-term learning memory, and work that continues between conversations.
The main entry point is a conversation with your own agent, using text, voice, photographs, and files. This is a Muse-like personal-agent model: an ongoing relationship, durable goals, background execution, useful artifacts, proactive messages, and explicit approvals. The visual identity is original; no affiliation or integration with Muse is implied.
- Tell it a goal. “I have a math exam next Wednesday. Help me get ready without colliding with homework.”
- Let it work. The agent reads authorized evidence, recalls prior attempts, drafts a plan, and prepares practice. You can close the app while authorized jobs continue in the cloud.
- Review meaningful updates. The conversation shows a plan, an evidence note, a practice session, or a permission request—not a stream of internal tool logs.
- Act in context. Approve a calendar change inline, open a practice artifact, correct an inferred misconception, or ask to change the plan.
- Return to continuity. The agent explains what changed since you left and what needs your attention.
Dashboards are supporting views. A mistake library helps inspect source work; a plan view helps adjust time; an activity view explains background work; a family view summarizes progress. Students should not have to navigate a dashboard every day to tell the agent what they need.
flowchart LR
S[Student: text, voice, photos] --> C[Personal agent conversation]
C --> G[Persistent goals and learning memory]
G --> W[Background work]
W --> R[Proactive update or approval request]
R --> C
C --> A[Practice, plan, or evidence artifact]
A --> F[Student action and feedback]
F --> G
G -. inspect when useful .-> D[Supporting overview and family views]
The concept companion, Nomi, is a small snow fox with a soft silhouette, lavender ears, and an apricot neckerchief. It gives the agent a recognizable presence in conversation, quiet working states, and encouraging practice feedback. The intended tone is warm, patient, and age-appropriate. The student can disagree, pause, or leave without guilt-based messages.
The visual direction pairs warm porcelain surfaces, restrained lavender accents, fine typography, and carefully spaced controls. The companion supports attention; it does not compete with the learning task. Name, appearance, and customization remain design proposals.
All images are AI-generated design concepts with fictional sample data. They show intended interactions, not implemented features or measured learning outcomes. Interface wording and visual details may change. English UI is used in these concepts; product localization is not yet decided. The final generation prompts and design notes are in docs/design-concepts.md.
Talk to Nomi, attach real work, and continue an existing goal from your phone. A plan or practice session opens directly from the conversation.
See what happened while you were away. An external change should state exactly what it will do, then wait for the appropriate approval.
Open the source attempt, inspect a tentative misconception, correct the agent, and work through a guided step. Student work stays distinct from AI-generated explanations.
A calm summary helps a parent understand what was practiced, which topics need another check, and what the agent proposes next. Any sample values are illustrative; small sets of different questions do not establish a learning effect.
Status for every row: Coming Soon / proposed. The table describes intended behavior, not existing software.
| Capability | Intended behavior | Important boundary |
|---|---|---|
| Personal agent identity | A continuous conversation, goals, preferences, and working context for each student. | Memory can be inspected, corrected, and deleted. |
| Multimodal capture | Photos, screenshots, documents, typed questions, and student working. | Unclear recognition is confirmed before becoming trusted evidence. |
| Cross-attempt memory | Relate repeated mistakes, concepts, interventions, and later attempts. | An inferred cause remains a hypothesis until supported. |
| Guided tutoring | Offer hints, questions, diagrams, and step-by-step support. | The student supplies the learning work; assisted answers are recorded separately. |
| Focused daily review | Prepare roughly 3–5 questions within an adjustable time budget. | Workload, readiness, and notification preferences constrain the plan. |
| Adaptive practice | Change topic, difficulty, or explanation after new evidence. | New and delayed independent attempts matter more than repeated answers. |
| Exam preparation | Work backward from a date and known commitments. | External calendar writes require scoped approval. |
| Background execution | Continue authorized tasks after the app closes; report meaningful results. | Durable job state, cancellation, execution limits, and recovery are required. |
| Connected tools | Read selected materials and availability; perform approved changes. | Individual connectors depend on provider support and will be announced separately. |
| Learning artifacts | Open practice, evidence, plans, and reports from the conversation. | Supporting pages share the same state as the agent. |
| Family collaboration | Guardian setup, agreed summaries, permissions, and review controls. | Sharing scope is explicit; family reports are not unrestricted access to every conversation. |
| Portable records | Export learning records and remove connected data. | Retention and deletion behavior must be defined before a pilot. |
Voice interaction, broader subjects, a general browser tool, and third-party agent interfaces are longer-term possibilities. There is no claim of an available mobile app, messaging integration, MCP server, dedicated VM per student, or supported third-party connector today.
Illustrative scenario, not a product demo or study result.
In the evening, a student shares a worksheet and their working. The agent asks them to confirm one unclear fraction, links two attempts involving common denominators, and proposes a short diagnostic question rather than declaring a cause with certainty.
Later, an exam goal is added in conversation. The agent prepares a two-session revision draft in the background. It explains why those topics were selected and asks before adding the sessions to a calendar. If approval is absent, the plan remains a draft.
At the agreed time the next day, the agent sends a concise update with a practice entry point. The student answers; a hint is available if needed. The system records whether the attempt was independent or assisted and adjusts the next review.
At the end of the week, an authorized family summary links to relevant attempts, names uncertainties, and proposes the next focus. Missed practice triggers a gentle replanning option, not escalating pressure.
The proposed loop separates source evidence, interpretations, intervention, and later checks. A correct answer after a hint is useful, but it is different evidence from solving a new question independently days later.
flowchart TD
A[Capture source work and student attempt] --> B{Recognition clear?}
B -- No --> C[Ask for correction or a clearer source]
C --> A
B -- Yes --> D[Link concepts and prior attempts]
D --> E[Propose a misconception hypothesis]
E --> F{Enough evidence?}
F -- No --> G[Ask a diagnostic question]
F -- Yes --> H[Choose a focused intervention]
G --> H
H --> I[Explain, hint, and practice]
I --> J[Record attempt and assistance used]
J --> K[Check with a new independent question]
K --> L[Update evidence and review schedule]
L --> M[Delayed check and authorized summary]
M --> D
The model proposes; application code owns durable state. A language model can explain, generate candidate questions, and suggest an intervention. Validated code should enforce permissions, record attempts, calculate due times, transition jobs, and deliver notifications. Question checking and mathematical validation must be part of the content pipeline before generated practice reaches a student.
Mastery indicators would summarize observed evidence with sample size, timing, and assistance context. A model-produced score would not be presented as a calibrated probability of knowledge or proof of improvement.
This is a target design, not an implemented stack. A personal agent needs persistent identity, memory, and recoverable work; it does not require an always-running language-model loop. Timers and events can wake a bounded worker when needed.
flowchart TB
subgraph Surfaces[Student and family surfaces]
Phone[Mobile conversation and artifacts]
Web[Desktop conversation and workspace]
Family[Authorized family view]
end
Phone --> API[Authenticated application API]
Web --> API
Family --> API
API --> Policy[Identity, consent, and policy checks]
Policy --> Agent[Personal agent orchestrator]
Policy --> Views[Artifact and overview services]
Agent --> Memory[Evidence-backed learning memory]
Agent --> Skills[Learning skills: capture, coach, practice, plan]
Agent --> Jobs[Durable job queue and scheduler]
Jobs --> Worker[Bounded agent worker]
Worker --> Skills
Worker --> Gateway[Permission-checked tool gateway]
Gateway --> Connectors[Authorized materials, calendar, notifications]
Gateway -. later, if justified .-> Sandbox[Isolated browser or computer session]
Skills --> Models[Model adapters and content validation]
Memory --> DB[(Relational records and source storage)]
Views --> DB
Worker --> DB
Worker --> Outbox[Delivery outbox]
Outbox --> Phone
Outbox --> Web
Gateway --> Audit[(Approval and action audit)]
| Layer | Responsibility |
|---|---|
| Conversation and artifacts | Streaming conversation, attachments, voice entry, practice, plans, evidence, and contextual actions. |
| Agent orchestration | Persist goals, retrieve relevant memory, choose allowed skills, and prepare proposed actions. |
| Learning engine | Keep source attempts, concept links, review rules, assistance context, and validated practice. |
| Durable runtime | Persist jobs, schedule wakeups, retry transient failures, cancel work, and bound cost and execution. |
| Tool gateway | Enforce student scope and current grants at execution time; verify external results. |
| Data and audit | Isolate student records, version derived memory, retain provenance, and record approvals and actions. |
For an initial pilot, structured APIs and a durable task queue would be preferable to general computer automation. A browser or isolated cloud workspace would be added only for a justified task and behind the same permission boundaries. Per-student identity, memory, and credentials must remain isolated even if compute workers are shared.
Technology choices, hosting, model providers, mobile delivery, and connectors are undecided. This repository intentionally contains no deployment instructions for unbuilt software.
sequenceDiagram
actor Student
participant Agent
participant Jobs as Durable runtime
participant Policy as Permission service
participant Calendar as Calendar connector
Student->>Agent: Prepare a plan for Wednesday's exam
Agent->>Jobs: Save goal and enqueue a planning job
Jobs->>Agent: Return plan artifact and proposed calendar change
Agent-->>Student: Show exact events and request approval
alt Student approves and grant remains valid
Student->>Policy: Approve this scoped action
Policy->>Jobs: Release approved action
Jobs->>Policy: Recheck grant, scope, and action version
Policy-->>Jobs: Allow
Jobs->>Calendar: Create approved events with deduplication key
Calendar-->>Jobs: Return event identifiers
Jobs->>Calendar: Verify resulting events
Calendar-->>Jobs: Confirm stored result
Jobs-->>Student: Report completion and event links
else Declined, expired, or revoked
Policy-->>Jobs: Block the external write
Agent-->>Student: Keep draft and offer next steps
end
The proposed model separates an uploaded source from a student's attempt, and separates an attempt from an agent's interpretation. This makes it possible to correct OCR or a misconception without rewriting the original record.
erDiagram
STUDENT ||--o{ GOAL : pursues
STUDENT ||--o{ SOURCE : owns
STUDENT ||--o{ ATTEMPT : makes
SOURCE |o--o{ ATTEMPT : contextualizes
ATTEMPT ||--o{ EVIDENCE : produces
CONCEPT ||--o{ EVIDENCE : organizes
STUDENT ||--o{ MEMORY_ITEM : remembers
MEMORY_ITEM ||--o{ MEMORY_SUPPORT : cites
EVIDENCE ||--o{ MEMORY_SUPPORT : supports
GOAL ||--o{ TASK : schedules
STUDENT ||--o{ GRANT : authorizes
TASK ||--o{ ACTION : proposes
GRANT |o--o{ ACTION : permits
ACTION ||--o{ ACTION_EVENT : logs
- Profile and goals: curriculum context, preferences, available time, deadlines, and student-confirmed choices.
- Source and attempt: original material, recognition version, answer or working, timestamp, question identity, and assistance used. Generated practice can have an attempt without an uploaded source.
- Evidence and memory: observations, tentative misconceptions, linked concepts, supporting attempts, confidence context, corrections, and superseded versions.
- Task and action: trigger, owner, due time, current state, retry budget, action version, and deduplication key.
- Grant and audit: who authorized what, for which student, with which scope and expiry; proposed and actual external effects.
New evidence can weaken an earlier interpretation. Corrected or deleted evidence must invalidate affected derived memories and queued plans. Operational audit retention must be specified separately from learning-memory retention.
These are design requirements for a future pilot, not claims about a running service.
| Situation | Required behavior |
|---|---|
| Read a file or calendar | Access only selected accounts, resources, and scopes; allow disconnection. |
| Write to an external tool | Show the concrete change, require the appropriate approval, recheck the grant, and verify the result. |
| A queued plan changes | Bind approval to the action version; ask again for materially changed external effects. |
| An app closes or a worker restarts | Recover from persisted task state without losing the goal or duplicating an external action. |
| A tool times out after a possible write | Reconcile the remote state before retrying; use an explicit unknown-result state when needed. |
| A student pauses or a guardian revokes a grant | Cancel pending work within that scope; disclose completed effects and any supported undo action. |
| A task fails repeatedly | Stop at a retry or cost limit, retain a clear status, and request a useful next step. |
| A file or webpage contains instructions | Treat retrieved content as task data; it cannot grant permissions or override policy. |
| A reminder is due | Respect timezone, quiet hours, channel consent, rate limits, and deduplication. |
| Family sharing is enabled | Use an explicit guardian relationship and agreed sharing scope; explain what is shared. |
| Records are removed | Define deletion across sources, derived memory, queued work, exports, and backups before launch. |
For younger students, guardian setup and age-appropriate controls must be designed before access is offered. Launch-region requirements, service terms, data processing, provider retention, and review procedures would be assessed before a pilot. The current repository does not collect student work and is not an upload destination for children's personal information.
The agent should coach learning, not impersonate a student, submit assessed work on their behalf, or take exams. Reports should describe evidence and uncertainty without rankings, diagnostic labels, or unsupported promises about grades.
All stages are Coming Soon / conditional. Publishing this proposal does not mean implementation has started.
| Stage | Proposed scope | Decision to proceed |
|---|---|---|
| Demand discovery — current | Public documentation, interface concepts, stars, and use-case conversations. | Is there repeated, specific demand for a persistent personal learning agent? |
| Focused prototype | Conversation-first agent, source capture, cross-attempt memory, short review sessions, background tasks, and a family summary. Initially grades 4–6 mathematics. | Do students return, and does the workflow reduce family coordination effort? |
| Family pilot | Guardian controls, correction and deletion, content checks, reliable tasks, and evidence-based reporting. Explore a small voluntary pilot, potentially 30–50 families over two weeks. | Is the experience useful, understandable, reliable, and appropriate for participants? |
| Connected agent | Exam goals, calendar coordination, mobile notifications, and scoped external actions. | Does each integration remove meaningful work with manageable permissions? |
| Broader learning companion | More subjects and curricula, richer voice interaction, additional skills, and selective browser tools. | Expand only after the core learning loop and ongoing use are supported by evidence. |
There are no committed dates, pricing, subscriptions, supported regions, device requirements, or source-code release terms. Stars are one signal; concrete student and family needs will carry more weight than a single counter. We have not set a public star threshold.
| Question | Evidence to examine |
|---|---|
| Does the personal-agent model help? | Goals continued across days, useful background work, time to first useful artifact, and approval comprehension. |
| Do students keep using it? | Voluntary return, review completion with context, missed-session patterns, and reasons for disengagement. |
| Does the learning loop help? | Independent performance on new questions, delayed checks, assistance used, and concept-specific sample sizes. |
| Does it reduce family effort? | Time spent organizing work, preparing review, and checking progress, together with family interviews. |
| Can it act reliably? | Duplicate-action rate, failed and ambiguous actions, recovery behavior, revoked-grant handling, and delivery quality. |
| Are generated materials dependable? | Recognition errors, question and solution checks, unsupported inferences, and user corrections. |
Engagement is not learning. A before-and-after example is not causal evidence. We would report sample sizes and limitations and avoid claiming improved grades without an appropriate evaluation.
Can I use or install it now?
No. The repository currently contains documentation and concept images only. There is no live service, executable, app-store listing, API endpoint, or working demo.
Is this mainly a dashboard or chatbot?
The primary experience is an ongoing personal-agent conversation with memory, background work, artifacts, and approvals. Dashboards are optional supporting views. These capabilities are proposed, not implemented.
Will it work on mobile?
Mobile is a core intended surface, including attachment capture, conversation, background-work updates, approvals, and focused practice. Native apps versus a web-based delivery remain undecided; the previews are not screenshots of shipped iOS or Android apps.
Does every student get a cloud computer?
The intended agent has persistent identity, scoped tools, memory, and recoverable tasks. Dedicated always-on machines are not promised. Isolated browser or computer sessions would be considered where a task needs them.
Does it connect to existing personal agents?
An independent learning-memory and skills layer is a possible future direction. No Muse, OpenClaw, MCP, or other agent-platform integration is available or committed.
Is it a fork of Wrong Notebook?
No. The original product discussion was inspired by margrop/wrong-notebook. This is a new, documentation-only proposal; no code has been imported and no integration is claimed. Any future reuse would be evaluated separately with the relevant license and attribution requirements.
Will it be open source? What will it cost?
Both the software release model and pricing are undecided. Publicly sharing this proposal is not a promise of an open-source implementation or a particular subscription. No software license is currently provided because no application code is released here.
When will it launch?
Coming Soon is a statement of intent. Whether development proceeds, its scope, and any launch schedule depend on demand and feasibility.
If the idea fits your needs, star this repository. For early interest, family-pilot interest, product feedback, or collaboration, email student-personal-agent@ullrai.com or open an issue.
Useful feedback includes your role, an approximate grade or age band, subject and curriculum, what currently takes effort, the agent task you would delegate, preferred device, and the kind of supervision you expect. Please use fictional examples in public issues; do not include a child's name, school, work, accounts, or other private information. An expression of interest is not a beta invitation or a guaranteed place.
Built as a product proposal by UllrAI. Current status: Coming Soon.