How Matrix Land SI works

The previous article moved from Excel to SSOT and ended with a question: if software can be generated as the business needs it, what should a company hold steady, and what should it leave to individual colleagues? Matrix Land SI begins with that question.

Previously, a department needing a tool had to translate its work into requirements and then wait for product design, development, testing and release. Some needs were too small even to enter the queue. People returned to Excel, using a spreadsheet, a few files and chat messages alongside existing systems to get things done. How a company actually works often lies between its systems.

AI coding gives colleagues a chance to turn that work directly into applications, while agents can call business capabilities across application interfaces. New questions follow: when everyone can create, who ensures that a customer remains the same customer, data is not copied independently everywhere, applications do not quietly gain extra permissions, and what was built can still be found and used next week?

We handle these concerns separately. Business colleagues create the parts closest to their work; the platform supplies shared foundations for identity, permissions, information, runtime resources and release records. Matrix Land SI takes on the work between those two sides that previously demanded repeated coordination.

What interests me most in this diagram is the AI Capability Commons in the middle. The business teams above have their own customers, processes and professional judgment; engineering and operations support sit below. The middle layer puts models, knowledge, application creation and cloud resources into business colleagues’ hands. It serves every department while letting each create something different.

Within the platform, LEGO manages applications, resources and releases; Knowledge stores information and versions; Mate handles conversations and tasks; Workspace MCP supplies tool entry points; and Auth supplies trusted identities and authorization. Connecting these capabilities lets colleagues concentrate on their business. Defining business objects and deciding which actions to expose still requires each business unit’s ongoing work.

Looking at a company’s systems, it is easy to notice software brands first: which ERP and CRM it uses, where documents live and which page contains reports. I would rather begin by asking where the company’s facts live and who has authority over them.

When a transaction occurred, what the customer authorized at the time, which rule version applied and why something was later adjusted: these are records left by actual business and decisions. Buying better software or connecting a stronger model cannot reconstruct that history on the company’s behalf.

For this platform’s design choices, I therefore treat data as the one digital asset a company must continuously accumulate and retain control of. Data includes business records, contracts, research, rule versions and processing results. Models can change, interfaces can be rebuilt and programs regenerated. Events that occurred and the grounds for decisions at the time are much harder to recover once lost.

The container changes; the underlying event remains

This data broadly lives in three kinds of places. First are existing systems such as ERP and CRM, with clear structure and limited flexibility. Second are applications built by departments themselves, which I prefer to call Local Apps: tools for the specific work of a function or group. Third are documents, spreadsheets, emails, recordings and other media, where expression is flexible but establishing the facts takes more work.

From the first category to the third, we generally move from high structure and low freedom to low structure and high freedom. Much of a company’s digital transformation over the past decade involved moving work from the third category to the first. The second now gives colleagues a way to organize their own smaller scope of work without waiting for a company-wide systems project each time.

Agents can access all three categories through tool interfaces. But connecting an interface only makes data readable and operations callable. When two documents contradict each other, or two systems call the same customer “active” using different definitions, no model can decide on the business owner’s behalf which one counts.

SSOT: authoritative, unique and clearly defined

The SSOT discussed in the previous article must be grounded in specific business objects. For a customer, which identifier establishes identity, who maintains the basic information and which source do other applications reference? Keeping a copy for convenient display does not give an application a new customer master record it can independently modify.

“Unique” needs a scope. A customer’s legal name, service relationship and latest contact time may each belong to different business functions. Revenue recognized by finance can differ from sales performance calculations. What must be unique is the agreed place to obtain a number within a defined question, object and time range, with an explanation of how it was calculated.

For example, departments will naturally report different “new customers this month” if no one specifies whether that means account opening, approval or first transaction, or which time zone defines the month. Putting the numbers into one database table will not remove the disagreement. First define the question, then establish the sources and calculation rules.

Ontology: describe business objects and permitted actions together

SSOT tells us where facts come from. Ontology further tells users what those facts mean in the business. It describes objects such as customers, accounts, products and orders, who owns which accounts, which customer an order belongs to, and which actions an object permits under which conditions.

A customer table alone is insufficient. Does “customer” mean a natural person, a legal entity or a service relationship? How are one person’s multiple accounts linked? Does closing an account end the customer relationship? Who may update contact details or change service status? Distinctions that business colleagues understand through experience need to become explicit.

Sales then sees customers to follow up with, operations sees materials and processing status, and other colleagues see information appropriate to their responsibilities. Their pages and generated views may differ, while object identities and factual sources still align. If a view reveals an error, it should request correction from the owner of that fact rather than create its own competing version.

