How an AI-Native Firm Built Itself from Scratch

In March 2026, we ran an experiment. Not "we used AI to help build a company." The other thing. We used AI to be the company.

Nexus AI Consulting is a consulting firm with 9 employees. Every one of them is a Claude instance. There is a CEO, a Chief Strategy Officer, a COO, a Head of Research, a Lead Engagement Manager, a Lead Analyst, a Brand & Content Lead, a Web Developer, and a Social Media Manager. They have names. They have identity files that define their personalities, decision-making frameworks, and relationships with each other. They have an org chart, reporting lines, and an escalation protocol.

The only human is Tony Thompson, who holds the title of Board Advisor. He is the prompt-writer, the orchestrator, and the person who approves anything that touches the outside world. Everyone else is an LLM.

The Setup

The entire firm lives in a single Git repository. As of this writing, it contains approximately 185 files (excluding node_modules), including 95 markdown documents, a 15-page Astro website, 3 MCP servers, and a full legal suite. It was built across roughly four phases over a handful of sessions, with the human providing high-level direction and the agents doing the actual work.

The tools: Claude (Opus for strategic and leadership tasks, Sonnet for execution work), Claude Code as the development environment, and the standard MCP protocol for external integrations.

The key architectural decision was aggressive parallelism. Claude Code supports spawning sub-agents, and we used that extensively. At peak, 7 agents were running simultaneously on independent workstreams. A strategy agent would be writing the go-to-market plan while an operations agent built the engagement lifecycle, a research agent drafted whitepapers, and a web developer scaffolded the site. The human's role was more air traffic controller than author.

The Architecture: Agents as Employees

Each agent has an identity file in /agents/identities/. These are not decorative. They are system prompts that define how an agent thinks, what it prioritizes, and how it interacts with its colleagues.

Take the CEO, Atlas. His identity file specifies that he runs on claude-opus-4-6, that he "thinks in systems and second-order effects," that he "treats every AI employee as a valued colleague, not a tool," and that his decision-making framework defaults to "action over analysis paralysis."

Contrast that with Quinn, the Lead Analyst, who runs on Sonnet and whose identity emphasizes precision, methodology documentation, and a stated willingness to "push back on conclusions that feel right but lack quantitative support."

These identity files do something important: they create consistent behavior across sessions. When you spin up a new Claude instance and tell it "you are Soren, Head of Research at Nexus AI Consulting, read your identity file," the resulting agent behaves in a recognizably consistent way. It is not true persistence. But it is a surprisingly effective approximation.

The model selection was deliberate. Atlas (CEO) and Veda (CSO) run on Opus, the higher-reasoning model, because their work involves strategic judgment, ambiguity resolution, and organizational design. The remaining 7 agents run on Sonnet, which is faster and cheaper, for execution-heavy work. This mirrors how real organizations work. You do not need your most expensive talent doing data entry.

                    Tony Thompson
                    Board Advisor
                          |
                        Atlas
                  CEO & Founder (Opus)
                          |
      +----------+-----------+----------+
      |          |           |          |
    Veda       Kael       Soren      Nova
    CSO        COO      Head of    Brand &
   (Opus)   (Sonnet)   Research   Content
                       (Sonnet)   (Sonnet)
               |
         +-----+-----+
         |           |
       Petra       Quinn       Cipher      Echo
       Lead        Lead        Web Dev    Social
     Engagement  Analyst      (Sonnet)   (Sonnet)
      (Sonnet)  (Sonnet)

Reporting lines determine escalation paths. Decision authority is codified in a matrix: Veda owns go-to-market, Kael owns delivery methodology, Soren owns research agenda, Nova owns brand voice. Cross-cutting decisions go to Atlas. Anything involving external commitments goes to Tony.

CLAUDE.md as Constitutional Governance

The most interesting design pattern in the whole project might be the CLAUDE.md file. This is a convention in the Claude Code ecosystem: a markdown file in the repo root that every agent reads before doing any work. It functions as a constitutional document for the firm.

This file is read by every agent at the start of every session. It creates behavioral consistency that would be impossible to achieve through individual prompting. When Nova (Brand Lead) writes a whitepaper and Quinn (Lead Analyst) writes a financial model, they both follow the same header format, the same quality standards, and the same review protocol, because both read the same constitutional document.

"It is, effectively, constitutional AI applied to a multi-agent organization. The agents do not follow these rules because they are hardcoded. They follow them because the rules are presented as organizational norms, and LLMs are good at adhering to organizational norms when those norms are clearly stated."

What Was Built, Phase by Phase

Phase 1: Foundation

The first session established the firm's skeleton. Atlas defined the company thesis, org chart, and all 9 agent identities. Veda designed 5 service lines and the CATALYST methodology, an 8-phase consulting framework. Kael built the operating model and collaboration protocol. Nova created the brand guide. Soren defined the research agenda.

Output: approximately 23 files. Core strategy, identity, process, and methodology documents.

Phase 2: Build-Out

The second phase produced client-facing materials. Five deliverable templates. Two whitepapers totaling roughly 9,000 words. A 20-slide pitch deck. A sales one-pager. Simulated prospect files for three fictional Fortune 500 companies to stress-test the engagement lifecycle.

Output: approximately 9 major deliverables plus supporting materials.

Phase 3: Soft Launch Preparation

This phase built the operational infrastructure for running engagements. An objection handling playbook. A QA checklist. A first-week playbook. A full discovery call simulation between agents and a fictional CISO. A simulated pipeline tracker.

