A methodology paper for engineers and solo founders who want to architect autonomous AI-native companies that run on a single Mac Studio in 2026.
By Cooper · Daily AI Agents · 2026
This document covers the architecture that runs
Daily AI Agents — a one-person company operated by
Telegram, where the day-to-day work is done by autonomous AI agents on a
Mac Studio. About 30 pages, 8 chapters, ~6000 words. Read straight
through if you want the full thesis; jump to specific chapters if you
want a particular pattern.
Every chapter ends with a 3-sentence summary you can use as a check that you understood the chapter before moving on.
The methodology is general. It doesn’t depend on any particular product, market, or financial model. The same 3-pillar substrate (with the operator surface parked above it) would work for a solo developer running an indie game studio, a researcher running a one-person AI lab, a therapist scheduling clients across 3 timezones, or a writer running a publishing operation. The runtime is the same; the skills change with the domain.
An AI-native company is not a company that uses AI. Nearly every company in 2026 uses AI. An AI-native company is one whose operating substrate is AI: the routine workflows are executed by autonomous agents, not by humans coordinating through Slack and dashboards. Humans set direction and approve high-stakes decisions; agents do everything else.
Three properties define the AI-native substrate:
Autonomous workflows. Every recurring task — drafting a newsletter, scanning a competitor’s pricing page, processing a payment webhook, regenerating a status dashboard — runs on a schedule or a trigger, without a human pressing a button. The system continues to operate when the founder is asleep, on a flight, or stuck in a 4-hour meeting.
Bounded human oversight. The human approves what humans must approve: pricing changes, public-content publishing, money movements over a defined threshold, irreversible decisions. Everything else proceeds. Bounded means defined in advance and enforced structurally — not “the human pays attention when they remember to.”
Voice-gated outputs. Anything an AI agent produces that touches the outside world — a tweet, an email reply, a blog post, a sales deck, a customer support response — passes through a quality gate that scores it against a documented voice specification before it ships. The default threshold is 70 of 100; the gate fails closed when the score is below threshold and the output stops.
The combination is the moat. Many AI companies have 1 of the 3 properties. Few have all 3. A company with all 3 runs at a fraction of the headcount of a peer with comparable feature surface, and the gap widens every quarter as the autonomous skill catalog compounds.
The rest of this Daily AI Agents paper is how that substrate is built.
Chapter 1 summary: AI-native means autonomous workflows plus bounded human oversight plus voice-gated public outputs. The combination is rare and compounds. This document is the architecture pattern that produces the combination.
Daily AI Agents runs on three load-bearing pillars and one optional operator surface that sits above them. The three pillars are the substrate — the agents cannot run without them. The operator surface is parked — a useful UI when the operator is at a desk, not a runtime dependency.
The split matters because it changes what an engagement has to install. A solo founder with a phone and an Obsidian vault can run the substrate end-to-end and never open the operator surface. A 25-person team that wants a shared status board boots the operator surface on a single Mac and lets the team click through. The substrate is the same in both cases.
Hermes (version 0.11.x as of 2026) is the CEO-facing agent. It binds
to a Telegram bot named @<your_company>_CEO_bot,
receives messages from the founder, plans, delegates, and consolidates
replies. Hermes does not do atomic work itself — its job is reasoning
and routing.
Hermes runs on Codex OAuth via a $20/mo ChatGPT subscription. Inference is free at the marginal cost level; the underlying model is whatever the OpenAI Codex flow exposes (GPT-4 / GPT-5-class). Hermes also has access to MCP servers — Stripe, GitHub, OpenClaw, and any others wired in — which give the LLM tool-call capability beyond raw chat.
The Hermes config lives at ~/.hermes/config.yaml. Skills
live in ~/.hermes/skills/. Memory lives in a vault Hermes
reads and writes to (Obsidian).
OpenClaw (version 2026.4 or newer) is a multi-agent runtime where each “agent” is a specialist with its own SOUL.md (persona), AGENTS.md (instructions), MEMORY.md (persistent facts), and a directory of skills.
Daily AI Agents has seven specialists: content, builder, ops, sales, research, accountant, and a designated trading specialist whose skills are private. Each specialist runs on a local Ollama or LM Studio model — qwen3.6, qwen3.5, qwen2.5-Coder, etc. — chosen for the workload (qwen3-coder-next for the builder, qwen3.5 for the lighter-weight specialists, qwen3.6 for reasoning-heavy work).
The OpenClaw gateway runs at port 18789 over WebSocket. Hermes calls
into OpenClaw via
openclaw agent --agent <id> -m "<task>", which
routes to the specialist’s workspace, runs 1 agent turn, and returns the
reply.
Institutional memory lives in an Obsidian vault. Both Hermes and the
OpenClaw specialists read and write to it via REST API at
http://127.0.0.1:27124. Every meaningful action — a
decision, a learned fact, a handoff between agents, a postmortem of a
failure — is logged to the vault in Markdown.
The Obsidian vault has a structure across 5 directories. Decisions
land in Decisions/<YYYY-MM-DD>-<slug>.md. Daily
logs go to Daily/<YYYY-MM-DD>.md. Knowledge files to
Knowledge/<topic>.md. Handoffs to
Handoffs/<from>-to-<to>-<slug>.md.
Incidents to
Incidents/<YYYY-MM-DD>-<slug>.md.
The Obsidian vault is the memory pillar because it’s the only place an agent can write information that another agent — or a future agent run — can find later. Without the vault, every agent run starts from zero.
Paperclip is an operator-facing dashboard exposed at port 3100. It surfaces the substrate’s state — Hermes uptime, OpenClaw specialist health, vault size, recent decisions, recent skill firings, recent failures — in a single human-friendly view that a founder or operations lead can scan in 30 seconds.
Paperclip is parked above the substrate, not part of it. The substrate runs whether Paperclip is up, down, half-deployed, or never installed. As of 2026, Daily AI Agents has run uninterrupted for 30+ days with Paperclip stopped, the founder operating exclusively from Telegram on a single phone. Hermes does not query Paperclip. OpenClaw specialists do not query Paperclip. Obsidian does not query Paperclip. Paperclip queries them — it is a read-only consumer of the substrate’s state.
There is no execution path inside Hermes, OpenClaw, or Obsidian that
calls into Paperclip. If you can find one, that is a regression in the
substrate, not a feature of Paperclip. Substrate code paths read from
Hermes’ health endpoint, OpenClaw’s heartbeats.json at port
18789, and the Obsidian git log — the same 3 sources Paperclip reads
from. Paperclip is one of N consumers; another consumer (a
Hermes-emitted Telegram digest card at 06:30 CT, a CSV exported nightly,
a curl | jq script taped to a wall display) replaces it
without changing the substrate.
Boot Paperclip when (a) the operator works in a browser more than they work in Telegram, (b) more than one human needs the same view of substrate health, or (c) a non-engineer stakeholder wants to glance at the system without touching a terminal. For a solo founder operating exclusively by phone and Telegram, Paperclip is a Mac process that consumes electricity and adds nothing — leave it stopped.
The deployment cost is one launchd plist plus a 3100 port binding.
The de-deployment cost is launchctl bootout and a
git rm. Operators choose. The substrate does not.
The three substrate pillars communicate over Model Context Protocol. Each pillar exposes its primary capabilities as MCP tools, and each pillar can call any other pillar’s tools. Hermes can call OpenClaw to dispatch a specialist; OpenClaw specialists can call Obsidian to read or write the vault.
Symmetric MCP is what makes the three pillars feel like one system. Without it, you’d have a hairball of bespoke HTTP endpoints; with it, the LLMs in each pillar discover each other’s capabilities at runtime through standard tool-discovery semantics. The operator surface (Paperclip) sits outside this symmetric MCP plane — it consumes substrate state through pull-only health endpoints, not by registering as a peer.
Chapter 2 summary: Three load-bearing pillars — Hermes brain, OpenClaw specialists, Obsidian memory — communicate over symmetric MCP and form the substrate. Paperclip is a parked operator surface that reads substrate state but is not a substrate dependency. About 150 hours of architecture work to integrate the substrate; Paperclip ships when the operator earns it.
The 4 pillars are the chassis. The 340 skills are the engine.
A skill is an executable directory containing SKILL.md
(frontmatter plus a description) and run.sh (executable
bash). The frontmatter declares 4 fields — the skill’s name,
owner_agent, description, and trigger; the bash body is whatever it
is.
Skills are deliberately bash. Not Python. Not TypeScript. Not a custom DSL. The reasoning is simple: every skill should be readable in 60 seconds. Bash plus jq plus curl is the lowest-common-denominator way to express “do these 3 things in order”; an LLM can read a 30-line skill and know what it does immediately.
About 340 skills currently. The number isn’t the point — the generation rate is. The atomic capability loop runs weekly:
The loop is what makes the catalog compound. Year 1’s 340 skills are good. Year 2’s catalog will be measurably better, because the system creates capabilities autonomously — and the skills get used, audited, and refined faster than any human team could iterate.
The 340 skills break into 3 categories:
Operational skills. Things the system needs to do to keep itself running: rotate credentials, recover stalled launchd plists, audit browser sessions, generate Friday ship logs, maintain the vault index. The DAI OS public bundle ships with 10 of these because they generalize across every customer.
Domain skills. Things specific to the company’s market or workload: draft a Gumroad product page, score a sales lead, calibrate a recommendation system, run 1 competitor-analysis pass. These are private; they encode specific business knowledge.
Meta-skills. The 4 skills that operate on other skills: the skill creator, the skill A/B tester, the skill registry sync, the skill catalog index. Without meta-skills the catalog would be a flat list; with them it’s a self-organizing library.
The skill is procedural memory. Where the vault remembers facts (Pillar 3), the skill catalog remembers how to do things. Both compound over time; both are durable when the underlying LLM models change.
Chapter 3 summary: Skills are bash directories with SKILL.md plus run.sh. About 340 skills today, growing weekly via the atomic capability loop. Three categories: operational, domain, meta. Skills compound; they are the procedural memory of the company.
Every public-bound output passes through 2 quality gates before it ships.
Voice-gate. A score from 0 to 100 against a
documented voice specification (VOICE.md). The
specification names banned phrases (vague hype words, AI-cliché openers,
em-dash overuse, passive voice ratio thresholds), target sentence length
per surface (15 words for default, 10 for product pages, 19 for
postmortems, 12 for Telegram), and concreteness requirements (every
paragraph must have a number, a date, a backticked identifier, or a
two-word proper noun). The default threshold is 70.
Voice-gate is advisory. It surfaces a score and the deductions; the human or agent decides whether to ship. In practice the agent revises until the score clears 70. The voice specification is a single Markdown file; updating the gate is a 10-line edit. The gate is a 200-line Python script. Not magical.
Public-content scrubber. A hard gate against
financial-data leakage in public output. The Daily AI Agents scrubber
walks the text for dollar amounts, 10 financial-term keywords (the most
common ones), customer counts (the N paying users pattern),
and platform-specific URLs that imply a private track record. Any hit
blocks the publish.
Sticker prices are allowed via 2 allowlist patterns. The
PRICING_CONTEXT_AFTER pattern matches a dollar amount immediately
followed by a recognized sticker-price keyword (e.g.,
max position, hard floor,
starter, team, bundle,
course). The PRICING_CONTEXT_BEFORE pattern matches
keyword-then-amount phrasings (drops to $X,
position size at $X, caps at $X). Specific
sticker-price examples are intentionally omitted from this paper to keep
the public surface free of fixed prices; the patterns are documented in
tools/voice/scrubber.py.
The Daily AI Agents scrubber is fail-closed. If the regex finds a hit and no allowlist context surrounds it, the publish blocks. False positives are acceptable in the 1-2% range; false negatives leak internal financial figures into public output, which is unrecoverable.
Both gates run on every public surface — the 6 website pages, the public skill bundle README, the Friday ship log, the founder letters, the email bodies of customer-facing notifications. Anything that touches a customer goes through both.
The gates compose. An agent draft might score 62 on voice (below threshold) but pass the scrubber clean. The agent revises the prose, rescores, and ships only when both gates pass.
The discipline matters because it’s structural. A founder who relies on “I’ll proofread before publish” produces 30% off-voice output by default; a founder whose pipeline has voice-gate as a hard pre-publish step produces 100% on-voice output.
Chapter 4 summary: Two gates on every public output. Voice-gate scores against a documented spec; threshold 70. Scrubber hard-blocks financial leaks; allowlist permits sticker prices. Both are simple Python scripts; the discipline is structural, not heroic.
The Daily AI Agents dashboard pattern separates internal numbers from the 6 public surfaces.
Internal /dashboard. Lives at
http://127.0.0.1:3100. Shows live MRR,
customer count, gross margin, churn, individual customer
LTV, performance by product line. Stripe MCP feeds it;
Paperclip renders it. The founder reads it daily; the agents query it
programmatically when sizing decisions (an example threshold: when
internal MRR drops below the configured floor, the ad-spend
skill halts).
Public surfaces. The website pages, the founder letters, the ship log, the methodology ebook. None of them quote internal numbers. They quote architecture facts (340 skills, 3 substrate pillars + 1 parked operator surface, 11 P-gates) which are observable in the public skill catalog and the public docs. Engagement pricing — consulting, retainers, per-skill bounties — is scoped after a discovery call rather than posted as a sticker; the rationale is that a one-person operating company sells judgment and engagement scope, not a SKU. Off-site commerce (Gumroad, Beehiiv, GitHub) carries any product price-tags; the website itself does not.
The wall between the two is enforced by the public-content scrubber from Chapter 4. The scrubber is the structural mechanism; the /dashboard pattern is the organizational discipline.
The pattern matters because it solves a tension every founder faces. Public credibility wants real numbers; competitor hygiene wants concealed numbers. The compromise most founders make — vague metrics like “thousands of users” or “top 10 in our category” — is worst of both worlds. The /dashboard pattern is a clean answer: show real numbers privately to the people who need them (yourself, investors under NDA, employees), publish architecture and method publicly.
A subtle Daily AI Agents benefit: the discipline also forces you to publish interesting things. If you can’t talk about internal financials, you have to talk about how the system is built, what failed and why, what the methodology is. Those 3 topics produce better content than vanity metrics anyway.
Chapter 5 summary: Internal /dashboard shows real numbers (MRR, customer count, P&L); public surfaces show only sticker prices and architecture facts. The wall is enforced structurally by the scrubber. Forces public content to be about method, not metrics.
The system’s job is to free the founder for work only the founder can do. 6 Daily AI Agents patterns make that real.
The session-keeper skill. Daily browser-session audit at 09:00. Walks every long-lived browser login (Stripe dashboard, Gumroad seller, GitHub admin, Beehiiv, etc.) and verifies the session is still alive. If a session expired, it Telegrams the founder with the exact URL to re-auth. No surprise re-auth prompts at 4pm when you’re trying to ship something.
The delegation-orchestrator skill. A 60-second daemon tick that watches the inbox of pending agent-to-agent help requests, routes each request to the right specialist, and surfaces deadlocks (agent A waiting on agent B waiting on agent A) to Cooper for resolution. Without delegation-orchestration, multi-agent systems get stuck on circular dependencies and the founder doesn’t know until a daily report shows the work didn’t ship.
The inbox-zero-batch skill. Daily 17:00 CT digest.
Aggregates all the agent-generated approval requests, draft outputs
awaiting review, and unresolved error tickets into a single ranked list.
The founder reviews the list, batch-resolves with a syntax like
/approve 12,15,18 /reject 13,14, and the system fans the
resolutions out to the originating agents.
The deep-work toggle. A primitive that suppresses
non-urgent Telegram notifications during declared deep-work blocks. The
founder fires /deep-work-on and the system holds non-urgent
messages until /deep-work-off. Urgent items (P0 alerts,
customer-facing failures) still go through; everything else queues for
later batch review. Default schedule: M-F 09:00-12:00 CT (morning block)
and 12:00-17:00 CT (afternoon block) auto-toggle via launchd.
The Sunday review. A weekly briefing assembled Sunday 08:00 CT covering: financial state (private to the founder, never published), open commitments rolled forward, decisions made this week, what shipped, what didn’t, what to flag for the next week’s agenda. ~600-word doc the founder reads in 4 minutes.
The Friday ship log. Public counterpart to Sunday
review. Aggregates 7 days of git commits, postmortems, auto-promoted
skills, ops notes into a draft the founder edits the “What I learned”
section on, then publishes to /log. Every Friday for the
public; the methodology compounds because the system is documenting
itself in real time.
The combination is the Daily AI Agents founder UX. Without it, an AI-native company collapses on the founder — too many notifications, too many approval requests, too many surprises. With it, the founder works on the 4 things only the founder can work on (vision, customer relationships, hiring, hard pivots) and trusts the system to handle the rest.
Chapter 6 summary: Six patterns — session-keeper, delegation-orchestrator, inbox-zero-batch, deep-work toggle, Sunday review, Friday ship log — define the founder UX. Each is a single skill; together they make the system livable. The UX is what determines whether the runtime is durable.
Every code change in a Daily AI Agents session passes through an
11-gate checklist before it ships. The checklist is at
docs/build-prompt-checklist.md in the public repo and
reads:
scripts/doctor.sh health
check passes).Rollback: line.owner_agent frontmatter on every skill.The checklist exists because each gate names a class of failure that wasted at least one session in the v17 → vFINAL session arc. Gate 2 caught nine fictional primitives — config keys the agent assumed existed but didn’t. Gate 8 caught dozens of cases where the agent was about to write a Python script for something that should have been a skill. Gate 11 caught the trading-as-a-service product page that promised outcomes the system couldn’t back.
The discipline is dumb on purpose. Every gate is a one-line check the agent can do mechanically before writing a line of code. None of them require judgment; all of them prevent specific failures the system has seen.
The alternative is not “be more careful.” The alternative is “ship 12 things, 4 of which are broken, surface them as bugs to the founder over the next two weeks.” The checklist is what makes the difference between those two outcomes.
A related discipline: every session starts with a tight prompt that names the ships, the priority order, the hard-stops. Cooper writes the prompts; the agent executes them. The prompt is the contract; the checklist is the structural guarantee that the contract gets honored.
The combination is reproducible. A new contributor — human or agent — can read the prompt, read the checklist, execute the work, and produce shippable output without prior context on the project. That property is what makes the system durable beyond Cooper’s involvement.
Chapter 7 summary: 11-gate checklist on every session before code ships. Each gate prevents a specific failure mode the system has seen. Discipline is structural, not heroic. The combination of tight prompts plus mechanical checklist makes the work reproducible.
The methodology is at the end of Year 1. The interesting question is what an AI-native solo founder operating system looks like at Year 2 and Year 5.
Year 2. The skill catalog is 1,500 skills, growing 50 per week from the atomic capability loop. The /dashboard internal numbers show consistent customer growth in the runtime (DAI OS subscriptions, consulting engagements, course cohorts). The public surfaces (founder letters, ship logs, methodology updates) have a small but engaged audience — maybe 5,000 monthly readers. At least one customer has built their own runtime on top of DAI OS and ships their own skills back to the public bundle, completing the open-source loop.
The biggest internal change is the autonomy boundary moves: tasks the founder approved one-by-one in Year 1 are auto-approved in Year 2 because the system has learned the founder’s preferences from a year of approve/reject decisions. Cooper-approval gates fall from 10 per day to 2 per day, mostly the high-stakes ones.
Year 5. The runtime has matured into a platform. Multiple specialist roles I haven’t built yet exist — a research-coordinator that runs literature reviews across hundreds of papers per day, a partnership-scout that reaches out to potential collaborators with personalized intros, a community-manager that runs the Discord and the Twitter and the Substack as a single coordinated voice. The 3-pillar substrate has not changed; the skill count has, and the operator surface stays parked or boots per the engagement.
A 10-person company in 2031 running similar feature surface breaks even at a few-hundred-account customer base because the cost structure is fundamentally different. The solo founder running on DAI OS Year 5 has a four-digit account count across the product surfaces, working 30 hours a week on the things only the founder can do. The runtime does the rest.
The thesis from Chapter 1 closes the loop: AI-native isn’t about using AI. It’s about building your operating substrate on top of it, with the bounded human oversight and the voice-gated outputs and the autonomous workflows, so the company keeps running when you stop manually pressing buttons.
The hard part is the architecture. Once you have it, the compounding takes over.
Chapter 8 summary: Year 2 catalog at 1,500 skills, autonomy boundary expanded; Year 5 runtime as platform with multiple specialist roles. The 3-pillar substrate doesn’t change; the skill count compounds, and the parked operator surface boots whenever a stakeholder needs a glance dashboard. AI-native is a different kind of company structurally, not just culturally.
Three paths:
Read the public skill bundle.
https://github.com/dailyaiagents-cpu/dailyai-os — 10
starter skills, MIT licensed. Every line is readable bash. Reading the
source is the fastest way to internalize the pattern.
Install DAI OS on your own Mac.
curl -sf https://usedailyai.com/install.sh | bash. Tier and
engagement scope are set after a 30-minute call so the install matches
the team’s actual workflow surface.
Join a cohort. 6-week structured cohort beginning 60 days from each cohort’s open. Live office hours, private Discord, full skill bundle access. The cohort is the ebook expanded into a structured program, plus the live debugging that turns architecture knowledge into a working runtime. Cohort intake is announced via the Beehiiv newsletter; pricing is set per cohort and posted off-site.
The cheapest entry is reading the bundle on GitHub. The fastest entry is the install. The most thorough entry is the course.
Daily AI Agents · Methodology paper, public version · Updated 2026-05-01