Ontology therefore needs ongoing involvement from business owners. A system can find matching names, detect conflicts and add relationships. But what counts as “complete” or which status may proceed to the next step still comes from the organization’s own agreements. Giving old fields new terminology does not solve that problem.

What stays the same when agents replace manual operation

Traditional programs calculate according to written logic. LLMs can handle ambiguous descriptions, make inferences and write code for precise calculations. In terms of business outcomes, both often do the same two things: move an object from one state to another, or produce a new record.

What changes is how those facts are operated on. Previously, people opened applications and followed pages and processes step by step. Agents can now consult documents, call interfaces, run programs and assemble the results. Either way, inferences must be distinguished from confirmed facts, and updates must go through the responsible business interface. A model saying something “should be complete” cannot replace an actual completion record.

As application interfaces become easier to generate, the data retained by the company matters even more. Today’s apps and tomorrow’s agents both use it. We need to progressively organize object definitions, sources, relationships and operating rules so new tools can continue working from accumulated business knowledge.

The previous section singled out data because what changes next is the computation used to work with it. Business people once operated interfaces while programs executed predefined logic. Increasingly, models can take on judgment and execution. We need to reconsider which steps must be fixed in advance and which methods AI may choose as work progresses.

There are two kinds of freedom here. Computational freedom concerns how each step interprets inputs, makes judgments and produces results. Path freedom concerns what happens first, what follows and whether a new situation permits a different approach. Along the path toward direct delivery of business outcomes, both are gradually opening up.

Stage one: UI-driven work, with computation and paths predefined

In traditional software, people open pages, fill fields and click buttons; programs process inputs using precisely defined rules. Formulas, conditional branches and subsequent actions are usually written during development. A page may support many operations and a workflow many branches, but someone must first define the paths the program can take.

For document checks, a system can verify uploads against a checklist and validate dates and required fields. An unusually named document that might nevertheless meet the requirement often needs human attention or an added rule. A program does not independently consult another source simply because it understands the purpose of the work.

Computational and path freedom are both limited. Outside the system, people constantly add judgment: opening an attachment, checking another system and returning to continue. Much work is really performed by a person moving through several pieces of software.

Stage two: workflows fix the path; AI computes within nodes

Next, we put models inside workflow nodes. After receiving a file, AI identifies its contents and classifies it before checking, approval and archiving. Judgments that were difficult to encode as precise rules can finally be handled by a model.

But the overall task remains bounded by the workflow. A model may understand complex material, choose wording and classify within a node; where it goes next is usually decided by predefined connections and branches. Some computational freedom has opened up, while path freedom remains with the workflow author.

Suppose AI detects conflicting information in two places. If the workflow only offers “pass” and “return,” those are its choices. It cannot naturally reorganize the task as “check another authoritative source first, then decide” unless the author has drawn that route in advance.

Freedom in this model therefore largely remains inside individual nodes. Even sophisticated reasoning within a node leaves the overall strategy constrained by existing paths. Changing the method often requires a person to revise the workflow. This constraint is useful for work with a mandatory sequence and explicit requirements at every step; it does not automatically give AI room to reorganize the entire task.

Stage three: a harness sets boundaries; AI chooses methods and paths

Go a step further and we give AI a task with acceptance criteria, specifying available information and tools, actions requiring confirmation, and conditions that require it to stop. The AI can decide where to look first, how to verify, whether to retry and whether to change methods based on execution results.

For document checking, the goal remains a supported inspection result. AI can read files, query authorized business records when it finds a conflict, and then decide whether additional material is needed. Provided it respects data, action and responsibility boundaries, it need not follow the same route every time.

This calls for a harness. It brings together objectives, tools, runtime state, permissions, checks and human takeover, providing a real operating framework for AI judgment and execution. We no longer need to enumerate every possible path in advance, but we must constrain behavior and inspect what was ultimately delivered.

What opens up here is the choice of method and path. Precise computation still belongs in suitable programs, and mandatory business steps remain fixed. A harness can invoke an existing workflow; AI can also decide that a verified process is the appropriate way to handle a task. Different approaches can coexist within one task.

What must become explicit when freedom expands

Previously, some restrictions were encoded in pages and paths: a button could not be clicked, a step could not be skipped, or a branch did not exist. Once AI can choose its own method, those restrictions must be enforced on data and actions. Taking a different route must not expose unauthorized information or bypass a required approval.

Data reads and writes must therefore strictly follow permissions. Actual services check which objects may be read, which fields may change and whose identity is used. A reasonable objective does not automatically confer additional authorization. Asking AI to “get it done” is not the same as giving it every resource.

Methods must also be supported by evidence. What information it read, why it chose the data, what calculations it performed, which tools it called and whether the results support its conclusion should all be verifiable. That evidence comes from sources, computation and execution records. A convincing explanation alone cannot prove the work was completed.

