How Family Offices Are Using AI to Get Ready for AGI
Most people are preparing for AGI by asking what the model will be able to do.
I think that is the wrong question.
The more consequential question is what happens to an organization when intelligence becomes abundant.
Imagine waking up with thousands of digital workers ready to research markets, write software, analyze customers, design products, test hypotheses, negotiate tradeoffs, and operate continuously. The cost of cognition collapses. The supply of possible work explodes.
It sounds like unlimited leverage until the organization breaks.
Priorities blur. Agents produce conflicting answers. Reports multiply faster than decisions. Code ships without context. Research generates confidence without truth. Everyone appears productive, yet enterprise value barely moves.
This part of the AI revolution receives too little attention. The model is only the engine. The institution still needs steering, memory, permissions, instruments, brakes, and a destination.
It needs a harness.
I am building that harness around my family office and operating companies now. Not because AGI or artificial superintelligence has arrived, but because the trajectory is clear. Machine intelligence is becoming more capable, less expensive, more agentic, and able to complete longer chains of work.
The winners will not have access to the smartest models.
Access will spread.
Models will change.
Yesterday’s frontier will become tomorrow’s commodity.
In fact, we see the “time to commoditization” of AI, the gap between frontier and what we can achieve with local inference running open models, is shrinking at accelerating rates.
That means the winners will build institutions capable of absorbing intelligence without losing focus, truth, or control.
They will know how to turn machine reasoning into capital allocation, faster product development, stronger intellectual property, deeper research, growing revenue, and durable operating advantage.
That conversion layer is the scarce asset.
This piece explains how my first AI operating system worked, where it began to fail, and how I am redesigning it for the age of AGI and ASI.
Building a Superstructure for AGI
As I teased above, most companies are still treating AI as a software feature.
They are buying copilots, adding chat interfaces, running workshops, and encouraging employees to experiment.
These steps are useful, but they are still warped by the old model of work: humans operate the company, while AI helps them complete individual tasks.
We are building toward a different model at McDonagh Family Office. My family office invests capital, builds software, creates media, develops intellectual property, conducts scientific research, and operates businesses. We are unlike any other SFO in the world. The question I care about is not how we can use AI to make each person slightly more productive.
The real question is:
How should a family office and its operating companies be designed when increasingly capable machine intelligence becomes a permanent part of the workforce?
Our solution?
I am wrapping our company in a custom-built harness designed to capture the maximum leverage from AI’s journey to AGI and ultimately, ASI.
I’ve been a data engineer since 2010, a machine learning engineer since 2012, sold a cybersecurity company to Facebook in 2018, and I am the biggest AI “believer” you will meet.
But even I do not expect artificial general intelligence to arrive as a single clean product launch. I expect capabilities to keep rising, costs to keep falling, and agents to become able to complete longer, more complex work with less supervision.
At some point, arguing over the precise definition of AGI will matter less than recognizing the practical reality: institutions will have access to more cognitive labor than they know how to organize.
Think through what that does to the world.
Intelligence becomes abundant. Coordination, judgment, authority, context, and institutional memory become scarce.
The model is not the company.
The harness around the model becomes the company.
Enterprise Value Creation Velocity
I think about the objective as enterprise value creation velocity.
That is not the number of prompts sent, agents created, documents written, tests passed, or tasks completed. Activity can rise while enterprise value remains flat.
Put another way: people tend to splash when they drown.
Enterprise value creation velocity is the rate at which an organization converts capital, intelligence, attention, data, and relationships into durable assets. Think swimming effectively vs splashing.
Those assets might include:
Revenue and cash flow
Adopted software
Proprietary data
Validated research
Audience and brand
Customer relationships
Better operating capabilities
Faster and more accurate capital allocation
Time Compounds
Velocity matters because time compounds. A company that learns faster can improve its product faster. A family office that makes better decisions sooner can redeploy capital earlier. A media business that converts research into trusted intellectual property can build an audience and distribution advantage.
But raw speed is not enough.
If the work must be redone, the apparent speed was fake. If an agent acts without authority, the output may create liability instead of value. If no one can tell which version is current, more production creates more confusion.
Real velocity is speed adjusted for quality, risk, adoption, and durability.
A hundred agents producing disconnected artifacts are not an enterprise.
They are a very expensive pile of motion.
The First Version of Our AI Operating System
I began by building a Git-backed operating system around my family office.
One central AI task acted as my Chief of Staff. It maintained the portfolio view, interpreted my instructions, tracked priorities, and delegated work to specialized AI leaders.
Those leaders took on functional roles: Presidents, Chiefs of Staff, product leaders, researchers, developers, writers, reviewers, and data scientists. Each could create additional bounded work lanes beneath it.
The system followed a hub-and-spoke model.
The central Chief coordinated. Specialized teams executed. I did not invent this pattern however I create many adaptions (verification modules, etc..) to improve work quality.
A software initiative might receive its own agent, repository, branch, isolated worktree, acceptance criteria, and authority limits. One agent would implement the change. Another would review the code. A third might verify deployment or test rollback readiness.
A research initiative could separate hypothesis design, implementation, scientific review, and evidence validation. A book project could divide drafting, continuity, developmental editing, fact-checking, and document production.
This worked remarkably well.
The system could conduct many kinds of cognitive work in parallel while preserving clear boundaries between projects. Git recorded the exact history. Work orders told each agent what it could change, what it could not change, how success would be tested, and when it had to stop.
The strongest work orders functioned like contracts.
They defined:
The outcome
The non-goals
The starting state
The allowed scope
The relevant evidence
The acceptance criteria
The review requirement
The tools and files available
The time or compute budget
The actions that remained forbidden
Reviewers were not ceremonial. They found real defects.
The system also learned to accept HOLD as a legitimate result. If the evidence was insufficient or the implementation failed a gate, the work stopped. The negative result was preserved instead of being rewritten until it looked successful.
That is an important feature for any AI-native institution.
When machine labor becomes cheap, the temptation is to retry until something passes. But repeated attempts can turn evaluation into theater.
A system that cannot preserve failure will eventually manufacture confidence.
Where the First System Reached Its Limits
The execution model was strong but the control plane around it became overloaded.
The same project status might be copied into the command center, project registry, initiative record, work log, task brief, pull request, and chat history. Each record was individually useful, but together they created a synchronization problem.
One task might know that a project had finished while the executive view still showed it as active. A clean branch might contain the latest operating state while the default branch remained far behind. An automation could appear active in a planning document while the actual scheduler said it was paused.
Git had preserved the truth.
Unfortunately, it had preserved several competing versions of it!
The central Chief also accumulated too much history. Delegations, receipts, decisions, corrections, and review cycles continued flowing through one permanent conversation. Completed tasks remained pinned. Old worktrees survived. The command center became part executive dashboard, part archive, part operating manual, and part event log.
It was a flight recorder pretending to be a cockpit.
The audit system had a related weakness. It could verify that required files existed and familiar text remained present. It could not reliably prove that the information was fresh, the correct branch was controlling, external systems agreed, authority remained valid, or the current portfolio view matched reality.
It tested whether the structure looked intact.
It did not test whether the institution knew the truth.
The final problem was governance recursion. A review would find a defect, which produced another contract, another verifier, another evidence packet, and another review. Each control might be rational. Together, they could become the product.
The system became exceptionally good at proving that it had not done the wrong thing.
Ever have a co-worker like that?
Annoying and oftentimes, unhelpful.
It needed to become better at finishing the highest-value right thing.
The New Design
The next system begins with one division of labor:
Probabilistic agents perform the reasoning and work. A small deterministic kernel owns state, authority, and transitions.
AI agents are powerful because they are flexible. They can synthesize ambiguous information, develop strategies, write software, analyze markets, challenge assumptions, and produce novel solutions.
That same flexibility makes them poor candidates to own canonical institutional state.
An agent should be able to recommend that a project advance. It should not be able to declare its own work accepted, invent permission, or silently redefine the organization’s priorities.
The deterministic kernel has a narrower job.
It records what happened. It checks whether a transition is allowed. It validates whether the required evidence exists. It reconciles live systems. It generates the executive view. It refuses contradictory or unauthorized states.
The agent does the work. The kernel governs the work.
Think of it like savant individual contributors backed by a manager who does everything by the book.
One Event, One State Transition
In the new design, every material change produces one structured event.
An event might record that a work order began, a result was submitted, a reviewer returned HOLD, a decision was approved, a deployment was observed, or an initiative was closed.
Each event includes a unique identity, source, time, evidence, previous state, proposed transition, and authority class.
Events are append-only. They are not silently rewritten.
The current portfolio view is then generated from those events. No one manually copies the same status into six narrative documents.
The executive interface becomes simple:
What are the three most important outcomes?
What is actively moving?
What changed?
What is blocked?
What requires my judgment?
What is the next earned gate?
Is the underlying evidence still fresh?
History remains available, but history no longer competes with current state.
This is a crucial distinction.
The system does not need one giant document containing everything it has ever known. It needs a small current-state projection with links to deeper evidence.
Here’s how I built it.
