The Bridge: An AI Executive Deck Where the Decisions Get Made

Every real company has a room. Call it the leadership meeting, the exec team, the board. Numbers arrive in it. People with different specialties read the same numbers and reach different conclusions. They argue. Someone decides. The decision becomes work.

That room is the most valuable thing a company owns, and it is the first thing a small company cannot afford. So the room collapses into one person's head, on a Tuesday, between calls, after a bad night of sleep. I ran that way for years. Analytics in one tab, revenue in another, the task list in a third, each of them telling me something true and none of them telling me what to do.

The Bridge is my attempt to build the room. Not a dashboard of what happened. The place where what happened gets argued about and turned into a decision.

Where the executives sit

The ship metaphor is not decoration here, it is the org chart. On a ship the bridge is not where the work happens. It is where the work is directed. Instruments and lookouts feed information in. Officers each read it through their own specialty. The Captain decides. The crew executes.

The metaphor earns its keep because it forces the question most AI tooling dodges: who decides? If the answer is "the model, quietly, at 6am," that is not a command deck. That is a liability with a nice font.

It is not a marketing tool

This is the part I have communicated badly, so let me be direct about it.

Marketing is what I wired in first. That was a sequencing decision, not a scoping one. Marketing has the richest daily signal and the shortest feedback loop in the business, so it is the cheapest place to find out whether a machine can actually form a useful judgment. It is the test bench.

The architecture underneath is domain-neutral, and it is neutral in a way you can check rather than take on faith:

• A signal is any measurable fact about the business. The stage is deliberately dumb. It pulls, normalizes, timestamps, and stores. It does not know or care whether a row is an ad spend, a churn number, a support backlog, or a cash position.
• A judgment is an interpretation with a spine. What moved, why it probably moved, what it implies, which strategic goal it touches, how confident the reasoning is. Nothing in that shape is specific to marketing.
• Half the council are not marketers. Munger is there to invert a risky bet and name the bias pushing it. Senge is there for the channel or the process that keeps backfiring after you fix it. Marcus Aurelius is there for the week where a number falls and the honest answer is that it was not yours to control. Rick Rubin is there for taste. Those are executive seats. You would not staff them to write an email.
• Every table carries a venture column. The schema was built so other parts of the business, and other businesses, can sit in the same room. Being straight about the current state: that column is designed for and not yet exercised. One tenant is live as of August 2026.

The loop: four stages, once a day

The whole system is one daily pass with four stages. Each stage is a table in the database, and each one feeds the next.

Signal is deliberately dumb, and that is a design decision worth defending. If you let interpretation happen at collection time, you can never re-interpret history when your strategy changes. So it stores raw and judges later. A separate read-only ingest arm handles the sources the Worker cannot reach on its own, and it masks every email address before anything is written down. It is not allowed to send, label, archive, or delete. If a tool call would change state, it does not get made.

Reasoning is where interpretation starts. The model reads the day's signals, one at a time and against each other, alongside the strategy file, and writes judgments. A judgment is not a task. It is an observation with a why attached, a linked strategic goal, and a confidence number that lets a weak read be treated as a weak read.

Recommendation is the meeting itself. It gets its own section below.

Act is the gate. Approve, reject, revise, or interrogate ("why did you suggest this?"). Approved items are written to an action ledger that tracks lifecycle: proposed, approved, scheduled, in progress, shipped, done. That ledger exists because "it was recommended" and "it is actually live" are different facts, and only one of them changes the business.

How the council actually works

This is the piece nobody sees from the outside, and the one people ask about when they watch the deck refresh.

The advisors live as folders in my Command vault, one per thinker, each holding an operator-grade brief of their work: thesis, big ideas, the frameworks with worked examples, decision rules, anti-patterns. Ten seats today, in two kinds. Doing seats move a number. Thinking seats decide whether moving it compounds or costs you later.

Look at the bottom half of that table and you can see the reframe in one glance. Nothing about inversion, leverage points, or Stoic temperament is a marketing technique. Those are the seats you fill when the question is should we do this at all.