Acceptance and exceptions belong in the same framework. Completion criteria, result checks, retry conditions and handoff points need explicit arrangements. Asking AI to deliver means advancing the task to an acceptable result; the business unit remains responsible for standards, permissions and taking over out-of-scope situations.

The other end of the spectrum: assistance with a human at the wheel

The evolution above is described from the perspective of directly delivering business outcomes. A parallel path has always existed: from chatbots to task-executing agents, people remain alongside and lead the work. The agent becomes more capable while continuing to act as an assistant.

This path particularly suits open-ended, exploratory and heuristic collaboration. Learning a new field reveals gaps in understanding as questions develop. Research may produce evidence that overturns an initial hypothesis. A one-off coding demo often needs to run before its creator understands what they really want.

At the outset, goals and acceptance criteria may be unclear. Human participation continually changes the task itself. Agents can find information, offer counterexamples, run experiments and modify code while people judge which directions are worthwhile. Understanding and inspiration gained in the process are themselves part of the result.

Assistance therefore has natural advantages. Researchers need to see how evidence produces conclusions, learners need to develop their own understanding, and application authors need to form judgments through use. An agent’s ability to work independently for a long stretch does not require surrendering direction and final judgment to it.

Support both ends—and their meeting within a task

The trend we see is that LLM computation can handle increasingly complex routine tasks and also participate in exploratory work. The platform must support both: delivering agreed business outcomes at one end, and learning, research and creation with people at the other. Many concrete divisions of labor lie between them.

Exploration may produce a clear subtask. Once a researcher knows what to verify, they can assign data checks to AI for independent completion, then discuss new explanations when results return. Conversely, an unfamiliar situation in routine work can become a joint human–AI judgment, followed by a decision on whether to incorporate the new method into future operation.

Different departments, task capabilities, compliance constraints and user experience place the same technology at different points on the spectrum. Some situations suit direct delivery; others need a few human decision points or continuous participation. The position should follow the specific task, observed performance and acceptable authorization scope.

AI computation first means seriously considering which understanding, judgments and actions AI can perform, then arranging human decisions, strict data permissions and verifiable outcomes around them. This orientation can also be called AI Maxxing: making full use of AI computation while bringing it into the company’s business and responsibility structures.

As an early user of Monica and Manus, I have often explained what I see as Manus’s competitive strength: noticing extremely small details, then continuing to solve them. Individually, these may not look like major features. Together, they become something others find difficult to catch up with.

I remember red starting a group chat in the middle of the night to solve edge cases such as image recognition failing because of a VPN environment and S3 storage. This stays with me because such a problem rarely appears in a polished product plan. For the affected person, the image simply could not be read and the work was stuck. Continued use depended on someone being willing to fix it.

Large companies may have enough engineers and know how to make the repair. But a detail passed through classification, prioritization and scheduling can easily be dismissed as too unusual or too small. The process looks rational while gradually making real usage problems invisible. The first barrier to hands-on work is whether we can—and are willing to—notice.

The same applies to frontline colleagues creating applications. People doing a job every day know which fields invite mistakes, which steps require another message in the group chat and which cases cannot follow the default process. Many needs are too small for a project but large enough to waste half an hour each day.

What Manus 2.0 suggested to me

Reading about game development in Manus 2.0, what struck me most was how it keeps people involved. Once a game runs, people still need to tune its feel, change assets and invite friends to play. Having the model write code completes only part of the work.

Parameter panels let people adjust speed, gravity and difficulty while playing; asset management lets them replace characters, visuals and sound; hosted multiplayer services put the result into friends’ hands. These solve three distinct questions: “Can I change it?”, “Can I make it my own?” and “Can others actually use it?”

Enterprise applications need the same capabilities. After a first version, business colleagues should be able to change fields, sorting and presentation through actual use, manage templates and files, share the application with authorized colleagues, and know how to restore service when a later modification goes wrong.

An operations colleague building a document-follow-up tool may discover that sorting by submission date is unhelpful; what matters is which document is missing. Later, they realize that repeated submissions from one customer should appear together. Participation in each revision lets the tool approach the real work. Re-explaining every detail to someone outside the situation can easily lead back to the original scheduling problem.

Why AI coding is an important entry point

Much enterprise work already runs through software, particularly in finance: document collection, customer service, operational processing and research records all contain digitizable work. AI can participate directly in changing the programs that carry it.

One reason I value AI coding is that code provides relatively clear feedback. We can check whether a program runs, a field is saved, a calculation matches a known example or an unauthorized user can gain access. Business colleagues can also test real examples and point out incorrect results.

