Schematic: building a system for systems

What if we stopped treating complex problems as collections of tasks and started treating them as systems that could be mapped, understood, adapted, and eventually operated?

There is a recurring pattern in the work we have done over the past decade. Whether we are designing a digital product, restructuring a business, building an operating model, launching a new company, or trying to understand why something is not working, the difficult part is rarely the individual task. The difficult part is understanding how everything fits together.

A business is not its CRM, website, sales team, financial model, marketing department, or operating procedures. It is the interaction between them. A clinical trial is not a protocol, a patient population, a set of endpoints, and a statistical analysis plan considered independently. It is the relationship between all of those things. Even something as personal as becoming fit is not simply a collection of workouts and dietary recommendations. It is a system involving training, recovery, nutrition, sleep, environment, adherence, feedback, and individual constraints.

We have excellent software for many of the individual components. We have databases, project management tools, CRMs, dashboards, documents, spreadsheets, automation platforms, and increasingly capable AI systems. What we do not have is a broadly useful interface for representing the system that sits above all of them.

That is the idea behind Schematic.

The problem is not a lack of information. It is a lack of structure.

The amount of information available to any individual or organization has become almost absurd. We can find research on nearly any subject, generate analyses in seconds, interrogate large datasets, and ask AI systems to produce plans for problems that would previously have required hours or days of research.

Yet more information does not necessarily produce better decisions.

In many cases, it produces the opposite. The information is fragmented across different sources and different applications, and the relationships between pieces of information remain implicit. A person reading a strategy document has to construct the underlying system mentally. An executive looking at a collection of dashboards has to work out which metrics influence one another. A founder researching a new market has to turn hundreds of disconnected observations into a coherent model.

The problem is not that the information does not exist. The problem is that the structure connecting it is difficult to see.

This is one of the reasons systems thinking has remained useful across disciplines. The important properties of a system are often not contained within its individual components, but in the relationships between them. System dynamics, for example, focuses explicitly on how interactions between components create behavior over time. The same principle applies whether the system is an organization, an industrial process, a market, or something much more personal.

Schematic starts from the assumption that software should help us represent those relationships directly.

The basic primitive is deliberately simple: nodes connected by meaningful relationships, with hierarchy, context, instructions, inputs, outputs, ownership, rules, and external systems attached to them.

The simplicity is in the interface, not necessarily in the system being represented.

From bird's-eye view to supergranular detail

The most important characteristic of a Schematic is that it should support radically different levels of abstraction without losing the relationship between them.

Consider a company.

At the highest level, its operating model might contain Strategy, Marketing, Sales, Product, Operations, Finance, and People. That view is intentionally incomplete. It is not supposed to tell you how the company works in detail. It is supposed to tell you what the major pieces are and how they relate.

A CEO can understand that view almost immediately.

A department leader can then move into Marketing and see positioning, brand, content, acquisition, SEO, partnerships, analytics, and the systems supporting them. A specialist can move further into SEO and inspect technical infrastructure, information architecture, content strategy, authority, measurement, and AI visibility. An operator can go further still and reach the individual process, data source, responsibility, rule, or integration that makes one of those components work.

The same system exists at every level. Only the resolution changes.

This matters because complexity is often made difficult by forcing people to consume it at one resolution. A 50,000-foot view is too vague for an operator, while a 5-foot view is unusable for an executive. Most software makes you choose between them.

Schematic should not.

The intention is closer to a map than a document. A map does not make a city less complicated. It makes the city legible. You can see the major roads, understand where you are, and then zoom into the exact street you need without losing your orientation.

That is the experience we want for complex systems.

The schematic is the model, not the picture of the model

This distinction is fundamental.

A conventional diagram is primarily a visual artifact. It may show that one thing connects to another, but the intelligence is often contained in the person who created it rather than the diagram itself.

A Schematic should be different.

A node is not simply a box on a canvas. It is a structured object. It can have a type, description, owner, instructions, rules, inputs, outputs, children, dependencies, external connections, and potentially an AI agent assigned to it.

