Operating substrate for startups: what to install in the first 90 days.

A forming company in 2026 has the same first-week problem every forming company has. Decisions about how the company will run pile up before there is a company to run. What the brand sounds like. Where files live. Who the AI in Cursor speaks for. How emails get filed. How time gets billed. How a new hire ramps. The defaults, set hastily in the first month, calcify into the operating shape of the company by month six. Most of what follows after is rework.

The conventional answer is to defer all of this until the company is "real," until there are enough employees, customers, or contracts to justify operations. The conventional answer was right when the work between founders was meetings and Google Docs. It is not right anymore. Founders in 2026 work alongside AI agents. The agents need to know who the company is, what its tone is, where its memory lives, and how its work gets accounted for. Those answers are operating decisions, and they get asked of the agent before the company has operations.

We call the answer to those questions a substrate, and we made the long-form case for it in an earlier piece on why most company AI projects stall: agents bolted onto an operating layer built for humans fail for structural reasons, not model reasons. This article is the companion for the company that does not have that problem yet because it does not have an operating layer at all. A forming company holds an advantage an established one would pay heavily for. There is nothing to retrofit. The substrate can go in before the operations that will depend on it, which means the operations get built once, on top of a layer agents can already read, instead of twice.

This article is the field-level version of what to install. We have built, deployed, and dogfooded these patterns at Rarefied Earth for eighteen months, and we now deploy the same substrate into forming companies. There are five patterns. None of them is novel in isolation. The leverage point is installing them as one composable system, not as five disconnected initiatives.

Pattern 1. The cross-agent memory cascade.

The first pattern is the one without which nothing else works. Every AI conversation in a company where AI is part of the team has to start with context. Who the company is. What it is working on. What the recent decisions were. Who its clients are. What the founder's preferences are. Without a memory layer, the founder spends ten minutes re-establishing context at the top of every Cursor session, every Claude conversation, every ChatGPT exchange. The re-explaining cost compounds until it eats the savings, and the agent quietly drops out of the workflow.

The wrong fix is to write a long prompt and paste it into every conversation. It scales linearly with conversations, decays as the company evolves, and creates inconsistency across agents. The right fix is a cascade of AGENTS.md files: one at the top of the company workspace that defines the company globally, one at the top of each project workspace that defines the active engagement, one inside each subfolder that defines the local concern. Every modern AI tool that operates inside a workspace reads this cascade automatically. The agent's first message in any conversation already knows the company.

The cascade is not just one file. It is a cascade because the company is layered. The top file says: this is who the operator is, these are the working preferences, this is the project portfolio. The company file says: this is the positioning, these are the active clients, these are the operating rules and the pricing posture. The project file says: these are the decision-makers, this is the current state of the engagement, these are the local file conventions. Each layer answers the questions asked at its altitude, and an agent working three folders deep inherits all of them.

Around the cascade sit the pieces that make it durable: a folder taxonomy that gives humans and agents the same numbered map of the company, a brand starter that locks palette, typography, and tagline in files agents read before producing anything, an operator protocol that records how the founder works, and an agent charter that says what agents may do autonomously and what they surface first. In the canonical package these are Modules 01, 02, 12, 13, and 14. The install is the first week of a deployment, about three days of focused work.

A company that knows itself is not yet a company that sounds like itself. That is the second pattern.

Pattern 2. Voice and capture.

The pain has two halves. Outbound, an ungoverned model drafts in marketing English: validation lines, hedge words, the house style of nobody. Inbound, the real record of the company arrives as email and never lands anywhere an agent can see it, so every draft is written against a partial memory of the relationship.

The wrong fix is to rewrite every draft by hand and keep the inbox in your head. The founder becomes the bottleneck on both sides, which is the situation the agent was supposed to end.

The right fix on the outbound side is a voice guide that exists twice: once as a human-readable document with calibration rules and before-and-after examples, and once as code. At Rarefied Earth the code version is a single Python module holding 17 banned patterns, from em-dashes to phrasebook flourishes, and every path that ships outbound prose calls the same check. If a draft violates, the path refuses and the agent rewrites. The guard is in the path of the output, not in a document the agent might consult. The two versions are maintained as a mirror pair, so editing the rule edits the behavior.

The right fix on the inbound side is layered capture. Ours runs four layers: a realtime rule that captures and routes mail the moment it arrives, a sweep at every session start that catches anything the realtime layer missed, a lifecycle pass that prunes unprocessed captures after 30 days unless they have been promoted into the permanent engagement record, and a health monitor that audits the whole pipeline at every session start and surfaces degradation before it becomes silence. Every captured message leads with a relationship header, client or prospect or vendor or advisor, that tells the agent how to behave before it reads a word of the body. Add session hooks that write a fresh briefing when a workspace opens, and a freshness layer, one short file stating what is true right now, because an agent weights a stale plan and a current one equally unless something tells it the difference. Modules 03, 04, 11, and 15. Week two.

