Aerospace × AI systems

From flight controls
to agent systems.

I’m Matthew Mangano. I build aircraft simulations, engineering tools, and the infrastructure around AI agents—with the same attention to models, interfaces, and verification.

Explore selected work ↓How I work with teams ↗
LinkedIn ↗GitHub ↗ControlStackAI ↗
SOUTHERN CALIFORNIA · OPEN TO BAY AREA OPPORTUNITIES
Physical systemsFLIGHT DYNAMICS / CONTROLS / REAL-TIME I/O
Agent infrastructureAUTHORITY / DURABLE STATE / RECOVERY
Tools for engineersREPRODUCIBILITY / REVIEW / HANDOFF

01 / Selected work

Ideas, carried into systems.

Independent projects alongside applied aerospace engineering. Open the case studies for the problem, contribution, and evidence.

01 — AUTHORITY & APPROVAL

GatekeeperOS

An agent may need one resource, not every credential its operator owns. GatekeeperOS separates resource access from the decision to make a change real.

TypeScriptCapabilitiesOpen source
Read the case study

The problem

Tool access often hides several decisions: which resource, which agent, which operation, and who approves the effect. A useful permission model needs to make those decisions explicit.

My contribution

Developing an independent operations layer around OpenClaw, with scoped grants, gatekeeper drivers, pending actions, and reviewable audit records. Work is AI-assisted; upstream platforms and dependencies are credited separately.

The design choice

Keep authorization in the kernel and resource behavior in typed drivers. A pending action can be inspected before application; a proposed effect is not represented as a completed external change.

Evidence & scope

Public source and dated acceptance records. Release compatibility and driver coverage are explicit in the project documentation. This is an operations layer—not a Linux distribution or a sandbox for hostile same-user code.

Explore source & acceptance records ↗
02 — HUMAN–AGENT INTERACTION

ALINA / Agentic Desktop

A conversation that belongs to the desktop, with visible work state and review controls—not a chat window that disappears when its UI process closes.

NixOSQML / Node.jsSystems integration
Read the case study

The problem

A desktop assistant spans a compositor, UI, agent runtime, and network connection. Treating all of that as one disposable process makes interruptions hard to explain and recover from.

My contribution

Product direction and AI-assisted integration of a resident conversation service, desktop UI, agent status, and declarative Linux configuration. The implementation builds on OpenClaw, NixOS, Hyprland, and Quickshell.

The design choice

A local daemon owns conversation state and the outbound queue; QML is a reconnectable view. Stable request identities support retries. The desktop exposes queued, working, and review-needed states.

Evidence & scope

Local daemon/QML source and dated deployment notes. This portfolio’s systems map is an original explanatory illustration, not a captured product screen. The architecture separates a persistent conversation service from its reconnectable desktop view.

Source-reviewed architecture · private implementation
03 — APPLIED AEROSPACE

Flight dynamics & controls

Aircraft simulation and engineering tools that connect control-law design, software testing, and the next engineer’s workflow.

MATLAB / Simulink6-DOF simulationEngineering practice
Read the case study

The problem

A controls team needs models and test environments with clear assumptions, consistent interfaces, and results that can be reviewed and repeated.

My contribution

My aerospace work spans flight controls, six-degree-of-freedom simulation, real-time integration, and verification tooling. At Aerospace Control Dynamics, I led a three-person team testing flight-control computer software, designed the test environment, analyzed results, and recommended and implemented control-law updates.

The engineering judgment

Make units, reference frames, requirements, and validation assumptions explicit. Numerical consistency matters, but a model also needs a stated basis in physical evidence.

Scope

This is a summary of my engineering experience, not a downloadable client case study. Customer code, models, test results, and technical artifacts are not published here.

Professional experience · high-level overview
04 — EXECUTION & RECOVERY

Dark Factory

A durable workflow controller for issue-backed agent work. The difficult part is not starting a task—it is deciding what happened after an interruption.

Go / SQLiteState machinesOpen source
Read the case study

The problem

An agent can finish after its lease expires; a process can disappear after a side effect but before an acknowledgment. Retrying everything blindly can duplicate work or advance on stale results.

My contribution

Developing an independent controller with durable workflow state, bounded execution, expiring leases, fencing tokens, and immutable review packets.