The naive version is what I built first: one model call, one advisor assigned per finding. It produced confident nonsense, because forcing a lens onto a problem it has nothing to say about is how you get a growth guru opinion on a hiring decision.

The version running now is a three-step panel:

1. Route. For each judgment, pick the two to four advisors who genuinely have a lens on it, and rate how important the judgment is. No forced fits. The router is allowed to gate an item out entirely, which is the same thing as a good chair keeping something off the agenda.
2. Panel. For the highest-importance items, each routed advisor produces a recommendation voiced authentically in their own frame. Hormozi argues the offer is weak. Senge argues the channel is not the problem and you are treating a symptom. They disagree, on purpose, because a meeting where everyone agrees is not a meeting.
3. Judge. A final pass selects the strongest candidates across every item by decision value, defined as importance times fit times actionability. Explicitly not by eloquence.

That last clause is doing real work. Left alone, a model picks the best-written recommendation. The best-written one and the most useful one are not the same thing, and the distance between them is where a quarter goes missing.

The frameworks, and where each one bites

The advisors argue. The frameworks constrain. If you only build the first half you get a very articulate committee that never converges, which is the failure mode of most "AI advisor" demos.

Every framework file in the folder is written scorer-shaped, in the same six parts: what it computes, its inputs, the formula or rubric, what it outputs, how a playbook calls it, and a worked example. Same shape every time, so the loop parses any of them identically and I can add a new one without touching code.

Two of them are worth showing in full, because they are the ones that most often overrule an advisor.

The score is a statement of intent

Surviving candidates get scored. The formula, with its exponents:

score = (Reach^0.5 · Impact^2.0 · Confidence^1.5 · StrategicFit · Freshness · StageWeight) / Effort

The exponents are the opinion. Impact squared beats the square root of reach by roughly thirty times at equal raw inputs, which means an item that touches four people and might close a deal outranks one that touches forty thousand and might not. Stage weights say the same thing again: revenue 1.5, acquisition 1.3, activation 1.1, retention and referral damped to 0.7.

That is not universal truth. It is my current truth, and it is the most executive thing in the codebase. A weighting is a company saying out loud what it is optimizing for this year. MaxShip is early, so qualified booked calls beat impressions. Retention weighting goes up the moment there are enough customers that keeping them is the constraint. Every one of those numbers is a config row, so changing the company's mind is an edit, not a rewrite.

The infrastructure genuinely is close to free. Cloudflare Workers has a free tier of about 100,000 requests a day and a flat $5 a month paid plan, with the database and key-value storage in the same account. The meaningful cost is model calls, because the panel makes several Opus calls per run. The money goes to thinking rather than hosting, which is the right ratio for a room whose only job is to think.

One morning, end to end

1. The signal

Three connectors return. Each becomes one row. No interpretation, and deliberately so: interpretation at collection time means you can never re-read history after your strategy changes.

2. The reasoning

The model reads all three rows together, against the strategy file, and writes a judgment. This one is cross-signal, which is the only kind that justifies the cost of a frontier model:

{
  "id": "rsn_4d18aa",
  "title": "Traffic is compounding. The offer page is where it dies.",
  "judgment": "Impressions +18% and sessions +21% week over week, but booking
    completions held flat at 2 against 9 starts. Attention is no longer the
    binding constraint; the offer page is. Three weeks of the same pattern
    means this is structural, not noise.",
  "signal_type": "cross",
  "evidence_signal_ids": ["sig_8f2a1c", "sig_b71d04"],
  "linked_strategy_ref": "qualified booked calls, not impressions",
  "confidence": 0.72
}

Two fields do the heavy lifting and they are the ones people leave out. linked_strategy_ref forces the judgment to point at something I actually wrote down, so the next stage can test fit instead of vibes. confidence at 0.72 means the panel treats this as strong but not settled, which changes how aggressive a move it is allowed to recommend.

3. The routing

