Skip to content

andysalvo/founderos

Repository files navigation

Founderos

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.

Overview

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.

Summary

  • 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.

What it does

  • 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

Why it matters

  • 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.

System overview

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.

Current state

  • 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.

Active direction

  • 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.

Still in research

  • 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

Why this repo is public

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.

Evidence

  • 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.

Where to start

  • docs/README.md for the doc map and recommended reading order
  • docs/ARCHITECTURE_OVERVIEW.md for the fastest technical overview
  • projects/README.md for the project map and growth surface
  • api/_lib/founderos-v1.js for the public contract and policy surface
  • services/openclaw/worker-loop.sh for the async worker loop
  • projects/paper-trading-loop/README.md for the best concrete proof application
  • projects/openclaw-outputs-ledger/README.md for curated worker outputs
  • career/resume-snapshots/2026-03-09-resume.md for a dated public-profile snapshot aligned to this repo stage

Full agent alignment

For deep alignment in a fresh thread, do not rely on this README alone.

Read the full Founderos context stack in this order:

  • README.md
  • AGENTS.md
  • CANON.md
  • docs/README.md
  • docs/ARCHITECTURE_OVERVIEW.md
  • docs/BOUNDARIES.md
  • docs/FOUNDEROS_LIVE_STATE.md
  • docs/principles/README.md
  • all files in docs/principles/
  • docs/governance/README.md
  • docs/governance/PRE_CONSTITUTION_RESEARCH_CORPUS.md
  • docs/governance/CONSTITUTION.md
  • docs/governance/amendments/README.md
  • all active amendments
  • docs/DECISION_LEDGER.md
  • memory/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.

Repository guide

  • api/ - HTTP routes and bounded execution logic
  • services/ - worker-side shells and runtime entrypoints
  • scripts/ - local operator commands, status views, replay tooling, and dashboards
  • infra/supabase/ - schema for witness, orchestration, and trading state
  • projects/ - applications and bounded research tracks built on the platform
  • career/ - dated public-profile and resume snapshots kept to align repo story with public presentation
  • memory/decisions/ - repo-backed decision log used as a small durable reasoning surface
  • .paper-trading-loop/ - local runtime artifacts written by paper-trading scripts
  • legacy/ - archived wrappers, snapshots, and older scaffolding kept off the active path

Artifacts

  • projects/openclaw-outputs-ledger/index.md shows curated async worker outputs and next actions
  • projects/paper-trading-loop/STATE_OF_THE_UNION_2026-03-09.md shows a concrete operator snapshot for the paper-trading proof application
  • career/resume-snapshots/2026-03-09-resume.md shows a dated public resume snapshot kept for alignment with the repo story

Design notes

  • 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.

Scope

  • 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

Key documents

  • docs/README.md
  • docs/BOUNDARIES.md
  • docs/principles/README.md
  • docs/governance/README.md
  • projects/README.md
  • projects/paper-trading-loop/README.md
  • career/resume-snapshots/2026-03-09-resume.md

About

Resources

Stars

Watchers

Forks

Releases

No releases published

Packages

 
 
 

Contributors