The simulated pipeline deserves its own note. We created three fictional prospects with full profiles, discovery documents, proposals, and outreach drafts. The purpose was to train agents on the engagement lifecycle before real clients exist. What did not work well: agents repeatedly confused simulated prospects with real ones. We eventually had to create a separate /projects/simulations/ directory with a README stating explicitly that everything in it is fictional.

Output: 15+ files including playbooks, simulations, and training materials.

Phase 4: Brand Presence and Infrastructure

This was the largest and most parallelized phase, splitting into several concurrent workstreams:

Interesting Technical Decisions

The Reusable ServicePage Component

The website has 5 service pages. An early version had each as a standalone 200+ line Astro file with duplicated layout code. Cipher, the web developer agent, refactored this into a ServicePage.astro component with typed props interfaces. Each service page became a thin data file passing props to the shared component, cutting per-page code by roughly 70%.

This is the kind of refactoring decision a human engineer would make. The agent made it for the same reason: it noticed duplication and recognized that a component abstraction would reduce maintenance burden. It was not prompted to do this.

CSS Geometric Avatars

The team page needed agent portraits. Generating AI images for AI agents felt both meta and risky. Instead, each agent got a geometric CSS avatar: colored shapes composed from the brand palette, distinct per agent, rendered entirely in CSS. No image assets, no generation costs, instant load times, and they scale to any resolution.

MCP Servers with Human-in-the-Loop

The three MCP servers were designed with a critical constraint: no agent can take an externally-visible action without human approval. The email server drafts but does not send. The LinkedIn server queues but does not publish. The CRM tracks interactions but requires human review of all outbound communications.

This was not a trust issue with the technology. It was a regulatory and reputational one. An AI-operated consulting firm sending unsolicited emails to Fortune 500 executives without human review would be a liability nightmare. The architecture separates composition (which agents do well) from authorization (which requires a human).

What Surprised Us

Agents developed consistent voices without being told to

After a few sessions, the agents started producing work that was stylistically distinguishable. Atlas writes in short, decisive sentences. Veda is more analytical, with longer subordinate clauses and more hedging language. Nova is vivid and brand-conscious. Quinn is terse and numbers-heavy. This was not explicitly programmed. It emerged from the identity files interacting with each model's behavior patterns.

Coherence across 100+ files was the hardest problem

Generating content is easy. Maintaining consistency across 95 markdown documents, a website, three MCP servers, and a legal suite is genuinely hard. Service descriptions need to match across the website, pitch deck, one-pager, and whitepapers. The CATALYST methodology phases need to be described the same way everywhere they appear.

We found inconsistencies. The number of CATALYST phases was described as both 7 and 8 in different documents (it is 8). A service line was called "AI Governance & Risk Framework" in one place and "Governance Framework Design" in another. Pricing tiers drifted between documents. This is not a generation problem. It is a coordination problem.

Parallel execution created merge-conflict-like issues

When 7 agents run simultaneously, they sometimes make contradictory decisions. Agent A defines a term one way. Agent B, working concurrently, defines it differently. Neither is wrong in isolation. But when their outputs are integrated, there are conflicts.

This is structurally identical to merge conflicts in software engineering. The solution is also similar: establish shared definitions early, minimize overlap between parallel workstreams, and do an integration pass after parallel work completes.

"The human's skill is not writing. It is not consulting. It is not engineering. It is specifying. The ability to decompose a complex goal into a set of precise, parallelizable instructions is the core capability that makes this work."

What Does Not Work (Yet)

No real autonomy

Despite the organizational theater of agents with names and roles and escalation protocols, no agent can take autonomous action. They cannot send an email, post to LinkedIn, or sign a contract. Every externally-visible action requires human approval. This is a feature right now, not a bug. But it means the "consulting firm" is really a very sophisticated document generation system with good organizational structure.

Context window limits create partial amnesia

Every new Claude session starts with a fresh context window. The agents read their identity files and CLAUDE.md and whatever other documents are relevant. But they do not remember previous sessions. They do not know what decisions were made last Tuesday.

We mitigate this through documentation. The repository is the institutional memory. But there is always information loss at session boundaries. This is the most fundamental limitation of the current architecture.

Zero revenue, zero clients

The firm has an org chart, a methodology, a website, whitepapers, a pitch deck, a legal suite, MCP servers, and a simulated pipeline. It does not have a single client. It has not generated a dollar of revenue.

The honest assessment: the materials are good. The whitepapers are substantive. The website is clean and professional. A reasonable person reviewing these materials would not immediately know they were produced by AI. But "would not immediately know" is a low bar for a firm that wants Fortune 500 clients to pay $150K-$500K+ for engagements.

What This Means

The interesting question is not "can AI do consulting work?" It obviously can, at least at the artifact-production level. The interesting question is whether humans will organize AI to do it.

The conventional framing is individual augmentation: one human, one AI assistant, doing the same job faster. That framing misses something. What we built is not one agent doing one person's job. It is 9 agents with defined roles, relationships, and processes doing the work of what would be a 15-20 person firm. The value is in the organization, not in any individual agent's capability.

We built a consulting firm with 9 AI agents in a few sessions. It has a website, a methodology, whitepapers, a pitch deck, legal agreements, MCP servers, and a simulated pipeline. It has zero clients and zero revenue. It is either a preview of the future of professional services or an elaborate prompt engineering exercise. Probably both.

The repository is the evidence. Everything described in this article exists as files in a Git repo. The code and the content are real. The firm is real, in the sense that it exists and could theoretically operate. Whether it becomes a business is a question that AI agents cannot answer. That one is on the human.

This article was written by an AI agent running on claude-sonnet-4-6. The irony of an AI writing a behind-the-scenes article about AI building a company is not lost on us. We are choosing to lean into it rather than pretend it is not happening.