The router reads the judgment and picks who has a real lens on it, plus how important it is:

{ "reasoningId": "rsn_4d18aa",
  "importance": 0.9,
  "advisors": ["hormozi", "sy-stem", "seth-godin"] }

Just as interesting is who was left out, and why. Marcus Aurelius was not routed, because nothing here is a temperament problem: the number is real and it repeated. Naval was not routed, because there is no leverage question in play. Y Combinator was not routed, because this is not a pre product-market-fit question. A router that never says no is a router that flatters you.

4. The panel

Each routed advisor answers in their own frame, and returns their own score inputs. Same judgment, three genuinely different reads:

The takes come back voiced, because the point is that I learn the reasoning and not only the instruction:

Hormozi: Nine starts and two completions is not a traffic problem, it is an offer problem, and no amount of new eyeballs fixes an offer. Put the risk on your side of the table. One named guarantee, stated in the hero, priced into the model.

Sy Stem: Watch the delay. Buying more attention pays back in days and fixing the offer pays back in weeks, so the fast fix will keep winning the argument and the real one keeps getting deferred. That is Shifting the Burden, and the dependency it creates is on paid traffic.

Godin: Say the quiet part in public. A founder writing honestly about their own broken conversion is more remarkable than another feature post.

5. The judge, which runs before the maths

This is the sequencing detail most people get backwards when they build one of these, and it matters. On the panel path the judge selects first, and only the survivors get scored. The score then orders the feed. There is a second, cheaper path in the codebase where the model emits score inputs and pure ranking decides, but the daily pass uses the panel.

