George Reid-Dowd

Product & technology leader · operations, AI systems and new products

I build the missing capability.

I take problems without a clean owner and turn them into working products, operating systems and teams.

I can’t leave broken processes alone.

See the work GitHub
From field product to operating systems
  1. 01
    Commercial uncrewed vesselBuild, testing, sale and client deployment
  2. 02
    Regional remote operationsCentre, systems, team and first live service
  3. 03
    Delivery systemsTeams, flow and operating outcomes
  4. 04
    ProductsSoftware, agents and ventures
George's career route A route connects commercial uncrewed vessel delivery, regional remote operations, client delivery leadership and product building. UNCREWED SURVEY VESSEL build · test · sell · operate REMOTE OPERATIONS built a regional capability DELIVERY SYSTEMS teams · flow · outcomes PRODUCTS software · agents · ventures 24.4539° N · 54.3773° E

A few results first

The pattern is easier to judge from the work than from a job title.

Build → operate
commercial USV deliveryBuilt, tested, marketed, sold and operated with the team.
67%
backlog reduction60 active projects to 20 in four months.
<1 year
to the first live remote operationA new regional mandate became a working client service.

Work in practice

An operating capability, an internal product and an open-source system.

Delivered commercial product0→1 regional service

From one commercial uncrewed vessel to a regional remote operations capability.

The first job was concrete: help take an uncrewed survey vessel from build through testing, marketing, sale and client work. The next was less defined: turn what we had learned into a regional service.

The decision: treat remote operations as an operating system, not a room full of screens. I led across hardware, networks, procurement, video, workflows, global alignment and team building so the technical system and the way people worked developed together.

Build → operate
commercial USV lifecycle
0 → 1
regional service
<1 year
to first remote rig move

Career record, 2020: implementation, commissioning, the remote operations centre, remote rig move and regional video-streaming solution were marked complete.

What had to work together

The capability crossed vessel systems, networks, video, procurement, operating workflows, people and global standards. The value came from making those dependencies work as one service rather than treating each as a separate technical project.

Early USV → regional remote operations
Uncrewed vessel work connected to a remote operations centre An early commercial uncrewed vessel, the first remote rig move and Fugro Pegasus as a later regional reference point connect to a remote operations centre. UNCREWED VESSEL BUILT → CLIENT WORK REMOTE RIG MOVE FIRST LIVE OPERATION FUGRO PEGASUS LATER REGIONAL USV REMOTE OPERATIONS CENTRE

A product became a service. The service became a regional capability.

Active internal systemReal-infrastructure validation

See GNSS interference while there is still time to act.

Positioning faults used to surface through vessel reports, screenshots and escalation. Diagnosis could start after the useful evidence had already disappeared.

The decision: move diagnosis from reactive screenshots to passive fleet telemetry. I conceived and built Holocron to capture receiver health continuously, survive intermittent links and give trained operators one live view of what is happening.

  • Working against real GNSS hardware
  • Rust edge agent with local disk buffering
  • Central ingest, history and operator map
  • Passive only: no interface to certified navigation or DP control
$8M / year modelled fleet-utilisation opportunity Business-case estimate, not realised savings.
Why the architecture matters

GNSS receivers feed a native edge service that buffers events locally and sends them over HTTPS. A central service parses and stores them in PostgreSQL/PostGIS. The operator view supports live triage and incident replay even when offshore connectivity is imperfect. The public visual is deliberately sanitised.

Sanitised telemetry model
FLEET HEALTH14:32:18 UTC
Fictional fleet telemetry map with buffered link recovery UNIT ANOMINAL UNIT BLINK LOST UNIT CNOMINAL
EDGE BUFFER 184 events held locally
14:31:48  link degraded 14:31:52  local buffer active 14:32:14  transport restored
Active public productOpen source

Keep the architecture and the code answerable to each other.

Coding agents can make individually correct changes while the intended architecture quietly drifts. A prose plan does not reliably survive the next session.

The decision: make architecture machine-checkable instead of asking the model to remember it. Cairn keeps a living blueprint beside the repository, reconciles the two and can block a conflicting commit.

  • Agent-written blueprint and contracts
  • Brownfield extraction from existing code
  • Local-first files that travel with Git
  • Graph UI, CLI, MCP and commit gates
Source
Plan ↔ reality
A blueprint graph is checked against code and either passes or reports drift BLUEPRINT INGEST AUTH STORE REPLAY RECONCILE REPOSITORY src/ingest.rs src/auth.rs src/store.rs src/replay.rs GHOST FOUNDplanned, not built

A map the agent writes, a gate the model cannot talk around.

Private TestFlight buildConsumer product

A child’s toy becomes a character that remembers.

Generated stories often forget the child, the character and everything that happened before. Each new story starts from zero.