Likewise, a connection is not simply a line. It can express a dependency, hierarchy, data flow, ownership, trigger, input, output, or another meaningful relationship.

This means the visual representation is only one way of interacting with the underlying model.

The model can be searched, queried, compared, versioned, forked, generated, modified, connected to other systems, and eventually executed.

That is what separates Schematic from a conventional whiteboard or diagramming tool. The canvas is the interface humans use to understand the system. The underlying structure is what allows humans and machines to work with it.

This distinction becomes increasingly important as AI becomes more capable.

Why ChatGPT alone is not enough

The obvious question is why any of this needs to exist when systems such as ChatGPT can already produce remarkably sophisticated plans.

The answer is not that AI cannot reason about systems. It can. The problem is the interface through which we interact with that reasoning.

Conversation is excellent for exploration. It is excellent for asking questions, testing assumptions, researching possibilities, and working through ambiguity. But conversation is inherently sequential, while complex systems are inherently relational.

Ask an AI to explain how a company works and it may give you an excellent answer. You still have to reconstruct the relationships in your head.

Ask it to create a plan for reaching $1 million in ARR and it may generate dozens of useful recommendations. You still need to understand which assumptions underpin the recommendations, what depends on what, where the bottlenecks are, and which elements need to change if your circumstances are different.

Schematic externalizes that structure.

The AI can still be there. In fact, it becomes significantly more useful when it has a persistent system to operate on.

Instead of repeatedly asking, "What should I do?", the user can inspect the system and ask, "What is missing?", "What is likely to become the bottleneck?", "What changes if I remove this component?", or "Which parts of this system could be automated?"

The difference is subtle but fundamental. The AI is no longer generating a temporary answer. It is reasoning over an explicit model.

Starting with the destination

One of the most powerful properties of Schematic is the ability to start with an endpoint rather than a collection of existing resources.

Imagine a consultant who wants to build a business generating $1 million in ARR.

The obvious approach is to start with the current situation and ask what should happen next. Schematic allows the opposite approach.

Start with the desired outcome.

Then work backwards.

How many customers does $1 million in ARR require? At what average contract value? What sales volume does that imply? What conversion rate is necessary? How many qualified opportunities are needed? How much demand must be generated? Which acquisition channels can plausibly generate that demand? What delivery capacity is required? At what point does another employee become necessary? What margins need to exist? What happens if pricing increases? What happens if retention is lower than expected?

The resulting structure is not simply a plan.

It is a model of the machinery required to make the outcome plausible.

The same logic applies to very different problems.

"Become extremely fit" can be decomposed into strength, cardiovascular capacity, body composition, mobility, nutrition, sleep, recovery, adherence, and the constraints imposed by the individual's lifestyle.

"Build my dream home" can be decomposed into requirements, location, land, financing, architecture, planning, construction, materials, interior, landscaping, timeline, and maintenance.

"Build a luxury real estate sales engine" can be decomposed into positioning, inventory, acquisition, qualification, nurturing, sales, viewings, offers, financing, closing, referral, and retention.

"Understand a competitor" can be decomposed into positioning, acquisition, product, pricing, sales, operations, technology, partnerships, economics, and customer experience.

These are superficially unrelated problems. Structurally, they have much in common.

They all have an intended state, components required to reach it, dependencies between those components, constraints, feedback, and points where intervention can change the outcome.

Schematic is designed to make that structure explicit.

A system should not be a template

There is a tension here that matters.

We want Schematic to contain common patterns and best practices, but we do not want it to become another library of rigid templates.

Our experience building systems is that there is rarely a single correct implementation.

A good operating model for a five-person consultancy may be completely inappropriate for a 500-person organization. A sales process that works in luxury real estate may be disastrous for an enterprise software company. A fitness system that is optimal for one person may be completely impractical for another.

What can be reused is the underlying knowledge.

The structure can be copied.

The assumptions can be inspected.

The components can be retained or removed.

