How work gets done: routing, evidence grades, approval gates

Chapter 1 described the workforce. This chapter follows a single request through it from end to end, because once you can picture that path, the rest of the manual is just detail hung on it.

The life of a request

Picture a real one. You type: "Our trial-to-paid conversion dropped from 18% to 12% since March. What happened?"

Before a word of analysis is written, the orchestrator does three quiet things in the background. It checks which of your tools are reachable right now, so it knows whether it can read real data or must work from what you say. It loads your business profile, so the team knows your stage and model without asking. And it classifies the request, which here reads as a product question with a revenue edge, so it goes to the product team with advisory support.

The product orchestrator then staffs the job rather than answering alone. A feedback synthesizer digs into what changed in how users behave, while an experiment designer checks whether anything that shipped in March could explain the drop. Each works its own angle and reports back in a structured summary. The orchestrator merges those summaries, resolves where they disagree, and writes the answer. You see none of that coordination, only its result.

That result reads like a briefing from a good analyst: the finding first, the evidence under it, and the one move worth making next. How much you should trust that finding is not left to your judgment, because the deliverable tells you outright.

Evidence grades, the honest layer

Every deliverable carries a grade that names what it was built from. HIGH means live, connected data, where the team read your actual analytics or billing records. MEDIUM means it worked from what you described, which is the normal footing before you connect tools. LOW means it had to assume more than it could verify, and it flags that rather than burying it.

Read the grade as a statement of footing, not of quality, because the two are different. A MEDIUM-grade strategy can be excellent thinking built on stated facts. The grade exists for one reason: so you never mistake a well-reasoned estimate for a measured number. That single confusion is what makes a confident dashboard dangerous, and the grade is the cure for it.

Knowing what a deliverable was built from is half of trusting Marg with real work. The other half is knowing it will not act behind your back.

Approval gates, the safety layer

Marg reads freely and acts carefully, and the line between the two is drawn by how hard an action is to undo. Anything that only reads (reports, analysis, research) runs without ceremony, because the worst case is a wasted minute. Anything that reaches outside your chat to change the world (a payment, a database migration, a code merge, a bulk CRM update) stops and asks you first, because the worst case there is real. The gates are tiered by reversibility, so a harmless draft never nags you and an irreversible action always pauses. Chapter 26 lists exactly what trips them.

The same restraint extends to people, not just systems. Some deliverables end at a human checkpoint by design, like the Growth Blueprint in chapter 19, which Marg prepares in full and a person signs off before it goes anywhere.

What this means in practice

Those two layers are what let you hand Marg real work and walk away. It tells you what it knew when it answered (the grade), and it asks before it changes anything you cannot easily reverse (the gates). With the model clear, the next chapter gets you installed and turns it from a diagram into your first deliverable.