Pattern 3. Time and money.

The pain: it is Friday night and the week's billable hours are being reconstructed from memory, and nobody can say what the AI spend was per client. Hourly consulting fails quietly this way. The work was done, the value delivered, and the invoice undercounts it because memory is a bad ledger.

The wrong fix is a spreadsheet and a promise to be disciplined. Discipline loses to a busy week every time, which is why the fix has to remove the discipline requirement instead of demanding more of it.

The right fix makes the agent the bookkeeper. Time gets logged conversationally: say "log two hours for the client on discovery prep" in any session and the entry is written, the client slug validated, and a dedup guard refuses entries that look like near-duplicates of work already logged. AI session cost gets attributed by workspace path, so the spend per client is a query, not a guess. The weekly close-out is one command that runs four stages in order: aggregate the reimbursable costs, synthesize the raw time entries into client-readable line items, generate the archive invoice, and push a draft to Stripe. Draft is the default. The client sees nothing until the send flag is passed deliberately, which makes the draft the iteration mechanism all week and the send a decision rather than an accident.

Underneath the pipeline sit three quieter pieces: a data management policy that says what is git-tracked, what stays local, and where backups live, before the first client artifact exists rather than after the first loss; a pattern log that records repeated observations and holds a rule-of-three bar before anything gets generalized; and a document pipeline that renders invoices and deliverables in the company's own brand instead of a default template. Modules 05, 06, 09, 16, and 17. Week three.

Pattern 4. The skill stack and machine-readable state.

The pain: AI capabilities arrive as a stream of discrete skills and tools. A founder chasing each one learns three and forgets five, and every workspace ends up with a different, undocumented toolkit. Meanwhile each new AI tool that joins the stack has to be taught the company from scratch.

The wrong fix is chasing tools, adopting whatever shipped this week and abandoning it next month. The churn costs more than the capability returns.

The right fix is institutional. A skill baseline installs once at the user level and every workspace inherits it; Rarefied Earth runs 68 skills this way, from security audit to PDF generation, refreshed with a single command. A client-onboarding runbook makes the next engagement a procedure instead of a project: one script provisions the folder structure, registers the email routing, wires the cost attribution, and creates the engagement repo, with zero bespoke edits to the capture pipeline. A local MCP state server exposes the company's status, brand facts, and voice rules through the Model Context Protocol, so any AI tool that speaks the standard, today's or next year's, reads the same canonical state instead of being hand-fed a copy. Shell conventions give agents and humans the same aliases for the same operations. A cloud-agents slot ships default-off, a place for autonomous background work to land when the company is ready for it and not before. Modules 07, 08, 10, 18, and 19. Week four.

Pattern 5. Handover and audit.

The pain: everything above lives in the founder's head, and the first hire spends six weeks extracting it. The substrate that was supposed to make the company legible to agents is illegible to people.

The wrong fix is writing the onboarding documentation when the hire shows up, which means writing it from a memory of decisions rather than from the decisions.

The right fix treats handover as a deliverable with a date. A documented walkthrough of every installed module, what it does, where it lives, how to tell it is healthy. Client-specific customizations recorded next to the canonical versions they diverge from. A 30-day support window with a named owner, then a 90-day check-in. And the part most installations skip: a recurring audit that scores every module green, yellow, or red with recovery steps attached. Substrate decays silently; a mail rule stops firing, a hook falls out of a config, and nobody notices until the gap has swallowed a month of record. The audit makes decay visible on a schedule instead of discoverable by accident. This is the deployment's final phase: half a week at handover, and the audits recur after.

The 90-day shape.

Sequenced, the five patterns are not a quarter of disruption. A discovery week comes first, shadowing the principals before installing anything, because most software rollouts fail by building the wrong thing very well. Then four week-long passes, foundation, voice and capture, time and money, amplifier, then the half-week handover. Call it five and a half calendar weeks of deployment work.

The rest of the 90 days is the part that gets undervalued: the founders operate the substrate while the support window is open, the audits run, and the patterns either earn their keep in production or get corrected while the deployment is still warm. Install is the cheap part. Operating proves it.

We package these five patterns as Build the Company, the productized deployment of the substrate Rarefied Earth runs on itself: twenty canonical modules at this writing, nine packaged for deployment, installed in the five-phase sequence above and listed live on this site's homepage, rendered from the same module registry the deployments install from. If your company is forming and you would rather build its operations once, inquire about a deployment.

Sources and further reading.

Related work.

This piece is the install-sequence companion to the field guide on why most company AI projects stall, which makes the case for the substrate from the failure data. The field guide on AI takeoffs for general contractors is the same posture applied to construction, the vertical where the firm's engineering credentials carry the most weight, anchored by the peer-reviewed pile-bent research behind them.