The system can be adapted to a different context.

That is why "copy" is such an important concept in Schematic.

Someone creates a sophisticated schematic for building a consulting business. Another person can copy it, remove the components that do not apply, add their own constraints, connect their CRM, change the economics, and make it their own.

A third person can improve that version.

A fourth can fork it for a different market.

The original remains intact, while the system evolves through its descendants.

This is one of the most powerful properties of open source, applied to a different type of artifact.

From templates to a library of systems

If this works, the public Schematic library becomes more interesting than a collection of templates.

It becomes a library of approaches to problems.

A new entrepreneur might not know everything that is required to build a company. Instead of starting with a blank page, they could find several public company schematics, inspect how experienced operators have structured them, compare the differences, and create a version appropriate to their circumstances.

An existing company could map its current operating model against public models and identify areas where its architecture is incomplete or unnecessarily complex.

A consultant could publish a proven framework.

A researcher could publish a research methodology.

An operator could publish an operational system.

An engineer could publish a technical architecture.

A person could publish a system for accomplishing a highly personal goal.

The platform becomes a mechanism for accumulating and distributing structured expertise.

That has an important consequence.

The unit of knowledge is no longer only the article, document, or answer. It can be the system itself.

Schematic and the agentic era

This becomes particularly relevant as AI moves from generating text toward executing work.

The current generation of AI agents can reason, use tools, interact with external systems, and perform increasingly complex workflows. But an agent still needs an environment in which to operate. It needs a goal, context, available tools, constraints, permissions, inputs, outputs, and a definition of what it is responsible for.

Schematic provides a natural place for those things to exist.

An agent can be assigned to a node.

A node can have explicit instructions and rules.

It can have access to particular external systems.

It can receive information from connected nodes.

It can produce outputs that feed other parts of the system.

A Marketing node might contain an agent responsible for monitoring performance. It could be connected to analytics, advertising platforms, CRM data, and content performance. A parent Marketing node could then aggregate the outputs of its child systems into a broader report.

Finance could have another agent.

Sales could have another.

Operations could have another.

The important thing is that the agents are not the architecture. They are components within it.

This distinction is becoming increasingly important as organizations move toward human-agent operating models. Recent thinking on agentic transformation is already shifting the unit of analysis away from individual tasks and toward redesigned workflows, with humans and agents jointly responsible for execution. The argument is that organizations need to define the future human-agent operating model first and then work backward into implementation, rather than allowing isolated agent pilots to determine the architecture organically.

That is very close to the problem Schematic is designed to address.

The blueprint should come before the agents.

From blueprint to operating system

This is where the concept starts to become more ambitious.

A schematic can initially be descriptive. It tells us how something works or how we think it should work.

Then we can add instructions.

Then data.

Then external systems.

Then agents.

Then triggers.

Then automation.

At some point, the schematic stops being a description of the system and starts becoming part of the system itself.

Consider a company's operating model.

At the top level, we might have Strategy, Marketing, Sales, Operations, Finance, and People. Each contains increasingly granular components. Some nodes are purely informational. Others connect to real systems. Some have humans responsible for them. Some have agents.

The Finance node could connect to accounting data and monitor cash flow.

The Sales node could connect to the CRM and monitor pipeline.

The Marketing node could connect to analytics and advertising platforms.

Operations could connect to project delivery systems.

An executive-level agent could sit above them and synthesize changes across the organization.

The Schematic becomes the architecture through which the organization is understood and increasingly operated.

This creates a progression that we find particularly compelling: a system can first be mapped, then understood, then configured, then connected, then automated, then monitored, and eventually adapted based on what happens in the real world.

The distinction between planning and execution begins to disappear.

Systems should be able to change

This is where the original inspiration from neuroplasticity becomes relevant.

The idea came to me while reading about neuroplasticity and thinking about the way systems evolve. The analogy should not be taken literally. A business is not a brain, and software is not a nervous system.

What is interesting is the underlying principle that a capable system can change its structure in response to experience.

