REST: An AI-Based Engineering Leadership Operating System

Why I Built This

In my current role, I carry far more context than I can comfortably keep in my head. I lead four teams with diverse responsibilities, each with its own priorities, blockers, people dynamics, risks, and moving parts.

That kind of cognitive load adds up quickly in practice and reduces decision-making quality.

I needed a way to keep track of what matters, rather than spending my days focused on admin. So I created REST AI: Reflect, Evaluate, Strategize, Track. It is an AI-assisted, markdown-based, local operating system for engineering leadership, built around simple files, simple rules, and a lot of iteration.

What It Does

REST helps me collect the important signals, interpret them, and action them, including tracking risks and items under executive attention.

It gives me a place to keep track of:

• What teams and individuals are working on without having to consult Jira
• What is allocated where
• What is blocked
• What risks are emerging
• What decisions have already been made
• What still needs following up

The inputs come in from systems like Jira, Trello, and Slack, and that part is automated. I do have to waste time copying and pasting admin from one tool into another.

Instead, I drop interesting updates into the system, talk to it about what matters, and let the AI help me organise the noise into something useful. I often do that conversation by voice typing, because that is faster and closer to how I actually think. Think of it as a pair programming session with an experienced leadership assistant who is helping you keep track of the most important things.

How It Works

The underlying structure is deliberately boring:

• A Git repository
• Markdown files
• Prompts and lightweight workflow rules
• A generated dashboard
• AI assistants I can pair with like another engineering leader in the room

The key idea is that the AI is not making the decisions for me. I discuss things with it, compare what it is seeing against the GitHub or git diffs, and use that workflow to keep track of what is changing so I do not let the AI run away with the process. It helps me gather context, compare signals, spot contradictions, and think through the next move.

That means I can use it for things like:

• a daily brief that surfaces the top priorities
• an action list of things I need to do or delegate
• a risk register for things that could go wrong
• a decision log so I do not revisit old calls
• a dependency view so cross-team work does not disappear

Reflect, Evaluate, Strategize, Track

The name REST is a shorthand for how I want the system to behave.

• Reflect on what has happened and what has changed.
• Evaluate what is actually important.
• Strategize about what to do next.
• Track the things that need continuity.

That is the real value here: not more data, but better judgement with better context.

Keeping It Healthy

One thing I have learned quickly is that these systems can become noisy if you let them.

So I am deliberately iterating on it over a few weeks, tightening it up as I go, and making sure stale context gets removed. If something is no longer relevant, I want prompts and workflows that help me mark it as such and keep the system lean.

The repository keeps historical tracking, but the day-to-day view should stay clean. Old dead context is just noise if it is not actively useful.

That also means I need to keep improving what gets tracked, what gets ignored, and what gets retired.

Why This Matters

I do not think this is just for engineers. Any leader dealing with too much context, too many moving parts, and too many decisions could use something like this.

The bigger lesson is that AI becomes much more useful when you give it structure and context. A plain Git repo, some Markdown, a few prompts, and a bit of discipline can go a long way.

You do not need a huge platform to start. You need a useful system, a willingness to iterate, and a clear idea of what you want the AI to help you think about.

File Structure

This should give you an idea of the inputs, outputs, and structure of the system:

├── AGENTS.md
├── CONVENTIONS.md
├── README.md
├── context
│   ├── delegation-model.md
│   ├── escalation-rules.md
│   ├── fy27-goals.md
│   ├── operating-principles.md
│   ├── ownership.md
│   ├── people.md
│   ├── platform-dependencies.md
│   ├── systems.md
│   ├── teams.md
│   ├── terminology.md
│   ├── work-allocation-filters.md
│   └── working-style.md
├── inputs
│   ├── confluence
│   │   ├── _source.md
│   │   └── snapshot.md
│   ├── jira
│   │   ├── ecommerce
│   │   │   ├── _source.md
│   │   │   └── data.csv
│   │   ├── inlife
│   │   │   ├── _source.md
│   │   │   └── data.csv
│   │   ├── platform
│   │   │   ├── _source.md
│   │   │   └── data.csv
│   │   └── shared-capabilities
│   │       ├── _source.md
│   │       └── data.csv
│   ├── slack
│   │   ├── _source.md
│   │   └── data.md
│   └── trello
│       ├── _source.md
│       └── data.csv
├── outputs
│   ├── action-items.md
│   ├── cross-team-dependencies.md
│   ├── daily-briefs
│   │   ├── 2026-05-08.md
│   │   ├── 2026-05-27.md
│   │   ├── 2026-05-29.md
│   │   ├── 2026-06-02.md
│   │   └── 2026-06-05.md
│   ├── decision-log.md
│   ├── risk-register.md
│   ├── stale-items.md
│   └── work-happening-in-each-team.md
├── prompts
│   ├── ad-hoc-update.md
│   ├── blocker-escalation.md
│   ├── daily-brief.md
│   ├── ingestion-check.md
│   ├── stale-items.md
│   └── unknown-terms.md
├── scripts
│   └── build_dashboard.py
├── system-improvements
│   └── dashboard-improvement-suggestions.md
├── templates
│   ├── decision-entry.md
│   └── risk-entry.md

Closing Thought

REST is still evolving, but that is the point.

It is a practical, AI-assisted operating system for leadership work. It helps me deal with context overload, make better decisions, and stay on top of what matters without drowning in admin.

That is enough for me to keep using it. And it is probably enough for other leaders to start building their own version too.