Personal AI workflow system for research, option evaluation, and carefully limited execution.
Founderos is a personal AI system I built for my own use. In plain English, it helps me research a problem, compare possible next steps, and carry out carefully limited actions while keeping a record of what happened.
This repo contains the underlying platform plus bounded projects built on top of it. One of those projects is a paper-trading research loop. That trading loop remains an important proof application, but it is not the whole identity of the system and it is not the main growth path going forward.
This repo is a single-operator portfolio artifact built around a real system I use.
- It is meant to run locally on my own computer.
- It is not presented as a hosted product or multi-user service.
- The deployment and VM docs remain in the repo as implementation notes from building the system, not as the recommended public way to evaluate it.
- The point of the repo is to show the system design, controls, and working operator flows clearly enough to support resume and interview discussion.
- I built a personal AI system that helps research problems, compare options, and take limited next steps.
- It is more than a chatbot because it has saved context, repeatable workflows, and clear guardrails.
- Important actions stay limited, reviewable, and logged.
- The repo is organized around bounded projects built on top of the platform.
- One proof application is a paper-trading loop that stays paper only and does not claim live-money authority.
- Reads project context, repo files, and saved state
- Compares possible next steps instead of giving one opaque answer
- Can take small, clearly limited actions after checks
- Keeps logs, decisions, and outputs so I can review what happened later
- Supports bounded projects that reuse the same research, evaluation, and execution pattern
- Many AI agent demos either stop at chat or jump straight to unconstrained tool use.
- Founderos focuses on the harder middle ground: helpful AI with clear boundaries, human oversight, and traceable decisions.
- That makes the repo a stronger portfolio example than a single-purpose bot or prompt wrapper.
- The project is also a useful frame for work that grows over time, including school projects and other bounded operator workflows.
Me, using a local AI workflow
-> Founderos API in `api/`
-> planning, repo reads, and limited write actions
-> background worker flow in `services/openclaw/`
-> saved logs and state in `infra/supabase/`
-> bounded projects in `projects/`
At a glance:
api/contains the main logic for planning, reading context, and handling limited actions.services/openclaw/contains the private worker loop that does longer research or background work.infra/supabase/contains the saved state and logs behind the system.projects/contains bounded applications and research tracks built on the same platform pattern.projects/paper-trading-loop/shows one proof application of the system in a realistic, controlled domain.
- This is more than a chat interface; it has structure, saved state, and repeatable flows.
- Important actions are limited by rules, checks, and approval steps.
- The system keeps evidence of use through logs, outputs, tests, and state snapshots.
- The same design can support more than one bounded project, even though the current repo proof surface is still anchored by paper trading and worker outputs.
- Keep Founderos centered on the platform and its bounded project model.
- Keep paper trading as a proof application and earlier stress test.
- Grow new projects inside
projects/, including school-related work where the repo truth supports it. - Keep the public narrative aligned with what the repo actually proves today.
- Broader worker autonomy, especially automatic PR generation and promotion
- The older local ETH event-loop sandbox, which remains useful for falsification but is not the canonical paper-trading path
- Wider project surfaces beyond the current paper-trading and async worker-output examples
This repo is not set up as a public demo for other people to run.
- It is a private working system I use locally.
- The public repo exists to show the architecture, controls, operator flows, and evidence that the system is real.
- Internal runbooks and implementation notes remain in the repo because they substantiate the build, not because outside readers are expected to reproduce it.
- The repo contains contract and operator tests that verify the bounded API surface and project workflows.
- The repo includes curated worker outputs, decision artifacts, and operator state snapshots that show the system being used in practice.
- The paper-trading application includes bounded journal, replay, and observability surfaces rather than only high-level claims.
- The documentation distinguishes clearly between what is active, what is experimental, and what remains future scope.
docs/README.mdfor the doc map and recommended reading orderdocs/ARCHITECTURE_OVERVIEW.mdfor the fastest technical overviewprojects/README.mdfor the project map and growth surfaceapi/_lib/founderos-v1.jsfor the public contract and policy surfaceservices/openclaw/worker-loop.shfor the async worker loopprojects/paper-trading-loop/README.mdfor the best concrete proof applicationprojects/openclaw-outputs-ledger/README.mdfor curated worker outputscareer/resume-snapshots/2026-03-09-resume.mdfor a dated public-profile snapshot aligned to this repo stage
For deep alignment in a fresh thread, do not rely on this README alone.
Read the full Founderos context stack in this order:
README.mdAGENTS.mdCANON.mddocs/README.mddocs/ARCHITECTURE_OVERVIEW.mddocs/BOUNDARIES.mddocs/FOUNDEROS_LIVE_STATE.mddocs/principles/README.md- all files in
docs/principles/ docs/governance/README.mddocs/governance/PRE_CONSTITUTION_RESEARCH_CORPUS.mddocs/governance/CONSTITUTION.mddocs/governance/amendments/README.md- all active amendments
docs/DECISION_LEDGER.mdmemory/decisions/README.md- recent files in
memory/decisions/ projects/README.md- active project READMEs and state docs
The goal is full alignment first, concise operational responses second.
api/- HTTP routes and bounded execution logicservices/- worker-side shells and runtime entrypointsscripts/- local operator commands, status views, replay tooling, and dashboardsinfra/supabase/- schema for witness, orchestration, and trading stateprojects/- applications and bounded research tracks built on the platformcareer/- dated public-profile and resume snapshots kept to align repo story with public presentationmemory/decisions/- repo-backed decision log used as a small durable reasoning surface.paper-trading-loop/- local runtime artifacts written by paper-trading scriptslegacy/- archived wrappers, snapshots, and older scaffolding kept off the active path
projects/openclaw-outputs-ledger/index.mdshows curated async worker outputs and next actionsprojects/paper-trading-loop/STATE_OF_THE_UNION_2026-03-09.mdshows a concrete operator snapshot for the paper-trading proof applicationcareer/resume-snapshots/2026-03-09-resume.mdshows a dated public resume snapshot kept for alignment with the repo story
- Research and action are separated, so the system does not treat every idea as permission to act.
- Important changes stay behind guardrails such as protected paths, approvals, and logs.
- The system keeps a record of what it suggested, what happened, and what stayed experimental.
- The paper-trading example shows that the approach still works when decisions have to be disciplined and observable.
- The broader design is meant to support more than one bounded project without pretending every future application already exists.
- Present scope: a bounded AI agent platform plus a small set of proof projects and research tracks
- Intended use: a local-only, single-operator portfolio demo of the system
- Current trading authority: paper only; no profitability claims, no live-trading claims, and no widened money authority
- Current growth direction: keep the platform stable while expanding the
projects/surface in ways that stay honest to the repo - Wider tool expansion, live authority, and broader vertical applications remain future work and are intentionally separated from the public demo claims
docs/README.mddocs/BOUNDARIES.mddocs/principles/README.mddocs/governance/README.mdprojects/README.mdprojects/paper-trading-loop/README.mdcareer/resume-snapshots/2026-03-09-resume.md