Full Width 
Shortcuts 
Sign Up 
Log In 
Articles 
Reading List More from Derek Sivers podcast
You load the program into the computer, and it begins its calculations. It’s computing. It’s working hard, and it’s going to take some time. People who tell me they are lost and running in circles have one thing in common: They say they keep listening to podcasts, reading books, watching videos, doing courses — taking in more and more information — and still don’t know what to do. Consider the computer metaphor for yourself. You’ve taken in so much information, and heard so many instructions. That’s enough input. It’s time for output. Run the program. Stop interrupting yourself with new information. Let yourself execute one plan of action, and see it through to fruition.
There was a crime out on Park Avenue today, so the police are gathering information. The police said, “This is great information. How sure are you of this?” That’s your brain, in the dark, inside your skull. It can’t see or hear, or experience anything directly. It interprets little signals sent through nerves, which is not much information to work with, so it’s often mistaken. But it tells you it’s completely sure. 100% positive. In each of these movies, the hero gets through it for the better. When he finds out his mind has been tricking him, it’s upsetting, but he adapts. His mind was at odds with reality but can now see the difference. It’s even a relief, because it explains some frustrating moments of confusion in his past. Since old beliefs were disproven, the hero takes in reality with clear eyes. He carefully proceeds with less confidence and more humility. So can you.
This book is about reframing — changing how you think about something — and choosing a perspective that’s useful to you right now, whether or not it’s universally true. This narrow definition is important because whatever you consider true is closed. No questioning. But when you say “not necessarily true”, it opens it up for reconsideration. Let’s look at “Useful Not True” in five steps: Your thoughts aren’t true. Reframe: Find better perspectives.
In my previous post, “a daily run” — (please read it first) — running was a metaphor for whatever actions you take in your life. The story is about how we choose beliefs because they’re useful, not true. Beliefs make emotions. Emotions make actions. Actions come from emotions. Emotions come from beliefs. So choose whatever belief makes you take the action you want. One belief makes you act selfish. Another belief makes you act generous. One thought makes you do something stupid. Another thought makes you do something smart. What matters is the action they create. So choose the thought that works for you. the story, picturing a pot of gold, or a tiger, or hot coals, made real improvements in the runner’s actions. Adopt beliefs for your current needs only. What works for others might not work for you. What you needed yesterday might not be what you need today. Life is nuanced. Choose your goals and beliefs only for how they help you now. I’m bad at this and have a lot to learn. This week it’s time to perform, so to summon the courage, I choose to believe I’m great at this. Neither belief is true, but I adopted them because they helped me take the right actions. In the story, picturing a pot of gold didn’t work well in the past, but later worked great during a different situation. Adopt beliefs just for fun, to try different ways of being. Don’t over-focus on the usual goal. Take your eyes off the prize and look around. Creative experiments, curiosity, and adventures are fun. Fun is always a legitimate and underrated goal. Different beliefs serve different goals. Gurus and pundits prescribe their beliefs. But their prescription might only apply if you have a very specific situation and destination. Advice should come with this disclaimer. Don’t care whether something is true — only whether it works for you. When you declare a belief to be true, it closes minds, cements identities, and leads to tribal fights with anyone who doesn’t find that belief to be true for them. photo © Josephine Stenudd
Here’s a story about my shortest date, and ketchup. I suggested we meet at a bar at 35th Street and 8th Avenue. Although she’s from New York, she didn’t know where that is. She said, “No.” OK, now I’m judging. Miserable voice. Doesn’t know the basic layout of the city she lives in. Two red flags. She said, in her weary voice, “I’m not going to tell you my last name. You could be a serial killer.” So a couple days later we met at the bar at 35th Street and 8th Avenue. She looked good. We said hello. I asked if she’d like a beer. She said yes. I brought two beers back to the table. So the first thing I say is, “Where do you think the word ketchup is from?” I looked at her and thought for a second. Miserable voice. Doesn’t know her city. Assumes I’m a murderer. And now doesn’t have the slightest bit of curiosity about anything — no willingness to engage in the tiniest bit of wonder. She said, “But you haven’t even had a sip of your beer!” Years later, I’m living in Singapore, which is next to Indonesia, so I’m reading a book about Indonesian history. It says there is only one word in English that comes from the Indonesian language. Ketchup. My instinct was right to walk out on that date. Little interesting things are all around us. But the uncurious will never know. ketchup photo by Betsssssy
More in startups
I didn’t realize being a venture investor would also mean becoming a full-time event planner.
QR codes are here. Barcodes should be very afraid.
An interview with Jason Del Rey about Amazon versus Meta, which is a continuation of the oldest battle in retail between Amazon and Walmart.
AI risk; Reindustrialization; The rent crisis; AI and jobs; Mass deportation; Chinese investment; Cyber risk
One of the many problems computers have blessed us with is an abundance of information. Software has long been great at storing, retrieving, and sharing a company’s knowledge. This is most SaaS apps, from Slack to GitHub to Notion. But as easy as it is to store information, it’s hard to measure its accuracy. Or gauge its importance. Or promptly act on it. Or extract useful observations from an ocean of disorganized crap. Thus, most information goes unused. Heck, most information goes unrecorded. So it’s been for many years. Agents on the brain A big upshot of the past year’s tooling improvements is that more information is worth recording and acting on. AI-native teams are shifting away from Notion and Google Docs, toward more agent-friendly formats like Markdown for their business’ docs. They’re storing more info in team-accessible locations, and using it to move faster with agents. A key contributor to the growing hype around this shift is Y Combinator. With the release of gbrain, a number of talks on the topic, and Tom Blomfield’s entry in this summer’s Request for Startups, they’ve turned “company brain” from viral idea to overused buzzword before most people have even heard the term. While different treatises on the subject will center different goals, the core idea is that companies should make as much information as is practical usable by their team’s agents, because this contributes to positive flywheel effects. When a company’s decisions, processes, and proprietary info are legible to agents, they can of course help automate things. But they can also route information – leaders and ICs should be able to get the facts they need without going through lossy and slow layers of middle management. And agents fed with enough knowledge to form a “closed loop”, where observation, decision, and outcome are captured, can help run self-improvement – helping you hill-climb measurable aspects of a business. Now this is all very good in theory, but currently tricky to implement without descending into some mix of dystopia and AI psychosis. As much as spelunking the Claudese docs of GBrain is interesting, it’s a bit early for you to adopt 1M lines of company-brain machinery that evolved to run a startup accelerator (unless, perhaps, you run a competing startup accelerator.) However, as I’ve worked to build our team’s own post-Notion data bus and repository of truth, I’ve found a few emerging-consensus principles and techniques worth considering, for those of you working to get more use out of agents for non-coding work. 1. Text files, synced with history Agents are really good at working with folders of text documents, so that’s the default approach. Then, you need a way to sync these documents with your team, track changes, and resolve conflicts, so – big surprise – the nerdy early adopters of this pattern are mostly using git repos. On one hand, this is kind of silly. Git is a weird sync layer for a system where you’re mostly editing one file at a time, and always want to pull before any view or edit operation, and immediately commit and push your changes. And it doesn’t provide for realtime multiplayer editing, which you want during meetings and the like. But also, git is simple. And well-understood. And it works. GBrain has some intense scripts that coordinate its sync engine on top of git, but you can get started by just instructing your AGENTS.md to pull frequently, and to push every change it notices on disk immediately to GitHub – with human edits and agent edits pushed up as separate commits. 1 One problem working with folders of Markdown documents – synced or not – is that there isn’t AFAIK a great app for browsing these. What you’d want is something where each window shows a folder, with the file structure on the left side and rendered-but-editable Markdown on the right. Given the git backend, you’d also want some hooks to fire pull and push events on open and save, as well as some way to do all this on your phone too. The closest Mac app for this I’ve found so far is Typora. I’ve promised my co-founder Jenn not to get distracted by writing a better tool, so let me know if you’ve found something more suitable. 2. Separate maintained truth from source data A classic failure of documentation is that it can become unclear what is actively maintained and trustable, vs. what was a one-off capture of a discussion, idea, fact, or plan at some point in time. A lack of clarity here is even more disruptive to agents than it is to humans, since the docs are their memory. It seems most company brain systems formalize this distinction. For our team’s brain repo we distinguish between “point-in-time” docs that were true (e.g. meetings, plans, decisions), and a much smaller set of “evergreen” docs that we continuously review and maintain (e.g. core strategy, policies, who are we building for). GBrain calls its analogous concepts “Timeline” and “Compiled Truth” docs respectively. 3. Rigorously track provenance Keeping a partially agent-maintained knowledge-and-action system from descending into mush requires discipline about where purported facts were sourced from. If a document was hand-authored by your Founding Engineer yesterday, and today your CTO edited and approved it, that’s probably a reliable document. If Steve had Sonnet 4.5 barf a novel of “load-bearing” analysis that was “quietly” incorrect last fall, that’s probably worse than nothing. A coherent company memory needs some kind of metadata – e.g. headers in your markdown files – that track document history and state. When was this drafted? Last reviewed? Overhauled? Sanity-checked? Who did so? Is this mostly AI speculation, or is it a specific human’s own thoughts and words? One useful instruction is to have agents (and humans) ensure they link underlying sources for every claim, and prefer attributed quotes of specific humans over paraphrases. Each transformation of text is usually lossy, so minimizing this (and making claims more auditable) makes the system more stable and clear. 4. Be queryable The more your agents can fetch, consider, and route your company’s ground truth, the less time your team will need to spend relaying info for one another – and the more you can spend building and solving problems. This can start with automatically putting your routine internal meetings and Slack decisions into point-in-time Markdown docs in your company brain, but you can go way beyond that. Ad campaigns should create an artifact about what was tried and what was measured. Customer feature requests should be documented in a standard queryable format. Signed contracts, lost deals, feature launches, policy decisions, recruiting leads – any interesting event in your org can be recorded and made usable, informing future improvements. Heck, some teams even make their agents’ prompts and traces visible to one another, in real time. Of course, all of this is easier if you have a transparent company culture. Orgs that can work mostly in the open, avoiding DMs and secret docs except for rare HR or legal issues, are getting leverage out of these tools faster than companies that live in a world of need-to-know. But as the tools evolve, it will get easier to leverage strictly permissioned data too. 5. Automatically improve While it’s early days, some agentic workflows can now recursively self-improve with supervision. The more mature software factories detect, draft, and land fixes for issues in the software factory itself. GBrain has a complex “dreaming” loop that looks for conflicts, synthesizes reports, and connects items into a knowledge graph. Every product analytics suite from PostHog to Amplitude is now selling a “self-driving” product loop. For now teams are experimenting and, naturally, not all self-improvement attempts immediately bear fruit. But ultimately, improvement is what we’re all after. This might mean faster decisions, clearer processes, simpler workflows, better products, more leads – if it’s part of your loop and you can measure it, it could be optimized. And of course, what can be optimized will get over-optimized. At least at first. Which brings us back to, as always, judgement. All these newfangled brains still need to serve the hearts. This is one of many agentic workflows contributing to GitHub’s stratospherically increasing server load and resulting sadness. You could use Google Drive for sync, which would be faster and automatic, but it neither resolves conflicts within files, nor makes edit history easily accessible. ↩