The design choice

Bind completion to the reviewed artifact and current execution generation. Persist transitions and ambiguous outcomes. When dispatch history is uncertain, block for reconciliation instead of assuming another attempt is safe.

Evidence & scope

Public source documents the controller and forced-restart proof using fake external services. That evidence is distinct from live production-provider acceptance or a packaged release.

Explore controller & recovery design ↗
05 — AGENT-ASSISTED LINUX

Agent Installer

Bring a local assistant into a Linux live environment—before the user has an installed system or knows which terminal commands to run.

Codex CLIArch / NixOSOpen source
Read the case study

The problem

Installation and recovery begin in an unfamiliar environment. Network readiness, sign-in, distribution differences, and data-preservation decisions all need to be understandable.

My contribution

Developing an agent-assisted live environment with embedded Codex CLI, shared onboarding and identity, readiness checks, and separate Arch and NixOS image adapters.

The design choice

Keep the distribution’s image builder separate from the agent runtime. Pin build inputs and keep credentials in private RAM storage during the live session.

Evidence & scope

Public development source and documented verification boundaries. These are assistant-enabled live environments, not a qualified physical-disk installer. Graphical onboarding and broader distribution support are future work.

Explore installer source ↗
06 — RESIDENT SYSTEM ASSISTANCE

OpenClaw System Agent

A local assistant that stays with the installed Linux computer, with its own lifecycle, private state, and explicit operating capabilities.

OpenClawLinux servicesOpen source
Read the case study

The problem

A useful system assistant needs to survive reboot, preserve the owner’s context, and distinguish what it can inspect from what it can change.

My contribution

Developing a resident assistant with environment inspection, private state, native service adapters, backup and recovery, and a narrow owner-authorized operations broker.

The design choice

Separate the live installer from the resident agent. Keep the daemon unprivileged and make supported operations explicit rather than granting general administrative access.

Evidence & scope

The public repository records isolated NixOS VM lifecycle tests, including reboot and backup/restore. It remains a development prototype; Arch packaging and experimental USB setup have their own qualification boundaries.

Explore resident-agent source ↗

02 / How I think

Different systems. Related questions.

Make the permission boundary visible.

Resource→Scoped grant→Proposed action→Decision

GatekeeperOS treats reading a resource and applying a change as different decisions. An agent’s intention is not itself authorization.

03 / Working with people

Technical ownership.
Shared understanding.

Leadership is clearest in the work: defining the problem, maintaining interfaces, and helping others use the result.

Lead testing into control-law updates.

At Aerospace Control Dynamics, led a three-person team testing flight-control computer software; designed the test environment, analyzed results, and recommended and implemented control-law updates.

EXAMPLE / FLIGHT-CONTROL SOFTWARE TEST LEADERSHIP

Improve the team’s tools.

Build simulation standards, analysis tools, and repeatable environments. Prior work includes requirements traceability for engine software and leading MATLAB/Simulink toolchain upgrades.

EXAMPLE / REQUIREMENTS & TOOLCHAIN OWNERSHIP

Direct AI-assisted work.

Set the engineering objective, divide work into bounded tasks, and review the result against the system’s constraints. Coding agents help implement and investigate; engineering responsibility stays with the human.

EXAMPLE / HUMAN-DIRECTED AGENT WORKFLOWS

04 / Background

An aerospace foundation.
A broader systems practice.

My work spans flight controls, six-degree-of-freedom simulation, real-time integration, and verification tooling. Today, I apply that background both to aircraft engineering and to the software around AI agents.

I’m interested in teams building research tools, autonomy infrastructure, and systems that engineers can inspect and improve.

MATLAB / SIMULINK · PYTHON · C/C++
RUST · GO · TYPESCRIPT · SQLITE
NIXOS / LINUX · REAL-TIME INTEGRATION
Mangano ConsultingCurrent engagement: Merlin Labs
Electra.aero / ACDControls, simulation & engineering tools
Belcan / GE AviationEngine software & verification
Gulfstream AerospaceFlight controls & simulation
University of CincinnatiB.S. Aerospace Engineering, 2006

Let’s build something worth trusting.

Engineering tools · Aerospace systems · AI-agent infrastructure

Get in touch ↗