That inspectability makes AI coding a practical route into enterprise work. Reliable applications still need validation, maintenance and owners. But many ideas previously expressible only in words can now quickly become versions people can try and change. People supply business judgment; programs turn it into reusable tools.

Local App: for these people and this particular job

I prefer the term Local App. “Local” means belonging to a specific function, department or working situation. It can run in the cloud and serve only a dozen colleagues. Its right to exist depends on whether it solves their problem.

When software was expensive to create, we often required a new application to satisfy many departments. Combining requirements meant compromising specific details. With lower creation costs, an application devoted to missing documents, meeting preparation or a particular kind of review can now receive serious attention.

As departmental applications multiply, the main danger is that each builds its own customer table or employee list. Interfaces and working methods can fit the department, while authoritative facts continue to reference their proper sources. A small application may eventually be retired, but the formal records and files it handled should survive for subsequent tools to use.

From an idea to a product requires a maintained system

Bringing “Vibe Anything” into daily production often runs into problems outside the model: where code versions live, how applications deploy, how files are stored, how databases evolve and who to contact when something breaks. These tasks are highly structured and full of details. Requiring every business colleague to learn them from scratch restores the barrier to creation.

An idea therefore still needs a system behind the creative process before it becomes a product. Someone must manage versions, deployment, assets, data structures and access rules. Technical details may be hidden, but they must actually work. A conversation saying “published successfully” cannot replace them.

This is also why I think the cloud could become a super app in the AI era. Computation, storage, databases and networking already live there, and models and agents need those capabilities. Products such as Cloudflare offer engineers many combinations, but the left-hand menu alone can discourage business colleagues. There is still much to do to make cloud entry points easier to use.

Matrix Land SI’s LEGO takes on part of that work, connecting application identity, code, resources and released versions so creation has somewhere to land. Auth handles identity and permissions; Knowledge handles shared information; business interfaces remain responsible for their records and rules. Business colleagues need not build the entire infrastructure themselves, but someone must continue looking after the applications they create.

Wrapping large models and wrapping cloud services are already difficult, messy jobs. Turning mature capabilities into services ordinary people can use requires getting the details right one by one. Distribution here means something concrete: a colleague who could not previously deploy an app can finally share a tool with the team—and still change it tomorrow if it is wrong.

An employee once opened several applications to perform separate steps. Agents can connect those steps and improve efficiency, but they also expose permission questions previously hidden in the interfaces. Whose identity is used? Which customers are visible? Does reading a file permit editing it? When calling tools on another Mate’s behalf, do permissions grow along the chain?

These questions need answers before tools execute. Adding identity and authorization after applications are built and used easily becomes a patchwork of exceptions.

Unify the calling method and basis for identity

MCP gives agents a consistent description of tools and a way to call them. Querying knowledge, reading business records and maintaining applications need not be taught separately in every workbench. Workspace MCP organizes these entry points so authorized agents can discover tools, understand parameters and make calls.

MCP itself, however, does not decide who may see whose customers. Matrix Land SI’s unified entry point must work with Auth, Knowledge and each application’s permission checks. Employee identity comes from trusted login and authorization flows; resource services still decide whether a specific operation is permitted.

If a salesperson says “organize my customer information,” the agent must act for that salesperson and retrieve data under their permissions. A more privileged tool creator does not justify giving the caller everything the creator can see. Calling a Mate likewise does not grant all permissions of its owner.

Entering an app, managing it and changing business records are different permissions

A colleague may open an application but not publish a new version, or develop it without any reason to read every customer record. Reading knowledge, editing it and managing its members are also different permissions. Distinguishing them lets business teams confidently involve more people in creation.

Every mode on the collaboration spectrum must respect these distinctions. An assistant in a workbench acts for the current employee and cannot exceed their authorization. An agent delivering results directly needs an explicit runtime identity, available resources and action scope. Choosing its own path does not justify unrestricted administrator access.

In Matrix Land SI’s current Mate runtime, Knowledge and app calls still check the actual employee’s authorization, while the published Mate configuration can further narrow tool scope. A Handbook may describe working methods; it cannot grant itself database permissions through prose. Future automated work must likewise make runtime identities and authorization relationships explicit.

Enforce rules at execution so tools can combine freely

If every new application needs its own login, keys and guessed department lists, business creation soon stalls. Shared identity, resource authorization and MCP interfaces address recurring work so application authors can concentrate on business details.

At the same time, the service responsible for an action must enforce its rules. A customer query checks which customers are visible; a status update checks permitted transitions; Knowledge checks who may edit a file. These rules must hold when models or workbenches change, or when an action becomes part of an automated task.

Only then can departments confidently build small applications and delegate some repetitive work to digital colleagues. Pages, methods and combinations of capabilities can change without repeatedly redefining company identity and data ownership.