{ "winners": [
  { "index": 0, "whySurvived": "names the actual constraint and is executable
      this week; guarantee is the highest-impact single change" },
  { "index": 1, "whySurvived": "kept as a constraint on the others, not as a
      task. Prevents the traffic reflex from being funded this week" }
]}

Godin's post lost. It was the most publishable idea in the room and the least consequential this week, which is exactly the trade the judge is instructed to make: reward the best decision, not the most eloquent take. Note what happened to the second winner too. It survived as a constraint rather than as a task, which is the most useful thing a thinking seat produces and something a pure task queue has no way to represent.

6. The score, computed on the survivors

Now the arithmetic, using the formula above. I have included the losing candidate so you can see what the numbers would have said:

Look at what the exponents did. The post reaches three times as many people as the offer-page rewrite and scores seven times lower, because reach is square-rooted and impact is squared. That is not the model being clever. That is me having written down, months ago, that this year I care about closing more than I care about being seen, and the formula holding me to it on a morning when the shiny idea was the post.

Here the judge and the maths agreed. When they disagree, the judge wins, because it ran first and it can weigh things the formula has no column for.

7. How it reaches me

One card in the deck. Everything on it is a stored field, not a re-summarization:

The lineage line is the one I would fight to keep. fed_by means I can see in one glance that this came from a cross-signal judgment, was shaped by two frameworks, and was argued by one named advisor. A recommendation I cannot trace is a recommendation I have to re-derive myself, and at that point the machine has cost me time rather than saved it.

8. The decision, and what it writes

Four moves, and each one leaves a record:

• Approve posts to /api/v1/recommendations/:id/approve, which writes a row into the action ledger with a status, a timestamp, an optional schedule, and my notes. The recommendation stops being an opinion and becomes a tracked thing with a lifecycle: proposed, approved, scheduled, in progress, shipped, done.
• Reject takes the same route with the opposite verdict, and the row is kept. A rejection is not waste, it is the clearest record of taste the system will ever get, and deleting it throws away the only honest signal about what I actually will not do.
• Revise re-runs the heavy drafting pass with my notes attached, against the same recommendation rather than a new one, so the thread of why stays intact.
• Interrogate makes the model explain itself against the strategy and the evidence signal ids. This is the one that earns its keep on bad days, because it is how I catch a confident judgment resting on a connector that quietly went stale three days ago.

On this morning the decision was: approve the offer-page rebuild, and let the systems seat's warning stand as the reason not to raise ad spend the same week. Two different kinds of output from one judgment, one a task and one a restraint.

That is the part I did not expect when I started building it. The value is not the draft. Drafts are cheap now and getting cheaper. The value is that the disagreement is on the record. In three weeks the number will move or it will not, and I will be able to go back and see which seat read it correctly, which is the closest thing a company my size has to institutional memory.

Where the standing orders live

None of the judgment is hard-coded. The brain is a folder of markdown I edit by hand.

bridge/
  strategy.md        north star, who we serve, the offer, the constraint
  playbooks/       one recipe per kind of output
    cold-email.md
    landing-page.md
    seo-page.md
    log-article.md  the recipe that produced this page
  frameworks/      RICE, AARRR, value equation, LTGP:CAC
  advisors/        the council. one folder per thinker

Edit a file, sync it, and the room behaves differently tomorrow. No deploy, no prompt archaeology, no vendor. That is the point of keeping strategy as a file instead of burying it in code: the part of the system carrying the most judgment should be the part I can read on a Sunday and correct with a text editor.

The rule for what belongs in there is one question. Does the loop read this on every run to decide what to do? If yes, it is hot config. If it is reference a human looks up occasionally, it lives somewhere colder. That single test has kept the folder from becoming a junk drawer.

What it looks like on a Tuesday

Undramatic, which is the point. The schedule fires. By the time I sit down there is a deck: a stats strip, the judgment feed, a small stack of recommendations with each advisor's take attached, the tasks it thinks come next, and a connector health strip so I can see at a glance whether a source went dark overnight.

Each recommendation carries its lineage. What fed it (which judgment, which framework, which advisor), what it expects to produce in the short and long run, and which piece of the strategy it serves. I can expand the reasoning and argue with it. Then I approve, revise, or kill it. That is the meeting, and it takes about the time a coffee takes.

Dating this, because it will age: the read, reason, recommend, and draft stages run on their own, and the review, approve, and reject controls plus the action ledger are live. The outbound executors are still deliberately manual. The conversational officer layer, where I give orders by message instead of clicking, is specified and not yet running. Marketing is the only tenant so far.

If you want to build the room

You do not need my stack. You need four things in this order, and most people attempt them in reverse.

1. A written strategy. One file. Who you serve, what you sell, where the constraint is right now, what winning looks like this quarter. If you cannot write it, no model can reason against it, and neither can a new hire.
2. One place the facts land. Even a daily script that dumps five numbers into a table beats eleven tabs. Raw first, interpretation later.
3. A scoring rule with an opinion in it. Not a framework off the shelf. A framework bent toward the one outcome that pays you this year.
4. A gate. Decide now, while it is cheap and theoretical, what the machine is never allowed to do without you.

I want to build a daily AI decision loop for my business. It will read my numbers, form judgments against my strategy, have a panel of advisors argue over what to do, and stack drafts behind my approval. Before any code, help me write the strategy file it will reason against.

Interview me until you have: who I serve (specific enough to exclude people), what I sell and at what price, where the constraint in my business actually is right now (demand, delivery, cash, or attention), the two or three moves I am genuinely committed to this quarter, and the one outcome that matters more than the others.

Then write it as a single markdown file, dense and specific, no filler. Where my answers were vague, say so directly instead of smoothing it over.

Finally, tell me which parts of what I said would cause an AI to make bad recommendations, and why.


End by asking me one question: "Which parts of this feel most uncertain — want me to explain them, or should I just build it for you?"

Start with the strategy file and the gate. The plumbing is the easy half and the models keep making it easier. What no machine can do for you is decide what you are actually trying to win.

Stop telling yourself this is out of reach because you are not an engineer. I am not one either. This is a scheduled job, a database with six tables, a folder of markdown, and a rule that nothing leaves the building without a human saying yes. The hard part is the thinking, and you already do that. You have just been doing it in eleven tabs.

If you build one and get stuck, reach out. I am always happy to help.