The brain is not a static machine with a permanently fixed configuration. Experience, learning and environmental interaction can influence neural structure and function. Research into experience-dependent plasticity has documented changes in neural connectivity and organization associated with learning and experience.

That made me think about the systems we build.

Why should an operating model be static?

A business changes because its market changes. A sales process changes because customers change. A product changes because people use it differently than expected. A fitness program changes because the person adapts. A research model changes because new evidence appears.

The structure should therefore be able to evolve.

A Schematic should not only describe what a system looks like today. Over time, it should be able to capture what the system has learned.

That means versioning matters. History matters. Evidence matters. The reasons for structural changes matter.

The most valuable schematic might eventually be one that has been operating for years and has continuously adapted based on real-world feedback.

Making complex systems legible

There is a temptation in software to simplify everything.

Sometimes that is correct. Complexity that exists only because of bad design should be removed.

But some complexity is intrinsic.

A large organization is complicated because there are many people, incentives, processes, markets and dependencies. A clinical trial is complicated because biology, statistics, regulation, logistics and patient safety interact. A construction project is complicated because physical constraints, financing, planning, materials and people interact.

Trying to hide that complexity can make the system easier to look at but harder to understand.

Schematic takes a different approach.

The goal is not to pretend that a complex system is simple.

The goal is to make its complexity navigable.

At the highest level, you see the architecture.

At the next level, you see the major subsystems.

At the next level, you see the individual mechanisms.

Eventually, you can reach the smallest meaningful detail.

That is why the canvas is so important. The canvas is not decoration. It is the mechanism that allows scale without forcing the user to consume every level simultaneously.

From understanding to research and monitoring

Once systems are represented structurally, other use cases emerge naturally.

Research is one of them.

Instead of producing a report about a market, you can construct a model of the market and attach evidence to its components. Competitors, customer segments, acquisition channels, economics, technologies, regulations and trends can all become part of the model.

Monitoring then becomes possible.

A research agent can watch specific nodes for changes. A competitor launches a product. A regulatory environment changes. A pricing model changes. A company hires aggressively in a particular area. New evidence emerges around a research hypothesis.

The system can flag the change and indicate where it affects the existing model.

The goal is not to pretend that the software has discovered causality. It has not.

The goal is to maintain a structured representation of what is known, what is inferred, and what has changed.

That is much more useful than repeatedly generating a fresh report from scratch.

Copying and improving entire systems

Competitive intelligence provides another interesting example.

Imagine mapping an entire competitor.

Not just their website.

Not just their features.

Not just their pricing.

Their entire apparent operating model.

How do they acquire customers? What happens after acquisition? How do they qualify leads? How is the product positioned? Where does revenue come from? What appears to drive retention? Which technologies are visible? Which partnerships exist? How does the organization appear to allocate resources?

Once represented as a system, the model can be compared with another system.

What is structurally different?

Where does one system appear to have fewer dependencies?

Where are there obvious bottlenecks?

Which components could be replicated?

Which should deliberately be avoided?

This turns copying into something more sophisticated than imitation.

It becomes structural analysis.

You are not copying what the competitor has built. You are attempting to understand the system that produces their outcome, then deciding which parts are worth reproducing or improving.

The system as organizational memory

There is another consequence that may prove even more valuable.

Organizations forget.

People leave. Teams reorganize. Processes change. Decisions become buried in meetings. A critical piece of operational knowledge can exist almost entirely inside one person's head.

Documentation is supposed to solve this problem, but documentation is often disconnected from the actual architecture of the organization.

A Schematic could provide a more persistent representation.

A new employee could understand how their role fits into the organization.

A new executive could understand the major operating mechanisms without reading hundreds of documents.

A consultant could inspect the architecture and identify gaps.

An engineer could understand which systems need to connect.

An agent could operate within the same environment.

Everyone is working from the same model, but at a different level of abstraction.

The Schematic becomes a form of organizational memory.

Not a static wiki.

A living model.

