Dave, it was great to meet you. I put this page together for you after our conversation: a closer look at the system I’ve built with Orca, Claude, Codex and a private VPS, and why it makes a practical difference to me as a neurodivergent person.
↓My work and household admin span email, messaging, documents and conversations. Returning to a task means reconstructing its state: what was agreed, which source is authoritative, what has already happened and what still needs a decision.
I’ve built a persistent information layer around the agents so that reconstruction is less dependent on my working memory. The benefit for me is continuity: being able to resume a task with its evidence and decisions intact, even when my attention has been elsewhere.
Bangbrain is the overall system. Bangcloud is its server-side component; Banglocal is the laptop-side work. Orca is the working interface; Claude and Codex are the agents I use to reason about and act on that context. Those boundaries matter when deciding where execution and authoritative state live.
Orca provides the project, terminal and browser context. I use Claude and Codex to investigate source material, develop applications and execute bounded tasks against the relevant working directory. Both work from the same project briefs and reviewed notes.
The VPS hosts scheduled collectors and source archives independently of the laptop. Local interactive sessions and server-side jobs have distinct lifecycles; moving a file or pushing a commit does not transfer execution.
Raw evidence, catalogue metadata and reviewed Markdown notes remain separate. Project briefs preserve decisions, provenance and unresolved work; agents explicitly load them at the start of a session.
Household coordination, festival booking logistics and invoicing each have their own workflow. Shared retrieval and filing conventions supply context without granting unrestricted write or communication permissions.
The VPS runs source adapters, scheduled extraction and catalogue generation. The routes vary by source: API reads, captured archives, document text extraction and page-based retrieval. Collection is scoped; coverage and freshness have to be checked at the source.
The catalogue is a discovery layer, not a substitute for the underlying records. An agent can locate relevant material quickly, then read the original evidence before drawing a conclusion or proposing an action.
Selected email, cloud documents, captured messages and meeting notes feed private source stores or catalogue adapters. Available voice notes are transcribed for text retrieval. Missing capture is not treated as evidence of absence.
Catalogue records carry a title, date, type and source pointer. Generated daily, weekly, monthly and historical views support discovery. Raw correspondence remains separate from reviewed project notes.
Agents start with the project brief and saved context, then retrieve scoped originals. Source freshness, incoming and sent messages, and complete thread pagination matter when establishing current state.
A reviewed checkpoint records changes, decisions, source references and unresolved actions. New sessions read that state explicitly; continuity does not depend on undocumented cross-chat memory.
Two applications I’ve built using this setup. The interface excerpts below are static illustrations with synthetic data; they are not connected to production records.
A Glastonbury planning app models participant readiness, booking groups and booking progress as shared state rather than a sequence of messages.
Explore the festival example ↗The house application combines repairs, notices, a diary, shopping and shared finances. An email ingestion workflow proposes evidence-linked repair updates for review.
Explore the house example ↗The application supports registration readiness, balanced group allocation, a persisted draw, booking sheets and atomic booking claims to reduce conflicting attempts. It translates a coordination problem into a shared operational view.
The excerpt illustrates group state only. This is an independent coordination tool, with no claim to preferential ticket access or improved queue odds.
Synthetic group state illustrating the coordination model.
A scheduled server process reads relevant incoming and sent landlord correspondence from the email archive and posts it to the repair application. Claude derives proposed case updates; a housemate reviews each suggestion before it changes the record.
Ingestion, interpretation and mutation are separate stages. The pipeline does not send correspondence to the landlord. Keeping the source alongside the suggestion makes it possible to challenge an inferred status or next action.
“Please send a photo of the dripping kitchen tap so the repair can be assessed.”
Keep the repair open. Ask a resident to attach a photo for review.
Awaiting human approvalIllustration only. No real messages, addresses or resident records are connected.
The invoicing work applies the same pattern to a transactional workflow: establish the agreement from source evidence, generate a reviewable version, then reconcile accounting and delivery records before marking it complete.
The automated issuing path was demonstrated in an accounting sandbox. Real invoices have also been issued and filed through a reviewed workflow. Unattended production invoicing is not claimed here.
Generated summaries support discovery; original records substantiate claims. Capture time, event time and note-update time are distinct. Unresolved evidence remains explicitly unresolved.
Shared storage does not imply shared model context. The entry brief, current checkpoint and scoped source retrieval form the session-start contract.
Read access, proposed changes, external communications and account mutations carry different authority. Review gates attach to consequential actions, not every routine retrieval.
Less context to reconstruct.
More capacity to act.