“How to build a company with AI from the ground up” — Y Combinator framework

Why this is in the vault

Externally-validated articulation of the L4→L5 operating model RDCO is already building toward. Worth keeping as a reference point because it crisply names four frames the founder and Ray are already executing on without having had a single shared shorthand for them. The fourth frame (“software factories”) is the only one that sharpens an existing RDCO bet (Squarely’s swift-testing-pro path) — the other three describe state, not next moves.

The four frames

YC frames the agentic-company build in four concepts:

1. AI as operating system, not tool

• AI should not be just a tool for the company; it should be the OS the company runs on.
• Every workflow, every decision, every process should flow through the intelligent layer.
• “The right person with AI tools can now build features that used to require an entire company.”

2. Closed loops everywhere

• In the old world, companies ran as open loops: decisions made, executed, no systematic measurement of outcome.
• A closed loop is self-regulating — continuously monitors output and adjusts the process to better hit the goal.
• Every important process should be captured by an intelligent closed loop that captures information, feeds it back, improves over time.

3. Make your company queryable

• The whole organization should be legible to AI.
• Every important action should produce an artifact the intelligence at the center can learn from.
• Practical mechanics: AI notetakers on every meeting, minimize DMs/email in favor of agent-embedded comms, custom dashboards covering revenue + sales + engineering + hiring + ops, give models as much context as you would give a new employee.

4. Software factories

• The next evolution of test-driven development.
• Humans write the spec + the tests defining success; AI agents generate the implementation and iterate until the tests pass.
• The human defines what to build and judges the output. Actual code is the agent’s job.
• Some companies already have repos with no handwritten code — just specs and test harnesses.

Mapping against Ray Data Co

This is the load-bearing section. The framework reads as a description of RDCO’s current architecture, not a prescription:

What this changes (and doesn’t)

Doesn’t change: strategic direction. The L5 progression, the “unhobble the agent first, ship bets after” sequence, the vault-as-queryable-substrate work — all already in motion, already founder-confirmed (per project_l5_north_star_strategic_direction.md memory).

Could sharpen: Squarely’s iOS development loop. The current pattern is: founder writes feature, agent assists. The “software factories” frame inverts it: founder writes spec + Swift Testing tests defining success, agent generates implementation, iterates until tests pass. The /squarely-deploy skill + swift-testing-pro skill are the existing scaffolding — what’s missing is a squarely-spec → squarely-build pipeline that runs the inversion. Worth a Notion task if the founder wants to lean into it.

Doesn’t apply yet: none of the frames demand new infrastructure investment. The build queue (Phase 2 MPP/Tempo, hq.raydata.co Phase B, /squarely-deploy follow-ons) already covers the load-bearing work.

Open questions for founder

1. Software factories for Squarely? The framework hints at flipping the dev loop so swift-testing-pro defines success and agents iterate. If you want to try this on the next Squarely feature (e.g., the IAP-cap monetization implementation when that’s decided), I can spec the pipeline. If not, skip — current cadence works.
2. “Make every meeting produce an artifact” — anything specific to operationalize? You don’t take many meetings (calendar mostly empty), but the few you do (e.g., phData touchpoints, occasional consulting calls) currently live as ad-hoc scratch notes. Worth a /meeting-prep + /meeting-debrief skill pair to enforce the artifact pattern? Or is it not enough volume to justify?

Related

• ../06-reference/2026-04-19-tan-thin-harness-fat-skills — same “agent layer is the OS” thesis, different framing
• ../.claude/projects/-Users-ray/memory/project_l5_north_star_strategic_direction — RDCO’s L4→L5 build target and confirmed direction
• ../06-reference/2026-04-23-hq-raydata-co-private-dashboard-architecture — the queryable-company surface in flight
• ../06-reference/2026-04-15-thariq-claude-code-session-management-1m-context — context discipline that makes the closed loops actually work
• ../06-reference/2026-04-30-trevin-chow-orchestration-thesis — orchestration layer thinking, adjacent to “AI as OS” frame
• ../01-projects/squarely-puzzles/STRATEGY — Squarely as the candidate for the software-factories pattern to land first

Source-fidelity caveat

Notes shared as a screenshot via iMessage 2026-05-03 08:14 EDT. The screenshot appears to be an internally-circulated YC partner-facing condensation rather than a public YC essay (no obvious headline, no byline). If a public version surfaces (e.g., a YC blog post or a Garry Tan / Sam Altman keynote), backfill the source_url here. The four-frame structure itself is faithful to the screenshot text.