A possible new layer between knowledge and execution

This is perhaps the simplest way to express the larger opportunity.

Today, we have an enormous amount of knowledge on one side and an increasing amount of execution capability on the other.

We have documents, research, expertise, models and accumulated experience.

We also have APIs, automation platforms, software systems and AI agents that can increasingly perform work.

What is missing is often the layer connecting the two.

Knowledge → System → Execution

The system provides the structure.

It defines what matters, how components relate, what the constraints are, where information comes from, who is responsible, what agents can do, and what outputs should be produced.

Without that layer, AI tends to operate as an intelligent generalist.

With it, AI can operate within a specific architecture.

That is a potentially significant shift.

The open-source opportunity

For Schematic to become truly useful as a general platform, the underlying format should eventually be open.

A schematic should not be trapped inside one SaaS product.

It should be possible to export it, import it, fork it, version it, embed it, build software around it, and allow other systems to consume it.

The hosted Schematic platform can provide the best experience for creating, discovering, sharing and operating these systems, while the underlying representation remains portable.

This opens the door to something larger than a product.

It creates the possibility of an ecosystem around systems themselves.

People could publish operating models. Researchers could publish methodologies. Engineers could publish architectures. Consultants could publish frameworks. Companies could publish their approaches. Communities could build specialized libraries.

A schematic could become a reusable digital artifact in the same way that code, design components and datasets are reusable artifacts today.

The difference is that the thing being shared is not an individual component.

It is the architecture connecting the components.

A new primitive for AI-native software

There is a broader shift happening in software.

For a long time, applications were the primary unit of interaction. If you needed to do something, you found the application designed for that activity.

AI is beginning to weaken that model. A capable agent can potentially interact with many applications on behalf of a user.

As that happens, the question becomes less about which application contains the functionality and more about how the work itself is structured.

This makes architecture increasingly important.

If an agent can access ten different systems, something still needs to define which system it should use, when it should use it, what information it should retrieve, what it should do with that information, what constraints apply, and what happens next.

That something could be a Schematic.

The applications become components.

The agents become components.

The humans become components.

The Schematic becomes the architecture connecting them.

This is the inversion that makes the concept interesting.

Instead of asking which software we should use, we can start by asking what system we need and then determine which people, software, agents, data sources and processes should occupy each part of it.

The long-term thesis

It is difficult to predict which abstractions eventually become foundational.

The most important ones often begin as relatively simple ideas. Their significance comes from what they enable other people to build on top of them.

Schematic is based on a hypothesis that a general-purpose representation of systems could become one of those abstractions.

The primitives are simple enough to be broadly applicable: nodes, relationships, hierarchy, context, rules, inputs, outputs, state, people, software and agents.

But the things that can be represented with those primitives are almost limitless.

A company.

A market.

A clinical research program.

A software architecture.

A construction project.

A sales process.

A personal development plan.

A competitor.

A supply chain.

A strategy.

A goal.

The domain changes. The underlying mechanics do not change nearly as much as we tend to assume.

If those mechanics can be represented in a way that is simultaneously visual for humans, structured for software and intelligible to AI, we gain something that is currently missing from the technology stack.

We gain a common interface for systems.

That interface could help someone understand a complex environment in minutes, while still allowing them to inspect its smallest details. It could allow an inexperienced person to start from a proven system rather than a blank page. It could allow an expert to encode knowledge into something others can reuse. It could allow an AI to reason over a persistent structure instead of generating disconnected answers. It could allow agents to operate within explicit context rather than as isolated automations.

And, eventually, it could allow the schematic itself to become operational.

That is the part that makes this worth pursuing.

We are not trying to build another place to draw boxes and arrows.

We are exploring whether a system can become a first-class digital object: something that can be designed, understood, copied, modified, connected, executed, monitored and continuously improved.

The ambition is deliberately broad because the underlying problem is broad.

Almost everything we care about is a system.

We simply do not have a particularly good way of seeing the whole.

Schematic is an attempt to build one.