Yarnling turns a photograph of a toy into a persistent character. The story world remembers the child, earlier events and the small details that make a sequel feel like a return.

  1. Photograph a toy
  2. Create its character
  3. Read the first story
  4. Return to a world that remembers
Private build · illustrative product view
Illustrative Yarnling story library view based on the private TestFlight build

Open-source systems

Tools I built to solve problems I kept running into across AI, design and physical systems.

george-rd.github.io/mag
MAGSwitch AI tools. Keep the context.
Early alpha · active public product

MAG

A private, local-first memory system that lets several AI tools share one portable record of decisions, fixes and handoffs.

Memory architecture

Exact, semantic and relationship-aware retrieval share one inspectable SQLite file, with public benchmarks and explicit trade-offs.

Source ↗
george-rd.github.io/openspine
OpenSpineLet your AI earn more responsibility. One job at a time.
Self-hosted personal AI · alpha

OpenSpine

A self-hosted control layer for personal AI. Its reference assistant, Lyra, takes one clear job at a time. Each task is bounded, tested and recorded. The full loop for growing responsibility is still being built.

Progressive delegation

Lyra can learn a repeated job. It cannot promote itself. New routines stay inactive until you approve them. You can limit, pause or remove them later.

Source ↗
george-rd.github.io/design-studio
Design StudioDecide the direction before touching the code.
Active public tool

Design Studio

A multi-agent design workflow that separates visual direction, implementation and blind review before changes reach the existing frontend.

Design as a system

Design judgement becomes a recorded, bounded workflow with durable product context, visual rules and evidence from the rendered result.

Source ↗
george-rd.github.io/growth-arsenal
Growth ArsenalPressure-test the offer before the market does.
Active public tool

Growth Arsenal

Linked workshops that test an offer, lead generation and customer copy. Independent agents attack the market, maths, message and execution plan.

Commercial reasoning

Business assumptions become explicit, reviewable and reusable instead of remaining inside one conversation.

Source ↗
george-rd.github.io/rive-rs-cli
Rive CLIAnimation becomes inspectable from the command line.
Working public build

Rive CLI

A command-line tool that lets people and AI inspect, render and evaluate interactive Rive animation files in repeatable steps.

Agent animation workflow

The same file can be inspected, rendered and scored in repeatable steps, so an agent can check its own output.

Source ↗
george-rd.github.io/cli-anything-meerk40t
MeerK40t CLIGive agents a safe path to a real laser.
Physical AI

MeerK40t CLI

A command line that lets an agent inspect, calibrate and drive a real laser engraver through explicit safety gates.

Physical result

The software has produced a real engraving, moving the proof beyond a simulator or interface demo.

Source ↗
george-rd.github.io/hologlyph
HologlyphA face made from text, speech and expression.
Active public demo

Hologlyph

A talking face for the web, driven by text, speech and expression, with support for custom avatars.

Embodied interface

An agent gains visible presence while the mechanism remains open enough to inspect and change.

Source ↗
Open the lab note 1 early experiment
SkillkeepEarly experiment · source only

Exploring how reusable agent skills can stay portable across different clients.

Source ↗

Products and ventures

These products test the same ownership pattern against customers, families, regulation and production.

reaveshq.com
ReavesHQAgents that work inside real customer workflows.
Live venture

ReavesHQ

An agent services business building assistants for communication and operating workflows where mistakes have real costs.

Commercial application

The work tests agent architecture against customer workflows, communication channels and the cost of getting an action wrong.

Agents · operations · communication
ogmallow.com
OG Mallow product packagingOG MallowA product venture carried through production and sales.
Live family venture

OG Mallow

A family product venture spanning recipe, packaging, sourcing, licensing, production and direct selling.

Production and sales

The idea has been tested against materials, regulation, production constraints and real customers.

Recipe · compliance · production · sales

How I work

Three moves recur across the work above.

  1. 1

    Find what produces the problem.

    Map the incentives, dependencies, handovers, authority and failure paths before accepting the requested solution.

  2. 2

    Build the earliest version reality can argue with.

    Make the idea concrete enough for a user, operator, machine or codebase to prove it wrong.

  3. 3

    Keep the loop open until people can trust it.

    Watch what happens, fix the weak link and document the decisions that must survive the first version.

Building is how I understand the world.

At twelve, I built my first computer. At university, I made an Android app that controlled a Leica laser measure and captured its readings. Years later, I was connecting vessels to remote operations centres.

Now the work spans AI control layers, memory systems, children’s products and tools that drive real machines. I learn by making, then turn what survives into something other people can inspect and reuse.

c. 2001 First computer
University Laser measure app
Operations Connected vessels
Now Agent systems

Start with the problem.

Tell me what is failing, what matters and what has already been tried.

george@reid-dowd.me

Strongest fit

  • Product and technology leadership
  • Digital operations and internal products
  • Agent and AI systems
  • Founder environments and unclear 0→1 work