A Fifth of Our Codebase Exists to Watch the Rest
Every morning at 6am Eastern, a scheduled job builds a sandbox and clones the Daylight repository into it. An agent boots inside. It connects to the production database through a read-only role, picks up the results of health checks that ran before it woke, then spends up to eighteen rounds of querying, reading, and reasoning working out what changed in the business overnight. It writes SQL against the event stream. It reads the product's own source. When a number moves, it runs git log and git blame until it finds the commit that plausibly moved it, then cites the file and line in its writeup. If something looks wrong, it opens a deeper investigation and emails me. Most mornings it files a short report and stays quiet, and I read it with coffee.
Daylight is our documentation app for parents in custody cases. That is the product. This post is about the thing wrapped around it.
The second product
When I counted last week, roughly 20 percent of Daylight's app-layer code had nothing to do with features. Thirty-two files, on the order of eleven thousand lines, six of the schema migrations. A user will never see any of it. Its entire job is to observe the business, reason about what it sees, remember what it concludes, and escalate when reality diverges from what it believes.
Nobody planned this. It accreted one useful piece at a time: an events table, then error capture, then an agent that could query both, then a place for the agent to keep its conclusions. Only recently did I step back far enough to see the shape. A second system had grown around the product, on the same substrate as the product. Same repo, same deploy pipeline, same Postgres instance, one schema over. And once you see it, the parts map onto a nervous system with uncomfortable precision.
Senses. Instrumentation on everything: every route change, every background job, every uncaught server error fingerprinted and counted, one row per distinct bug.
Episodic memory. An append-only event log holding everything that has ever happened in the product, filtered three ways so employee and test traffic never pollutes the signal.
Reflexes. Deterministic checks that run before any model is involved: failed payments, data-quality regressions, new error fingerprints. Their results get injected into the agent run as pre-verified facts, so expensive reasoning turns never get spent re-deriving cheap ones.
Deliberation. The Analyst, the agent from the opening scene. The weekly run gets 55 reasoning turns, the daily 18, and the sandbox it thinks in contains the product's full codebase and git history.
Attention. When a daily run flags a fire, the orchestrator spawns a scoped investigation of that specific anomaly and emails the human. Anomaly, then focused attention, then escalation.
Semantic memory. The findings ledger. This one deserves its own section.
Beliefs with the SQL attached
The ledger is the piece I would rebuild first anywhere else.
I spent six years at Meta watching the same failure repeat. Dashboards held state: current numbers, trend lines, the occasional annotation. The conclusions, which were the entire point of the work, lived in a deck presented once, a Slack thread, or the head of an analyst who later changed teams. Questions we had already answered got re-asked a year later and re-answered from scratch, sometimes differently.
The ledger gives conclusions a table. Each row is a named belief, typed as structural, causal, definitional, or risk. Each moves through a lifecycle: candidate, confirmed, retired. And each carries a pinned evidence recipe: the SQL that produced the belief, the result that supported it, and the date it was last re-verified. Beliefs are never deleted. They get retired or superseded, with a pointer to whatever replaced them. An index keeps the least-recently-verified beliefs at the front of the queue, so the system's stalest convictions are the first ones it re-tests.
Dashboards hold state. The ledger holds conclusions, keeps them falsifiable, and re-tests them on a schedule.
Part of what makes a senior analyst expensive is that they remember whether their last call held up. That memory now has a table, a schema, and a re-verification queue.
One substrate, walls on the outside
The load-bearing architectural decision is co-location. The common enterprise pattern treats AI as a peripheral: a chatbot on one side, a BI copilot on the other, each wired in through an API and shown a sanctioned slice. This apparatus is built more like tissue. The agents read the same tables the product writes, and they store their own cognition, the reports and findings and memory, one schema over in the same database.
Co-location buys two things. First, no integration tax: no ETL lag, no translation layer where definitions quietly drift, the apparatus's picture of reality is exactly the product's. Second, observation shares an address space with the code. The agent that notices an oddity in the event stream can open the file that emits those events. That is how a system I built for analytics quietly started finding bugs and pointing at the commits that introduced them.
The objection writes itself: I have handed an AI agent the keys. The honest answer is that the trust is an engineering artifact. The agent holds no master credential. It reads through purpose-built roles that can only select, and it writes to exactly two tables, its own reports and findings. The words parents write, the most sensitive data in the product, are invisible to it; it sees sanitized views of counts, timings, lengths, and categories, never the text. The sandbox denies all outbound traffic except the few endpoints the agent needs to function. Wide latitude to read and reason on the inside, hard walls on the outside. It gets to think about everything because it can touch almost nothing.
The product becomes the variable
Here is the shift that snuck up on me. The classic founder loop puts the human at the center: stare at the dashboard, form a hypothesis, change the product, stare again. All the cognition lives in the founder, and the tooling just displays.
With the apparatus running, the loop inverted. The system watches continuously, holds the beliefs, chases its own anomalies, and interrupts me when something is burning or a belief needs revising. The product stopped being the end point of my work and became the variable the loop adjusts. Control theory has clean names for this: the product is the plant, the apparatus is the controller, and the controller is where the intelligence lives. My job moved up a level. I spend fewer hours doing analysis and more hours making the thing that does analysis more observable, more capable, and connected to better data.
It has already earned its keep. Earlier this month, one investigation cross-referenced ad attribution, the event stream, and the commit history, and reframed our growth strategy: buyers were arriving already convinced, one specific funnel step was doing nearly all the leaking, and a whole category of engagement work turned out to belong to product strategy rather than growth. That conclusion now sits in the ledger, evidence pinned, due for re-checking.
One caveat keeps me honest. A controller has no value without a real plant under it. Daylight has paying customers and a live funnel producing real signal, and the apparatus is worth building because that signal exists. The order of operations matters: product first, then legibility, then apparatus. Teams that begin with the apparatus are building the flashy autonomous-company demo, and those fail for exactly this reason.
The affordance ladder
What the apparatus is allowed to do grows in rungs, and each rung opens only after the observability and containment around it already exist.
The basis for each widening is a scored track record in the ledger, domain by domain, never a general impression that the system seems smart. It buys its autonomy with receipts.
What transfers to your org
Most companies cannot co-locate an agent with production data next quarter; the boundary between the product database and the tools that watch the business is political long before it is technical. Three pieces transfer anyway.
Give conclusions a table. Named beliefs, a pinned query for each, a last-verified date. This beats the deck graveyard with zero AI involved. A test: can you list your org's ten hardest-won analytical conclusions, each with the query that supports it? If not, your stack stores state and forgets knowledge.
Build the read path an agent would need. A documented event schema, a small cookbook of canonical queries, read-only credentials scoped tighter than any human analyst's. Model reasoning is cheap now. The binding constraint is how legible your business is to something that reads fast and remembers everything.
Let the analyst see the code. Metric moves have commits behind them. Anyone who can run git log against the funnel, human or agent, answers "what changed" in minutes instead of meetings.
The product improves the business linearly. The apparatus improves the rate at which the business improves. I know which one I feed first each morning.
If something like this is accreting inside your company, half-planned, one useful table at a time, I would like to compare notes: kyle@monumentlabs.io.