117 lines
8.4 KiB
Markdown
117 lines
8.4 KiB
Markdown
# Rensheng, gbrain and the personal workspace
|
|
|
|
Research and recommendation, 2026-09-28. No integration was installed or tested.
|
|
gbrain inspection: `e78f1c38b947b053f3a46881340f74f316be855a`.
|
|
Rensheng inspection: `c06c4e3f290800752a0c252c84fbca0eed61e45d`.
|
|
|
|
## Finding
|
|
|
|
There is substantial overlap. Memory, CRM, daily briefs, natural-language task
|
|
management and agent tools are not unique to this workspace. Its remaining
|
|
product hypothesis is a low-friction daily execution interface: turn personal
|
|
context into a few actionable choices, execute through appropriate controls,
|
|
retain actual outcomes, and improve routines from experience.
|
|
|
|
This hypothesis has not been demonstrated by the current mock. Home, Messages
|
|
and Journal still use in-memory prototype state; Beeper sending and life
|
|
integration are not connected. Research has real persisted decks and Codex chat.
|
|
See [current status](../README.md) and [execution prototype](execution-support.md).
|
|
|
|
## Honest comparison
|
|
|
|
| Concern | gbrain | Rensheng / life | This workspace |
|
|
| ------------------------- | ------------------------------------------------------------------------------------ | ---------------------------------------------------------------------------------- | ------------------------------------------------------------------ |
|
|
| Collection | Native Google/GitHub sync, chat-history connectors, imports and extension points | External agents and existing source tools; shared raw store remains planned | Real research connectors; communication integration proposed |
|
|
| Durable personal context | Pages, sourced facts, corrections, withdrawal, retrieval and graph | Small source-linked Markdown views, explicit user decisions and domain conventions | Should consume context, not own another CRM |
|
|
| Daily brief | Agent briefing skills | Briefs generated by external agents | State-derived prose prototype; externally published brief proposed |
|
|
| Tasks | Agent skill for add, complete, defer and remove in a structured task page | Procedures and context; execution tools retain occurrences | Direct routine/task controls, currently prototype |
|
|
| Execution by content type | No equivalent unified routine/measurement/reply screen identified in inspected UI | Separate OpenBrief implements attention handoff and return anchors | Content-specific execution controls are the intended focus |
|
|
| Routine learning | No equivalent occurrence-based routine review identified in inspected implementation | Stores chosen procedures and meaningful review conclusions | Durable events and statistics proposed, not implemented |
|
|
|
|
gbrain's [daily-task-manager skill](https://github.com/garrytan/gbrain/blob/e78f1c38b947b053f3a46881340f74f316be855a/skills/daily-task-manager/SKILL.md)
|
|
defines stable task IDs, priority, completion archives and deferral. Its
|
|
[briefing skill](https://github.com/garrytan/gbrain/blob/e78f1c38b947b053f3a46881340f74f316be855a/skills/briefing/SKILL.md)
|
|
already addresses daily assistance. These are agent workflows, not evidence of
|
|
a unified execution app, but they are genuine alternatives for a user satisfied
|
|
with chat and linked source applications.
|
|
|
|
Rensheng is not uniquely local or agent-independent: gbrain also emphasizes
|
|
portable, sourced memory across agents. Rensheng's useful distinction here is
|
|
the deliberately small, directly readable context model and its operational
|
|
conventions. It does not ship a replacement for gbrain's complete ingestion and
|
|
retrieval infrastructure. See [Rensheng's comparison](https://github.com/yutakobayashidev/rensheng/blob/c06c4e3f290800752a0c252c84fbca0eed61e45d/COMPARISON.md).
|
|
|
|
## The nearer overlap: OpenBrief
|
|
|
|
The Rensheng repository also contains an implemented
|
|
[OpenBrief](https://github.com/yutakobayashidev/rensheng/blob/c06c4e3f290800752a0c252c84fbca0eed61e45d/docs/openbrief.md)
|
|
daemon, desktop app and mobile companion. It handles observations, bounded
|
|
briefs, agent proposals, confirmed decisions and return anchors. Thus resumption
|
|
support should not be described as absent from the existing Rensheng repository.
|
|
|
|
Before integrating that feature, choose one owner for its decisions and return
|
|
anchors. If OpenBrief remains active, this workspace should reference its
|
|
records rather than independently maintain conflicting copies. Reusing its
|
|
runtime is not automatically required: its ACP ownership and desktop collection
|
|
solve a narrower problem than this app's external-Codex publishing contract.
|
|
Actual compatibility needs a separate implementation check.
|
|
|
|
## Recommended division
|
|
|
|
- **Original systems:** messages, calendar events and source evidence.
|
|
- **life:** relationship context, explicit preferences, accepted goals and routine
|
|
definitions. External Codex maintains these files. Compiled claims remain
|
|
traceable to original evidence and user corrections.
|
|
- **External Codex:** interpretation, candidate selection, reply drafts and
|
|
periodic review. No new app-owned reasoning engine is required.
|
|
- **Workspace:** published suggestions, user choices, activity occurrences,
|
|
measurements and execution events, plus the controls to act on them.
|
|
- **gbrain, optional:** collection or retrieval infrastructure if a measured
|
|
source-coverage or search problem justifies operating it. Do not introduce a
|
|
second authoritative profile, task list and routine definition by default.
|
|
|
|
Durable context and execution events have different owners. Copy meaningful
|
|
outcomes into life through Codex; do not continuously reconcile two independently
|
|
editable task databases. If gbrain indexes life later, treat the indexed copy as
|
|
a projection and first verify its source-write behavior. This is an integration
|
|
proposal, not a tested read-only mode or a promise that whole-brain deployment
|
|
can be reduced to a dependency-free collector.
|
|
|
|
## Options and decision criteria
|
|
|
|
1. **Rensheng + Codex + existing apps:** lowest custom application upkeep. Prefer
|
|
this if a daily brief and source links already lead to action reliably.
|
|
2. **Rensheng + this workspace + Codex:** recommended experiment for the stated
|
|
need for routines, measurements and communication in one daily view. The
|
|
execution interface and recorded outcomes must earn their maintenance cost.
|
|
3. **Add gbrain underneath:** consider when collection, retrieval or cross-agent
|
|
memory becomes an observed bottleneck. Its connectors do not supply a native
|
|
Beeper integration or automatically replace external-Codex reasoning.
|
|
4. **gbrain + existing chat/source apps:** reasonable if generic memory, Gmail
|
|
waiting reports and conversational task management satisfy the actual need.
|
|
In that case, much of this workspace need not be built.
|
|
|
|
## Smallest useful experiment
|
|
|
|
Run a suggested one-to-two-week trial with one real life routine, one measurement
|
|
and a small set of real Beeper follow-ups. This duration is a practical starting
|
|
point, not a clinical protocol. Persist records before adding more mock screens.
|
|
|
|
Publish a short brief and actionable items through the proposed
|
|
[Codex interface](agent-publishing-design.md). Support direct execution, deferral
|
|
and correction. Keep reply completion distinct from fulfillment of a promise.
|
|
Retain events across reloads. Use observed results in one Codex-led review and
|
|
save only adopted routine changes to life.
|
|
|
|
Compare with the simpler baseline: Codex writes a daily brief to life and the
|
|
user acts through existing apps. Assess actual usefulness: easier starts and
|
|
returns, important commitments missed, false positives, correction effort,
|
|
and whether the workspace is opened without prompting. Completion rate can
|
|
support review but must preserve planned denominators, missing coverage and
|
|
routine-version changes. No specific UI is claimed to treat ADHD.
|
|
|
|
If the interface does not reduce friction, simplify to the baseline rather than
|
|
defend the project through feature count. Defer generic vector search, knowledge
|
|
graphs, a new agent framework, broad connector coverage and additional dashboard
|
|
expansion until this execution loop proves useful.
|