On August 24, 2026, Y Combinator CEO Garry Tan posted a prediction that crossed ~318K views on X:
Prediction: systems of record will need to become AI harnesses or face replacement by agents
A follow-up tweet sharpened the claim:
There will still be API's and acl's and sql and underlying data structures that are deterministic. It's just that software companies have to build the AI harness and full solution for their customers or be subsumed by it
The thread drew pushback, vendor reactions, and a concrete builder pattern. This explainx.ai read is for people shipping CRMs, internal tools, and vertical SaaS — not a recap of enterprise buzzwords. If you already know what an agent harness is, skip to the two-layer stack. If you are new, start with the TL;DR table below.
TL;DR — questions after Garry Tan's thread
| Question | Direct answer |
|---|---|
| Is Tan saying kill the database? | No. SQL, APIs, ACLs, and schemas stay deterministic and authoritative. |
| What changes? | The product must include the agent harness — loops, tools, verification — not just CRUD screens. |
| What happens if you don't? | Standalone agents (Claude, Codex, custom stacks) read/write through APIs and own the workflow; your UI becomes archival. |
| What about hallucinations? | Tan: control them with agentic workflows and processes — grounded reads, gated writes, deterministic stop rules. |
| Is a CLI a harness? | Often yes — bounded commands over records are a minimal harness surface agents can call safely. |
| Who reacted? | Thread skepticism on record integrity; Notion 👀; Salesforce on intelligent workflows; Rogo-style entity profiles cited as the upside. |
What "system of record → AI harness" means in practice
A system of record is the place your organization treats as canonical: the CRM row, the ticket ID, the ledger entry, the signed contract PDF metadata. For twenty years, SaaS won by being that canonical store plus the UI clerks and operators used to maintain it.
Tan is arguing the UI layer is no longer enough. Customers will pay for finished work — research briefs, pipeline updates, compliance packets, onboarding sequences — not for another form with an "Ask AI" sidebar. If your product stops at searchable records, an external agent stack will:
- Read the same data through your API (or scrape exports if you lag on access)
- Act through scripts, MCP tools, or CLI wrappers
- Write back only where your ACLs allow — or bypass you entirely with a shadow spreadsheet
The survival move is to own the harness inside your product boundary: the loop that plans, calls tools against your deterministic layer, verifies outputs, and lands results back in the system of record with audit trails.
That is the same structural shift OpenAI described a week earlier when it pitched Codex as a platform — embed the harness, don't force every workflow through a generic chat window — applied to vertical SaaS instead of developer tools.
The two-layer stack: deterministic records vs agent harness
Think of two layers that must never collapse into one blob:
Layer 1 — Deterministic substrate (unchanged)
| Component | Role | Tan's wording |
|---|---|---|
| Database / warehouse | Source of truth for entities and history | "underlying data structures that are deterministic" |
| SQL / typed queries | Reproducible reads and constrained writes | "sql" |
| APIs | Contracted access for apps and agents | "API's" |
| ACLs / IdP | Who may read or mutate which rows | "acl's" |
This layer answers: What is true? It should not "reason." It should enforce invariants, foreign keys, and permissions.
Enterprise teams already wire this for Claude via enterprise-managed auth and MCP connectors — Okta-provisioned access to Notion, Linear, Slack, and similar systems of record without per-user OAuth sprawl. The deterministic store stays put; the harness gets a standard tool port (MCP).
Layer 2 — Agent harness (the new product surface)
| Component | Role | explainx.ai corpus |
|---|---|---|
| Tool router | Maps model intent → API/CLI/SQL calls | Harness engineering |
| Loop controller | Retry until verification passes or cap hit | Loop engineering |
| Verification | Tests, schema checks, duplicate detection | Context / prompt / loop stack |
| Approval gates | Human sign-off on writes that matter | Claude permission modes |
| Observability | Attach agent runs to record IDs | Notion × Cursor task board pattern |
This layer answers: What work got done, and can we prove it?
Tan is not asking SaaS vendors to replace Postgres with a chatbot. He is asking them to ship Layer 2 as seriously as they shipped Layer 1 — or watch Layer 2 get built by agents that treat Layer 1 as dumb storage.
Hallucinations in systems of record — Tan's reply and the engineering response
Thread participant @gibsonfc1 pushed back: "Not sure hallucinations are a good idea in systems of record."
Tan replied:
You still need databases and api's. Also hallucinations are the thing you control with proper agentic workflows and processes
That matches how explainx.ai already frames why models hallucinate and how to catch it: the failure mode is not "LLMs exist" — it is unguarded generation presented as fact.
For record systems, workable guardrails look like:
- Read-before-write — every mutation prompt includes fresh API/SQL reads, not stale context
- Tool-only facts — customer revenue, stage, owner come from
get_deal(id), not free text - Schema-validated writes — POST bodies checked against OpenAPI/Prisma types; reject unknown fields
- Deterministic stop rules — Claude Code
/goalstyle evaluators: "deal stage updated AND activity log row exists" - Human approval on irreversible actions — delete, refund, legal send
A harness that skips those steps deserves the skepticism. A harness that enforces them is why Tan separates deterministic storage from agentic process.
CLI-as-harness — Adam Rosler's thread point
@adam_rosler suggested a pattern already familiar to infra teams: a CLI to access records and insert becoming the norm — and that CLI is the harness surface.
# Illustrative pattern — not a shipped product
crm contacts show --id=acct_42 --format=json
crm notes insert --contact=acct_42 --body-file=./research.md --source=agent_run_9f3
Agents do not need a GUI to be safe. They need bounded verbs with typed arguments, ACL checks server-side, and idempotency keys on writes. That is thinner than a full MCP server but the same architectural idea: the model never touches raw SQL.
Comp AI's open-source CRM pushes further — intelligence in the NestJS API is treated as a bug; the Eve research agent owns loops and tools, Postgres stores evidence. Tan's tweet generalizes that inversion to every category still selling "database + forms" without an agent loop.
For coding-adjacent builders, Tan's own gstack is a reference harness: markdown workflows chained through slash commands, deterministic scripts for brittle steps, browser QA with explicit guardrails — thin hardness, fat judgment as he argued in the 400× productivity essay.
What incumbents are signaling (without linking out)
Two large workspace/CRM vendors reacted in public on the same day — worth reading as product direction, not as endorsements of Tan's exact wording.
Notion replied 👀 to the thread. Their June 2024 engineering integration with Cursor already moved tasks toward agent runs attached to tickets — the ticket stays the system of record; the harness run is reviewable on the board (Notion × Cursor coverage). The emoji reads as "we know this pressure is real."
Salesforce posted that AI agents learning and acting on data mean systems of record create value when they drive intelligent workflows beyond compliance archiving. That is harness language: the archive alone is table stakes; the workflow layer is where margin lives.
Neither post linked Tan's thread directly in the material explainx.ai reviewed; both align with the same builder takeaway — records + agent loops, not records + summarization.
Rogo-style entity profiles — the upside case in the replies
A quoted thread fragment described Rogo Intelligence-style entity profiles assembled from email, CRM, files, and meeting notes — a single harness output that clerks used to assemble manually.
That is the positive flip side of Tan's warning: when the harness lives inside the system of record, the product ships synthesized artifacts competitors cannot replicate from a read-only API key. The moat becomes:
- Proprietary joins across modules you already host
- ACL-aware retrieval (agents see only what the user may see)
- Write-back into the canonical timeline with provenance
Standalone agents can approximate this with enough OAuth scopes — until IT turns scopes off. Vendors who ship the harness first own the default path.
Build checklist — if you maintain a system of record
| Step | Action |
|---|---|
| 1 | Audit APIs — every harness-critical mutation already has a typed endpoint; no "agent-only" shadow tables |
| 2 | Expose MCP or CLI tools — start read-only; add gated writes with approval |
| 3 | Attach runs to record IDs — like Notion task boards or Comp AI queue rows |
| 4 | Ship verification in the loop — not a disclaimer banner |
| 5 | Centralize auth — enterprise-managed MCP or your IdP equivalent |
| 6 | Measure workflow completion — time-to-brief, time-to-close, not "AI messages sent" |
If you are greenfield, read how to build your first agent loop before bolting chat onto legacy CRUD.
What people are asking on X
"Does this mean Salesforce dies?" — No. It means Salesforce-shaped products must ship agent loops on CRM data or cede the workflow layer. The deterministic CRM row likely remains; the unpaid intern work moves to agents.
"Is this just MCP hype?" — MCP is one tool port into Layer 1, not the whole harness. You still need loops, verification, and product UX (MCP roadmap context).
"Can startups skip the database?" — Bad idea for regulated or multi-user domains. Tan explicitly keeps SQL/API/ACL. Comp AI still runs Postgres; the agent is front and center, not the storage engine.
"Is Garry Tan hyping YC deals?" — Possible bias, but the structural claim stands independent of YC: token economics already push agents into every workflow; systems of record that refuse harness-shaped surfaces become integration back ends with shrinking UX margin.
Bottom line
Garry Tan's August 24 thread names a product architecture shift, not a database fad:
- Keep deterministic records — SQL, APIs, ACLs
- Ship the AI harness — tools, loops, verification, approvals, audit
- Deliver full solutions — entity profiles, closed loops, write-back — or agents built elsewhere will treat your product as storage
For explainx.ai readers, the actionable read is: if you own canonical data, you are now also in the harness engineering business whether or not your roadmap says so.
Related on explainx.ai
- What is an agent harness?
- Codex as a platform — open agent harness for builders
- Comp AI open-source agentic CRM
- Claude enterprise-managed auth and MCP
- What is MCP?
- Loop engineering with Claude Code
- gstack — Garry Tan's skills factory
- Context vs prompt vs loop vs harness stack
Thread view counts, vendor replies, and product capabilities reflect public X posts and explainx.ai coverage as of August 25, 2026. Garry Tan is YC CEO and an investor in many SaaS companies — evaluate predictions against your own compliance and data model requirements.