Landing Gear is a human-auditable service ecosystem and application framework for building trustworthy local-first automation, operator tooling, and AI-backed systems.
Landing Gear began as a practical attempt to build better infrastructure around automation, trust, and AI workflows. Over time, it has grown into a broader ecosystem: a set of purpose-built services, shared architectural rules, standardized contracts, and operator-facing tools designed to make powerful systems visible, understandable, and governable.
At its core, Landing Gear is built around one guiding principle:
¶ Each service should own one kind of truth.
A service should have a clear role. It should know what it is responsible for, what it is not responsible for, and how it communicates that truth to the rest of the system.
That idea shapes nearly everything in Landing Gear.
Landing Gear is best understood as two closely related things:
The Landing Gear kernel is a small, explicit foundation for building services in a consistent way. It provides shared patterns for things like:
The goal is not to hide how a service works. The goal is to make every service easier to build, easier to inspect, and easier to operate.
The Landing Gear ecosystem is the family of services built on top of that framework.
These services include, or are planned to include:
workspace:// resource addressingNot every service is equally mature today. Some are implemented, some are actively being designed, and some are long-range architecture. This wiki exists partly to make that difference clear.
Modern software systems, especially automation-heavy and AI-assisted ones, become messy very quickly.
A project starts with a few scripts. Then it needs authentication. Then approvals. Then logging. Then a UI. Then workers. Then artifact storage. Then a task queue. Then a way to understand what happened three weeks ago. Then a way for a human operator to intervene without tearing the system apart.
The usual answer is often:
“Just bolt together whatever existing tools already do each piece.”
That can work, but it often creates a system that is technically functional while becoming increasingly difficult to reason about. It produces:
Landing Gear takes a different path.
It builds a small, coherent ecosystem of services that are designed to cooperate from the beginning. Each service has a role. Each major cross-service interaction should have an explicit contract. Actions should leave receipts. Sensitive operations should pass through visible gates. Trust should be a system feature, not an afterthought.
Landing Gear is not just an app platform, and it is not just an AI agent framework.
It is an attempt to build a legible operating environment for complex, human-supervised automation.
A technically skilled human should be able to inspect the system, follow its logic, and understand why something happened.
That means:
Permissions, approvals, and security boundaries are not background implementation details. They are part of the system’s meaning.
Landing Gear uses ideas like:
These are not only technical structures. They are also part of how the system communicates trust and consequence to operators.
Landing Gear services are meant to work together closely, but not become one giant blurred application.
For example:
That division of responsibility is one of the most important ideas in the whole project.
Landing Gear can be loosely understood in layers.
These services make the rest of the ecosystem trustworthy and operable:
These services organize jobs, tasks, state, and flow:
These services handle communication, personality runtime, and intelligent behavior:
These services make agents feel present, responsive, and embodied:
These layers are not hard walls. They are a way to understand how the system grows from core infrastructure into richer forms of interaction.
Imagine an operator says through Chat:
“Maki, can we add an easter egg where clicking your avatar too many times makes you get annoyed and push the mouse cursor away?”
A future Landing Gear flow might look like this:
That entire chain should be understandable, inspectable, and governable.
That is the Landing Gear mindset.
Landing Gear is an active evolving project, not a completed product.
Some parts are already substantial. Others are established designs waiting for implementation. Others are future concepts that have been discussed deeply enough to deserve documentation, but still need engineering passes before they become real services.
Broadly:
The wiki should always distinguish between:
This wiki is intended to become the canonical documentation home for Landing Gear.
It should serve several audiences at once:
A place to preserve the actual shape of the system so that important ideas do not disappear into old chat logs or half-remembered decisions.
A readable onboarding path into the project’s purpose, vocabulary, architecture, and service boundaries.
A stable source of truth that helps implementation work stay aligned with the intended system rather than drifting into accidental redesign.
A manual for understanding what the system is doing, how trust works, how services relate to each other, and where to look when something breaks.
For a first pass through Landing Gear, read these pages in order as they are written:
After that, move into the service pages:
Landing Gear is ambitious, but the ambition is not just “make a lot of software.”
The real ambition is to build software infrastructure that remains:
Landing Gear is a system built around the belief that good architecture should make meaning clearer, not harder to find.
Welcome in.