REST: An AI-Assisted Operating System for Engineering Leadership

Executive Summary

REST is an AI-assisted operating system for engineering leadership. I built it because cross-team leadership creates a context problem: keeping enough of the organisational picture in your head, at the right altitude, to make good decisions.

The aim is not to outsource judgement. It is to support it, surface what matters, and reduce the chance that important context gets lost across multiple teams.

And yes, I know that REST is an overloaded term in engineering. I used it deliberately, and I rather like the cheeky acronym overlap.

Workflow Diagram

In this diagram, orange represents human actions and blue represents machine actions.

Why I Built This

In my current role, I carry more context than I can reliably hold in my head.

I lead four teams, each with its own priorities, blockers, people dynamics, risks, and dependencies. The challenge is not only making decisions; it is keeping enough of the organisational picture in view to make good ones.

That kind of load accumulates quietly. The risk is drift: weaker judgement, missed dependencies, and decisions made from an incomplete picture.

I wanted a better way to keep track of what matters without depending on memory alone.

That is why I built REST AI: Reflect, Evaluate, Strategise, Track.

It is an AI-assisted, Markdown-based operating system for engineering leadership, built on simple files, clear rules, and continual iteration.

What It Does

REST helps me collect signals, interpret them, turn them into actions, and keep track of what needs attention.

It gives me a structured place to understand:

• What teams and individuals are working on
• Where work is allocated
• What is blocked
• What risks are emerging
• What decisions have already been made
• What still needs follow-up

The inputs come from tools like Jira, Trello, Slack, and other working notes. Some of that is automated. Some of it is deliberately manual, because not everything important arrives neatly packaged in a ticket.

The value is not in aggregating data for its own sake. I ask it to collate information so I can make better decisions with the fullest possible context in view.

I can add an update, ask the system to help me think through what it means, and use that to organise the noise into something useful.

The best comparison is not an AI dashboard. It is closer to a leadership assistant: something that helps me stay oriented without pretending to make the decisions for me.

A Worked Example

Here is a real example of the sort of thing this system is useful for.

Peter van Onselen - a staff engineer on one of my teams, and an old friend of mine - wrote about the technical side of a related OpenSearch incident here: I Am Sorry, Dave.

Peter’s post is worth reading on its own. He describes an inherited OpenSearch-backed cache/indexer, a production data issue, and the careful way he used AI as a read-only diagnostic assistant while staying the human operator. He did not hand production control to the model. He used it to reason faster, then made the judgement call himself.

REST gave me the leadership-side view of the same class of problem.

The useful signal was not a dramatic incident report. It was a set of small, easy-to-miss clues that pointed to ownership, access, and production risk around OpenSearch maintenance. In practice, that meant a Slack update could be interpreted as more than coordination chatter:

“Can someone confirm who is owning the OpenSearch maintenance and whether they have the AWS access to complete it before the window opens?”

On the surface, that looks like routine housekeeping. In reality, it might mean:

• A production-sensitive task has no clear owner
• The person who appears to own it may not be able to execute it
• The work may need escalation before it becomes a last-minute problem
• The team may be carrying an assumption that is not yet true

REST helped me turn that into a leadership judgement point. It pulled the signal into the working view, connected it to the relevant action and risk, and kept it live until there was evidence that the ownership question had been resolved.

That was the value: not that AI magically understood the situation, but that it helped me gather enough context to make clear decisions quickly - who needed to be involved, who might be affected, what the timing meant for delivery, and how much of the technical detail I needed in order to have sensible conversations with people like Peter without wasting everyone’s time.

How It Works

The underlying structure is deliberately simple:

• A Git repository
• Markdown files
• Prompts and lightweight workflow rules
• A generated dashboard
• AI assistants I can use as a thinking partner

That simplicity matters. I do not want a fragile platform I need to maintain. I want something durable, inspectable, and easy to evolve.

The most important design choice is that the AI is not the decision-maker. I use it to gather context, compare signals, spot contradictions, and surface what needs attention. Then I check that against source material, diffs, and the real state of the work.

Alongside live inputs from Jira, Trello, and Slack, the system includes reference material on:

• Delegation
• Escalation rules
• Strategic goals
• Operating principles
• Ownership
• People
• Platform dependencies
• Teams
• Terminology
• Work-allocation filters
• Working style

In other words, the AI is not just reading updates. It is reasoning against organisational memory.

What I Use It For

The outputs I care about are practical:

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

That is the real value of the system: not more information, but better judgement.

Reflect, Evaluate, Strategise, Track

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
• Strategise about what to do next
• Track the things that need continuity

That sequence matters. Most leadership systems are good at collecting information and poor at turning it into action.

Keeping It Healthy

I have learned that systems like this become noisy unless you actively maintain them.

If everything is tracked forever, nothing stays useful for long.

So I am iterating on the system deliberately. I am tightening the workflows, improving the prompts, and removing stale context as I go.

The idea of retiring information is important here. Not every note, decision, or risk should live in the active working set forever. Some things are useful for a time, then become noise. Retiring information means moving it out of the live view once it is no longer actionable, while still preserving enough history to understand what happened if I need to revisit it later.

That is different from deleting context. It is a judgement call about freshness. If a risk has been resolved, a dependency has moved, or a decision has been superseded, I want a clean way to stop it cluttering the working picture.

That means constantly improving:

• What gets tracked
• What gets ignored
• What gets retired
• What gets surfaced again

The goal is not a perfect knowledge base. The goal is a useful operating system.

Why This Matters

Any leader dealing with too much context, too many moving parts, and too many decisions could benefit from a system like this.

The broader lesson is that AI becomes much more valuable when you give it structure and context. A Git repository, some Markdown, a few prompts, and disciplined workflow design can go a long way.

You do not need a large platform to start. You need a system that helps you think clearly, a willingness to iterate, and a good sense of where AI should augment judgement rather than replace it.

File Structure

The structure is intentionally plain. The repository is organised around context, inputs, outputs, prompts, scripts, and templates.

The context files capture the operating model: delegation, escalation rules, strategic goals, operating principles, ownership, people, platform dependencies, teams, terminology, work-allocation filters, and working style. The inputs are drawn from Confluence, Jira, Slack, and Trello. The outputs are the working artefacts I actually use - action items, cross-team dependencies, daily briefs, a decision log, a risk register, stale items, and a view of what is happening in each team.

Around that sits the supporting machinery: prompts, scripts, and a small set of templates that keep the system consistent without making it brittle.

You can read more about the structure in Appendix A.

Closing Thoughts

REST is still evolving, and that is part of the point.

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

That is enough for me to keep using it, and enough to let me “rest” a little easier.

I would strongly encourage other leaders to experiment with a similar approach, because it has been genuinely useful for me.

Appendix A: Full File Structure

Naturally, I can’t show the contents of these files as those are private to the organisation, but this structure should give you a sense of how the system is organised and the kinds of information it captures.

├── 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