# Places of highest leverage: where to focus when the agents can go in every direction, told with three days of real steps, sgit.ai > When a team of agents can build almost anything, the scarce thing is direction, and this article is about how I choose it. The rule I have used since I was a CISO is to work at the place of highest leverage: where I can add the most value right now, am not blocked, and can just start, even without knowing how the whole problem will be solved, because by the time I get there I will have better tooling and a better view. The last three days are the worked example. The newsroom went from a reading meter to pay by depth, personas, an encrypted share, a persona in a link, a reading list in a link, a passkey design, a lab that corrected the design, real vaults from the browser and a vault pane, each step shipped and used before the next was chosen, two steps walked back, and a branch parked because it is only valuable with many readers. On a Wardley map the passkey work moved from genesis to a product in a day because almost every shoulder it stands on is a commodity someone else matured; the one custom layer we had to add is where a provider is not. The path looks obvious backwards and was five choices at every step going forwards; walking back is not failure, and parking is not either. Constraints, saying no, shipping to a user even when the user is me, and the brief that could not be written until the art of the possible was known. *Source: · sgit.ai v0.7.82 · this file is generated from the same content as the page, so the two cannot drift. Every page on this site has a `.md` twin; internal links below point at them.* --- [Home](../index.md) / [Articles](index.md) / Places of highest leverage: where to focus when the agents can go in every direction, told with three days of real steps # Places of highest leverage: where to focus when the agents can go in every direction, told with three days of real steps By [Dinis Cruz](https://sgit.ai/about/index.md) · 2026-10-12 · [article v1.2.0, 3 versions](versions/places-of-highest-leverage.md) · [sgit.ai v0.7.75](https://sgit.ai/admin/versions.md) · startupsfocusleveragewardley-mapsexplorer-villagershippingconstraintsagentsnewsroomfeedback-loopstrategyarticle ***Abstract:** When a team of agents can build almost anything, the scarce thing is direction, and this article is about how I choose it. The rule I have used since I was a CISO is to work at the place of highest leverage: where I can add the most value right now, am not blocked, and can just start, even without knowing how the whole problem will be solved, because by the time I get there I will have better tooling and a better view. The last three days are the worked example. The newsroom went from a reading meter to pay by depth, personas, an encrypted share, a persona in a link, a reading list in a link, a passkey design, a lab that corrected the design, real vaults from the browser and a vault pane, each step shipped and used before the next was chosen, two steps walked back, and a branch parked because it is only valuable with many readers. On a Wardley map the passkey work moved from genesis to a product in a day because almost every shoulder it stands on is a commodity someone else matured; the one custom layer we had to add is where a provider is not. The path looks obvious backwards and was five choices at every step going forwards; walking back is not failure, and parking is not either. Constraints, saying no, shipping to a user even when the user is me, and the brief that could not be written until the art of the possible was known.* Five choices at every step; the path only looks obvious backwards. The steps the newsroom actually took from 10 to 12 October, with the choices passed over at each, two walked back, one branch parked, and every step shipped and used before the next was chosen. This morning I asked the agent that runs the newsroom to read the day's articles and tell me what it could build next. It came back with a long list, all of it possible: the inbox mode, the reading modes, the marks, automating the wire's daily run, more beats, scheduling, consumption analytics. Every item was a reasonable thing to do, and a team of agents could have started on all of them by lunchtime. That is the problem this article is about. When the agents can go in every direction, where do you focus? My answer is the one I have used since I was a CISO, and it has a name I gave it years ago: places of highest leverage. This article says what that means, shows it on the last three days of real work, puts it on a Wardley map, and ends with the part that only became clear this week, which is that the briefs I write depend on knowing what is possible, and knowing what is possible depends on having shipped. ## In short - **Direction is the scarce thing.** Agents can build in any direction; what they cannot generate is the sense of what to build next and when to stop. Providing that is the job. - **Work at the place of highest leverage.** Where you can add the most value right now, you are not blocked, and you can start. Not where the biggest problem is; where the next step moves the needle most. - **Start without knowing how it ends.** By the time you reach the hard part you have better tooling, better data and a better view. Starting somewhere, even somewhere slightly wrong, beats being paralysed by the size of the whole. - **Shipped and used, every step.** Nothing stays theoretical. Each step goes in front of a user before the next is chosen, and the user can be me. - **The path is five choices at every step.** It looks linear and obvious backwards; forwards it was a tangent, two steps walked back, and a branch parked. The non-linear path was the efficient one. - **Walking back is not failure, and parking is not either.** A tangent reaches diminishing returns or no demand; you note it and move. The parked branch is on the map, with the reason. - **Shoulders matter.** On the Wardley map the passkey work went from genesis to a product in a day because almost everything under it is a commodity someone else matured. The custom layer we had to add is the one place a provider is not. - **The brief depends on the possible.** The inbox brief could not have been written until the vault ran. Shipping is what tells you what to think next. ## The rule Places of highest leverage means this. At any moment there are many things that could be done. Most of them are blocked on something: a decision, a dependency, a thing that does not exist yet, a person. Some are not blocked but would not change much. A few are not blocked and would change a lot, for the people who use the thing and for everything built after. Work on those, and only those, until they stop being that. It is a rule about where, not what. It does not say what the product is; it says where to stand today. And it does not require knowing how the whole problem will be solved. I often do not. What I know is that by the time I get there, I will have better tooling, a better understanding and a better view, because every step taken produces those three things. So instead of standing in front of a large problem being paralysed by it, you start somewhere, and the somewhere can be slightly wrong, because the first step's job is not to be right. It is to produce the second step's information. There is a mathematical version of this that I use in security and cannot name from memory in a voice memo, so I will name it here carefully. It is the family of methods that begin with a guess, measure, and narrow: Fermi estimates that start wide and get calibrated; Bayesian updating, where each observation moves the prior; Monte Carlo runs that turn a guess into a range. What they have in common is that the first number is not the point. The range that emerges after a few steps is highly informative, and you cannot get to it without the first bad guess. Engineering under uncertainty works the same way, and so does choosing what to build. The other half of the rule is constraints. I have token budgets, hours, attention, and one person's focus, and I think the constraints are the reason it works rather than the price of it. The FIRE model from Dan Ward says it in four words, fast, inexpensive, restrained, elegant, and [Knowing when to stop](knowing-when-to-stop.md) is this site's version: value rises fast and then flattens, and past the point of diminishing returns more work is optimising the wrong thing. Constraints are what make you notice the flattening. And saying no is the sharp end of it. Steve Jobs said something like: focus is about saying no to the hundred good ideas, and I am proud of the things we have not done. With agents that is not a slogan. It is most of the work. ## Three days, step by step The figure at the top is the record, from the release logs of this site and the newsroom, and I want to walk it because the rule is easier to see in a sequence than in the abstract. On 10 October, [Pay after you read](pay-after-you-read.md): a meter in the browser at 12:09, pay by how far you read at 13:40, personas and your own newsroom at 14:23, sending your reading encrypted at 15:28, usefulness setting the price at 15:49. Each one was the place of highest leverage once the one before it existed. A meter made a price possible; a price made personas worth keeping; personas made sharing worth encrypting. None of them was planned a week ahead. Each was chosen after using the last. On 11 October, [a link to a persona](a-link-to-a-persona.md) at 09:53 and [a reading list in a link](a-reading-list-in-a-link.md) at 14:30, 81 minutes after its brief, because sending someone to the newsroom as nobody was the friction I felt that morning. Then the passkey design, and here the path bends. The first version had a door vault between the passkey and the master. A review in the afternoon took it out as a layer too many: there was no requirement for it in our use case, and I agreed. That is the first orange arc on the figure. On 12 October at 00:15, the newsroom's lab, which had built every step of the design as a card, found that [the same passkey returns different bytes](the-passkey-opens-the-vault.md) through a phone over QR than through the provider on the device. The door went back, as a door per path. That is the second arc, and it points the other way. Two reversals in twelve hours, both right, both cheap, because the design had been shipped as something you could press rather than argued as a document. At 01:33 real vaults from the browser, through the vendored library rather than a writer of our own, which was a choice passed over. At 02:22 [the vault pane](the-vault-is-live.md), live. And then, this morning, the list. The agent offered the inbox, the reading modes, the marks, and also automating the wire, more beats, scheduling, consumption analytics. The second group is parked, and the figure says why in blue: valuable only with many readers. We do not have many readers; we have articles, and me, and the person I showed the walkthrough to. The place of highest leverage is the feedback loop on what exists: the inbox, the marks, the modes, because they make every article better, they are what the readers we do have want, and they make me a better briefer of the agents, which compounds. Improving how the wire is computed is real work for a real day, and that day is not today. ## Walking back, and parking Two things in that sequence are easy to read as failures and are not. Walking back is what a two-way door looks like from inside. The distinction, from Jeff Bezos, is between decisions you can reverse and decisions you cannot, and the point is to move fast through the first kind. Removing the door was a two-way door; so was putting it back. Neither cost more than an afternoon, both were shipped as a version with the change on its page, and the second was forced by a test, which is the best possible reason. The path with two reversals in it reached a better design faster than a path that had tried to get the design right on paper would have, because the paper could not have known what the phone would return. Parking is the same move at the level of a branch. A tangent reaches diminishing returns, or it turns out there is no demand yet, and you stop. Not because it was wrong; because its leverage is lower than something else's today. The parked branch stays on the map, with the reason, and the reason has a date on it: when there are many readers, the wire's scheduling becomes a place of high leverage. That is also why I do not feel ownership of any of these pieces. They are open, the record is public, and the thing I am attached to is the feedback loop, not any one feature in it. The same thing as a shape rather than a record: three to five routes open at every step, one taken and shipped, two walked a little way and walked back, one parked, and the straight line that only exists in hindsight. The hardest part is that going forwards you cannot see the path. Backwards, from the vault pane, the sequence looks inevitable: of course the meter led to personas led to sharing led to a vault led to a passkey. Forwards, at each step, there were five choices, and the figure shows the ones passed over in grey: a paywall, a subscription, an account, a recommender, analytics, a server, Google sign-in. Any of them could have been taken. The method in the madness is only visible by walking backwards, and that is fine, as long as each step forwards was shipped and used before the next was chosen. That is the discipline that replaces foresight. ## Which shoulders, on the map Which shoulders the passkey work stands on. Almost everything under it is a product or a commodity someone else matured; our piece is the door and a door per path; the one custom layer we had to add is the phone by QR, where a provider is not yet mature. There is a second reason the three days went as fast as they did, and the Wardley map shows it. The passkey work went from genesis, a design on a page, through custom-built, a lab you could press, to a product, a pane on every page, in a day. Within hours of that we were building on it: vaults inside vaults, the reading records, the next brief. It is already on its way to being a commodity for us, something that just works and is not thought about. That is only possible because of what it stands on. Look at the bottom of the map. Synced passkeys with the PRF extension in iCloud Keychain: commodity, mature, the same bytes on a Mac, an iPad and an iPhone. The WebAuthn PRF extension itself, Web Crypto with HKDF and PBKDF2, sgit keys made in the client, the vault library we vendored unedited, the vault server, the Stripe payment link: all products or commodities, all someone else's work, all matured before we arrived. Our piece, the door and the derivation, is small, and that is the point. We are not building a passkey system. We are adding one small custom layer on top of a stack that is already mature, and a small custom layer on a mature stack becomes a product almost as soon as it works. The one exception proves it. Google Password Manager's passkey, reached through a phone over QR, returns different bytes from the same passkey on the device. That is a place where a provider is not yet mature, and it is exactly where we had to add a custom layer, a door per path, and exactly where the work slowed. If we had built on that path alone we would still be building. We built on Apple's synced path, which is further to the right, and the thing shipped. Which shoulders you stand on decides how fast your piece becomes a product. The map tells you where the mature shoulders are, and it is worth drawing before choosing where to stand. ## Shipped, and used Everything above rests on one rule that I want to state on its own: it is about shipping, and it is about a user. Every piece of work, these days, has to be used straight away, by someone, and it is fine if the someone is me. Not a hypothesis, not a design document that waits for a quarter: a thing a person opens. [I miss it, so it is working](i-miss-it.md) made the case that the people who decide the roadmap have to use the product; this is the operational version. A step that was shipped and used tells you where the next step is. A step that was only designed tells you nothing, because you have not felt it. That is also why the briefs come after the shipping and not before. [The site is an inbox](the-site-is-an-inbox.md) begins with a confession: I could not have written it two days earlier, because I did not know the properties of what would run. The vault had to exist, the passkey had to work, the door had to be per path, before I could think about what a reader does with any of it. The art of the possible is not something you reason your way to. It is what shipping leaves behind, and the next brief is made of it. ## What this does not claim - **Three days is a sample.** The sequence is real and the times are from the release logs, but it is one project at one speed, chosen because it is the one I can show. - **The rule does not pick the product.** Places of highest leverage says where to stand, not what to build; the what comes from using the thing and from the people who ask for it. - **The mathematics is named carefully.** Fermi estimates, Bayesian updating and Monte Carlo ranges are the family I mean; the memo could not name them, and the analogy is mine, not a theorem. - **Parking has a cost.** A branch left for later can be overtaken; the wire's scheduling may need to be rebuilt when its day comes. That is accepted, and it is cheaper than building it for readers who are not there. If you run a team of agents and the hard part has become choosing, or you want to compare maps, write to [agent@riskmandate.ai](mailto:agent@riskmandate.ai). ## Where this comes from A voice memo of mine on 12 October 2026, the last of the day, written by this site's agent in the voice of this site. The argument and the editorial responsibility are mine. The steps and their times are from the release logs of sgit.ai and newsroom.sgit.ai, 10 to 12 October 2026, and from the articles that record them: [Pay after you read](pay-after-you-read.md), [A link to a persona](a-link-to-a-persona.md), [A reading list in a link](a-reading-list-in-a-link.md), [The passkey opens the vault](the-passkey-opens-the-vault.md) and [The vault is live](the-vault-is-live.md). The list of what the newsroom's agent could build next is from this morning's session with it. The two-way door is Jeff Bezos's, from his 2015 shareholder letter; the saying-no line is attributed to Steve Jobs and quoted from memory; the FIRE model is Dan Ward's. Both figures were drawn for this article. Related: [Knowing when to stop](knowing-when-to-stop.md), [I miss it, so it is working](i-miss-it.md), [The site is an inbox](the-site-is-an-inbox.md), [Explorer to villager](explorer-to-villager-newsroom.md) and [How much of this did I write?](how-much-of-this-did-i-write.md). ## Threads Startups & strategyAgents & policySite & engineering[This article as a graph →](graphs.md#places-of-highest-leverage) ### Builds on - [Knowing when to stop: what experience gives people, and what we have to design into agents](knowing-when-to-stop.md) Knowing when to stop is the hard part for people and agents: what experience gives people, and the constraints that give agents the same perspective. - [Pay after you read: how a reading meter became a working business model in one afternoon, one release at a time](pay-after-you-read.md) Seven releases in one afternoon turned the reading meter into a working model: pay after you read, and the rating sets the price. - [A link to a persona: send people to the newsroom as someone, not as nobody](a-link-to-a-persona.md) Send a CISO to the newsroom as a CISO: personas kept in a vault by the newsroom's agents, opened from a link, followed or forked. - [From me to you, in a link: a personal reading list, two briefs to build and use it, and the loop that makes it a day's work](a-reading-list-in-a-link.md) A reading list from one person to another, in a link the server never sees; a brief to build it, a brief to use it, and the loop that ships it in a day. - [The passkey opens the vault: a door per path, a master vault for every user, and no server of ours](the-passkey-opens-the-vault.md) Tested: a passkey's PRF bytes compute a door that holds the master's key, and a different path to the same passkey gives different bytes, so a door per path. - [The vault is live: from a design on 11 October to a reader's vault on newsroom.sgit.ai by two in the morning, and how all of it fits together](the-vault-is-live.md) The reader's vault runs on newsroom.sgit.ai: a passkey opens three real vaults, each device writes one file, and the architecture is drawn as it stands. - [I miss it, so it is working: the people who decide the roadmap have to use the product, and the vault the newsroom now needs](i-miss-it.md) I read the newsroom on four devices and they do not agree. Missing a feature is the best sign; the makers must use it. And the brief for the reader's vault. - [The site is an inbox: deciding before reading, marks that build the reader's own graph, and why I could not write this brief until the vault existed](the-site-is-an-inbox.md) The site as an inbox that starts empty: decide fast before reading, mark slowly while reading, build a graph you own, and sign what you send to the newsroom. - [Go slow to go fast: moving the newsroom from an explorer project to a villager one, with the brief to do it](explorer-to-villager-newsroom.md) The newsroom is live and charging. Move the reader code to its own repo, same bytes and same bugs, then map, test, review and refactor before new features. - [How much of this did I write? The numbers behind twenty articles in four weeks, and what the input actually was](how-much-of-this-did-i-write.md) Twenty articles in four weeks, measured from the session record: 63,000 words in, 85,000 out, no one-line prompts, and the real input is twenty years of writing. ### Continued by - [Not a straight line: working for RiskMandate by working on the newsroom, and why the thinking is never wasted](not-a-straight-line.md) Working on the newsroom solved RiskMandate's oldest problem in two days: progress is not a straight line, and the thinking is never wasted. - [Judo for small countries: where Portugal, Romania and Estonia can add the most value in AI, and why the race for GPUs is not it](judo-for-small-countries.md) A small country should not race for GPUs: the opportunity is the plumbing its talent stands on, built once as open infrastructure, with small models. - [Why I love Wardley maps: the best of ours, how I read one, and a map inside a map inside a map](why-i-love-wardley-maps.md) The best of our Wardley maps with their context, why the technique matters, one map read as a story, and a map inside a map inside a map. [All articles](index.md) · [All graphs](graphs.md) Article No. 89 · [start a reading list with it](https://newsroom.sgit.ai/for/make.html#r=89) **Posting this article on LinkedIn?** The cover is [places-of-highest-leverage.jpg](banners/places-of-highest-leverage.jpg) (1920×1080, title and key ideas on it). Upload it as the article cover, paste the title, then select and copy the body from this page. **Want the next issue by email.** One issue a week or so: what was published, what it adds up to, and what is worth your time. [Subscribe to the SGit Newsroom →](../subscribe/index.md) [← All articles](index.md) --- *[Site index for agents](../llms.txt) · [HTML version](https://newsroom.sgit.ai/articles/places-of-highest-leverage.html)*