I follow a dozen-plus paid Substack writers on AI because that’s where the sharpest thinking is, but I don’t have time to read them all, let alone turn what I read into something useful — a course idea, a blog post, a talking point. Meanwhile every “AI-assisted work” article makes it sound like you just open a chat window and go. In practice I had five, then ten, then twenty separate AI-touched projects running at once, and no single place that told me what any of them needed from me today, what had already been read, or what was still sitting in a queue.

That’s not a personal quirk — it’s what happens to any team that adopts AI tools project-by-project instead of building a layer that coordinates across them. Once you have more than a couple of AI-assisted workstreams, the actual bottleneck stops being “can the model do the task” and becomes “who is tracking what state each workstream is in, and who is making sure nothing falls through.” Most teams solve that with tribal memory and a Slack channel. I wanted a system that solves it with state files and scheduled runs.

CogitOS is a Textual (terminal UI) dashboard you run with `python src/home.py`. The home screen has four regions: a main menu on the top left, a switchable panel on the top right that cycles between Ongoing Projects, an Ideas bag, and Closed Projects, a middle panel that flips between Inbox/Session/Editor/Info, and an activity tracker at the bottom that shows background jobs running live.

The main menu is the real feature list: “Run full Sources pipeline” does discover → summarize → gate → YouTube scan → morning report in one press — it logs into Substack through a persistent (never-automated) browser session, pulls new paywalled articles, summarizes them, and scores each one against my active projects and charter so only genuinely relevant material surfaces. “Generate ideas” extracts high-value ideas out of everything newly read into a shared ideas bag. “Auto-route bag ideas” uses a heuristic-plus-LLM pass to either match each idea to an existing project or flag it as a new project proposal for me to approve — nothing gets created without a human step. A Publishing submenu turns the queue into actual drafts — blog post, LinkedIn post, one-pager — and pushes approved blog drafts to WordPress; LinkedIn is deliberately never auto-posted, only prepared for me to paste. A Sources submenu exposes every stage individually for manual re-runs (retrieve, retry failures, relevance-gate, format prompts, drop a single link or YouTube video). An Operations submenu handles credentials, scheduling, a Fineco bank-balance scrape, Gmail/Calendar watch, and a CANSLIM stock-screening scan — because once you have one coordination layer, it’s tempting (and useful) to route every other recurring personal-data job through it too.

Underneath, every LLM call goes through the Claude CLI rather than the Anthropic API directly — a deliberate choice so the LLM inherits my actual Claude Code config, hooks, and behavior instead of a bare API call. Every long-running action (a Sources pipeline run, idea generation) executes as a background subprocess that streams progress to the tracker instead of freezing the UI. And `data/summary/index.md` is the single source of truth for what’s already been processed — nothing gets re-fetched or re-summarized once it’s in there.

The thing I didn’t expect: the hardest part wasn’t getting an LLM to summarize an article or draft a blog post — that’s the easy 80%. The hard part was state. Knowing that this URL was already processed, that this idea was already routed, that this credential shouldn’t touch the LLM context at all. I ended up writing an explicit decision log and a “no primitive without a nameable consumer” rule for myself, because it’s very easy to over-build a coordination layer speculatively before you’ve proven the smallest daily loop actually delivers value. Depth over breadth, hardened one loop at a time, beat trying to design the whole “personal AI OS” up front.

I also learned that login automation is a trap. Automating Substack/Google login gets you flagged as a bot almost immediately, so CogitOS uses a persistent browser profile the user logs into once by hand — the one deliberate exception is a bank site where the session expires too fast for that pattern to work, and even there credentials never touch the LLM context.

The natural extension is the “project-advancement loop” already sketched in the design docs: a background Fleet of AI agents advancing multiple projects unattended while I stay focused on one in the foreground, with an activity log and scheduled critic/judge passes (an “alignment” check against my stated priorities, a “work-reviewer” check on deliverable quality) surfacing a reviewable morning report instead of raw output I have to babysit.

That’s exactly the shape of problem an engineering org hits once AI agents move from “assist one developer” to “run overnight across a backlog”: you need a spine of durable state (what ran, what changed, what’s pending approval), a review gate before anything ships, and a single surface that rolls all of it up for a human — not twenty separate agent sessions nobody’s tracking. CogitOS is a one-person proof that this coordination layer is buildable with files-as-truth and a scheduler rather than a heavyweight platform; the same pattern — a home dashboard, a triage queue, an approval gate, a shared “brain” of durable knowledge — is the missing piece in most companies’ current AI rollouts, which stop at “give everyone a chat window” and never build the layer that turns many parallel AI-assisted efforts into one coherent operation.