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. ↩

Forestwalk’s CTO Jenn Cooper shares what she’s been learning about tests, after a couple years of increasingly coding with agents: Most discussions about AI-native development jump from this problem – agents’ tendency to accumulate tech debt – directly to tests. … Tests verify that code does what it did before. Whether what it did was even the right way to do it is a separate question. She argues that while agents make it easy to have rigorous traditional test coverage, at best unit tests maintain local code cohesion. At worst, they can actually make it harder to improve what agents are worst at: the wider coherence of the entire codebase. So far I’ve been impressed with how effective the broader automated checks she describes can be to guard against agentic nonsense.

Recently, Andrej Karpathy argued that the ideal interaction pattern for AI models is voice in, visuals out: Audio is the human-preferred input to AIs, but vision is the preferred output from them. Around a ~third of our brains are a massively parallel processor dedicated to vision; it is the 10-lane superhighway of information into brain. The claim is that while “text in, markdown out” is the mode most people use LLMs today, what we should be building toward is a Jarvis-like mode where we primarily speak to AI – and it primarily responds with UI, video, or other visuals. Let’s check in on where we’re at for both halves of this claim: visuals as output, and voice as input. Visuals Out Humans love looking at things! While it can be convenient to be able to listen to our computers speak, waiting through a voice response feels kinda… ugh. You can increase the speaking rate, but fundamentally, the fastest way for a computer to give humans information is to display it. We’re faster at reading text than we are at listening, but that’s just the start. There’s a good reason computers long ago evolved past text-only terminals: richer interfaces are often faster, clearer, nicer, and more useful. The power of human vision has facilitated a rich history of computers showing people stuff. At first, LLMs weren’t great at producing visuals, often spending many tokens to produce half-baked results. However, Anthropic’s Thariq Shihipar recently wrote how HTML is increasingly a viable output format to supplant Markdown, for certain model responses. This is great, since HTML is a powerful way to show visuals. Going beyond text can give us dynamic: Hierarchy (sidebars, columns, navigation) Exploration (drill ins, filters, expansion) Direct manipulation (scrolling, dragging) Data visualizations (graphs, charts, dashboards) Mockups and prototypes (show, not tell) Illustrative images and video (pelicans, bicycles) Thus the DOS era of AI begins to end. While it will be a while before general-purpose agents consistently return compelling HTML in response to arbitrary requests, visual responses are already practical for vertical agents – it helps to do one thing well. Recent months have seen a noticeable uptick in AI features producing useful diagrams, charts, sliders, and so on. So, yep. Visual output is a natural fit for AI, and we’re already going beyond plain text. Voice in On the other hand, most people are ambivalent about the idea of talking to AI. We were promised the Star Trek computer, or Jarvis, but so far we’ve gotten Siri and automated spam calls. There’s merit to the skepticism. Fundamentally, voice is never going to be the only input mode for computers. Just as we sometimes need voice because our hands are occupied, other times it’s impractical to speak aloud for social or confidentiality reasons. And even when we can speak, voice alone isn’t enough – effective computer use will always require more precise inputs, such as mouse clicks and drags. However, voice is a deeply human and useful input mode. For example, it’s excellent for getting out our not-yet-organized thoughts and observations. While ChatGPT voice mode is substantially dumber than its text mode, it can still be useful for organizing your thoughts – advanced rubber-ducking. Compared to text, speech also contains additional nuance and detail. Voice is not just words – it’s intonation, timing, tone, pitch, energy, and emphasis. Where a transcript would only see okay, how you voice the “okay” might convey “Sounds good!”, “Tell me more”, “I kind of doubt that.” or “Get the hell out of my office.” This is why we call somebody if we need to have an emotional conversation, rather than sending misinterpretable text messages. We speak faster than we type in terms of WPM, so together with the additional details in our voice, we simply put out more information per second via voice than from a keyboard. The Tyranny of Latency So, great. Talking to AI and having it respond with visuals are both natural and highly useful. Why aren’t we doing this all the time? If you’ve actually used AI voice systems, you’ve probably noticed that they’re usually slow, dumb, or both. In order to feel fast, we’ve known since the 60s that computers should respond within about 100ms, and that in order to keep users’ sense of flow, they need to respond within about 1000ms (1 second). Even before networks and giant neural nets, it could be a challenge to hit these bars. But voice AI adds a substantial new hurdle. Humans are more sensitive to lagged voice than we are to lagged visuals. For a fully fluid voice conversation with interruptions going both ways, the latency bar is about 200ms. More than that, and interruptions feel janky and annoying. You’ve experienced this on voice calls with other humans: if there’s a noticeable lag and you’re stepping on one another’s words, you back off into a more stilted turn-taking conversation style. At best, this is what we get with common AI applications today: slow, single-duplex turn-takers. They listen until it seems like you’ve stopped, generate a response, then stream until it sounds like you’ve started saying something, at which point they abruptly stop. While 200ms is a long time in traditional computing terms – a smooth animation frame needs to render in just 16ms – you’ll find 200ms is not a long time to do the complex work of sending a user’s voice over the network, making sense of it, generating a voice response, and sending it back. In order to achieve the required latency, applications generally do voice inference with rather small models. The most advanced voice model most people have tried, ChatGPT’s rather outdated voice mode, is profoundly dumb compared to GPT 5.5 or Claude Opus 4.8. Even if you understand why this is the case, it’s fun to watch that guy who awkwardly gets it to misadvise him1. But there is hope. Earlier this month Thinking Machines gave a preview of their approach for realtime voice models, which they call Interaction Models. These are full-duplex systems, which means we’re finally getting simultaneous perception and generation. Rather than switching between generation and listening, these streaming models slice time into 200ms chunks, interleaved continuously. While 200ms isn’t enough to generate a very smart response, that fast streaming model can call slower, smarter models to do things like lookups, reasoning, and generating artifacts – then return the results in 200ms chunks when they’re ready. Now, this is all very exciting, and I’m excited to see where it goes. But despite the claim “The model instantly reacts to visual cues”, even their demo videos show a noticeable and sometimes awkward lag between stimuli and voice responses. This is partly because it’s early – Thinking Machines was only founded last year. But it’s partly because humans are just that sensitive to voice delays. It’s a fundamentally difficult problem. However. Humans are less sensitive to laggy visuals. Since visuals are less intrusive than a voice response, you get the more permissive 1000ms response budget that we’re used to when building computer programs. This is convenient, since voice → visuals is a great interaction mode. Voice In, Visuals Out The good news is that you don’t need to wait for Thinking Machines or any other model advances to build useful voice in, visuals out experiences today. Here’s a quick example of what voice in, visuals out can feel like: not a chat, but a live visual representation of what you’re working on. The Cedarloop voice agent can help outline notes, file bugs, and do other in-meeting work. Here are a few latency approaches to keep in mind if you’re working on voice-in, visuals-out agents: The underlying model needs to be very fast. Any slower than p50 latency of 700ms and p95 of 1200ms will feel janky. Meanwhile, it’s common to see small requests on “fast” models that have over 5000ms of p95 latency 🫠 You need to send uncomfortably short time slices for inference. Err on the side of sending incomplete text rather than waiting for two-second pauses, and use context engineering to have the model heal any errors. Keep your context prefixes stable, so they can be well-cached. 90%+ of our input tokens are cached, and thus far faster (and cheaper) than if we were sending fresh context every request. Tokens are slow, and HTML is token-heavy. Realtime visuals-out needs to use efficient formats out of the LLM, which can then be displayed in a rich web or native view. Get it dialled in right, and you can build delightful-feeling experiences. If you’re working on these kinds of realtime apps, I’d love to chat – happy to share what we’ve been learning, and hear what others have been finding. GPT-Realtime-2 recently launched in the API with “GPT-5-class reasoning,” but is not in ChatGPT yet. And so far, Claude has no realtime multimodal model at all. ↩

Years ago, back when I was leading a mobile dev team, my friend had an idea for a business. You see, back then the most frustrating thing about mobile dev was the final step: getting your app on actual phones. Builds, provisioning, and code signing made for a harrowing trial, festooned with obtuse errors and other sharp spikes. So, Dennis had a pitch for me. “What if,” he asked, “we did all your apps’ builds and provisioning and signing for you, in the cloud?” I raised an eyebrow. “Well, obviously that would be great. In theory. But it would be too annoying to build that. Apple drops Xcode versions and switches submission requirements with no warning. And you’d need to make sure that…” He stopped me with a wave. “Right, but: if we did it, and it worked. Would you use it?” “Well, of course we would. But I don’t think you want to run this.” My attempt to discourage him didn’t work. Perversely, the idea that this was a hard problem got him more excited. He immediately dove in. Three years later, Buddybuild was acquired with fanfare. They’d accomplished what they set out to do, made a tidy profit, and they were even able to keep theirgreat team here in Vancouver. Wisely they ignored me, and chose to do the hard thing. The Nice Thing About Hard Things Doing something hard yet pointless is foolish. But doing something hard yet valuable has a lot of benefits. It’s easier to recruit a great team to tackle hard, worthwhile problems. It leads to less competition, due to schlep blindness. It’s a great way to hone your ambition and discipline – over time, working on hard things feels less hard. Consider that. If you have a great team, less competition, but more ambition and discipline, then you’re set up to do well. These days are well suited to attempting hard things. Our tools are improving so fast that a project which seemed straightforward last year might be trivial next year. Better to dial up the ambition a bit. Of course, there are a few pitfalls to trying hard things. You’re more likely to burn out, for one – it’s very important to sleep, exercise, and manage your own energy when your work is kicking your ass. And it can sometimes be difficult to tell when the “hard and purposeful” parts end, and when the “overcomplicating things” or “naive folly” begins. I highly recommend having a co-founder that finds hard and purposeful problems motivating, yet takes a dim view of overcomplication. Doing hard things is best not attempted alone. But, all in all, it’s a good default. We can do hard things. So, let’s.

Small companies are, by default, very transparent. When there are 4 people working in a room, you have a direct line of sight on what everybody else is doing, and why. Your docs, Slack channels, and repositories are open to everybody. When the CEO has an epiphany that changes everything, you all know right away – probably because you were at lunch together when it happened. Thus, startup founders will often get religion about transparency. “Our culture,” they’ll declare, “is to be radically transparent! Everything defaults to open. We hire adults, expect them to do great work, and give them the context they need.” Yay transparency! And this works pretty well. Transparent orgs tend to delegate more effectively, have higher accountability, less politics, faster trust, and just plain ship more. Transparency helps bigger orgs adapt more quickly to the ground truth, responding to customer signals that execs might not be directly exposed to. But, at a certain scale, radical transparency strains. Some idle musing by the CEO sends a team off on an unimportant side quest. A well-justified compensation anomaly upsets a group who is missing background information. A 450-message Slack thread about bike shed paint color choices devolves into factions, hashtags, and philosophical arguments about the morality of taupe. #nevertaupe And if you talk to people at a large yet highly transparent company, you’ll hear about the hazards of the relentless firehose. A thousand shared Slack channels, to start. But also a glut of docs – some critical, most unmaintained. Then there’s the meeting notes, meeting recordings, and meeting invites. Plus proposals, requests for comment, and requests to comment on your proposals’ comments’ resolutions. “So, you like information, eh? Well, have all the information in the world!” How do you make sense of all this? While some people are tenaciously able to find, within this chaos, the important info they need to do great work, a lot of otherwise-capable people get easily distracted by information that just might be urgent, provocative, or even just… shiny. 🪎 Meanwhile, allowing everybody access to every historical doc is occasionally useful, but it also presents an ever-growing surface area for leaks and legal liability. Are you sure there isn’t something highly sensitive or disagreeable in those 99,999 unmaintained Notion docs? So, as companies grow, they tend to lock information down. Some – Netflix, Stripe, Shopify – do their best to keep as transparent as possible while still complying with necessary guardrails. Others – Apple, Palantir, Oracle – move toward a need-to-know basis, ensuring information flows top-down. With more control over information, it’s easier to ensure that leaks or internal distractions don’t derail your plans for surprising product launches and/or world domination. Of course, every company’s culture is forged by the market they operate in, but there’s always some tradeoff here. And as companies grow, they tend to regress to a boring middle ground. However. As with many tradeoffs, the balance has recently begun to shift. Given this firehose, please assess my plan Recently, we’ve seen a revolution in tools that can make better use of the firehose. Slack can now summarize your unread messages, albeit with mixed effectiveness. Tools like Glean and Unblocked can consider a mountain of your company’s data and answer important questions about it, albeit limited to the data they can actually see. And large open companies like Shopify and Stripe have internal tools that let employees’ agents query, analyze, and act on the copious data any given employee has access to – albeit with some sharp edges and exfiltration risks. Just as LLMs are making the world’s data more useful to the world, they’re making companies’ internal data more useful to employees. Of course, this can be misused! In some companies we’ll see further secrecy – I’ve heard of AI search tools and MCPs letting employees find accidentally-visible compensation data and other spicy docs that hadn’t been audited. I’ve heard of support agents giving customers true-but-problematic information because they surfaced it with internal AI tooling without proper training. But as we evolve past early growing pains, and into teams and processes fully making use of this stuff, the anecdata points toward this new tooling becoming a superpower. Agents’ newfound ability to effectively query and reason about far more data than can fit into context is making the long tail of communications and docs much more useful for decision-making – but only when people have access to the relevant data. Given that, the maturation of AI tooling will motivate companies to become more transparent. In 2024, the cost of being internally secretive was meaningful but manageable. Although Apple keeping information need-to-know sometimes leads to waste, or important changes being slow to diffuse through layers of management, they’ve done, like, pretty well for themselves? With all the scrutiny from press, competitors, and regulators, you can see why they’ve kept it up. But as all companies increasingly have tools that can assess, consider, analyze, and make use of all the business’ communications and documents, what kinds of org are going to benefit most? Well, the ones that let their employees access more context. Extremely transparent orgs like Zapier, GitLab, and PostHog that might have struggled to cope with their firehoses – and who often had gaps in the data due to untranscribed meetings and decisions – will increasingly be able to leverage it. Sure, not all of it, certainly not at first. (Some of it is just junk.) But increasingly more of it. And critically, it won’t just be executives that will be able to attend to all this knowledge. Were we ought to be The frontend dev working on your internal admin dashboard should be flagged that the React upgrade issue they’re battling right now was just solved by the customer-facing dev team. The intermediate developer who is incensed about a company-wide tech decision should be able to build their understanding of why it was made without booking a 1:1 with the responsible Principal Engineer. Your go-to-market team should be able to “see” through to the code, developers’ conversations, and the recent decisions around a given feature, letting them give customers correct and timely information about what to actually expect from the product today. And everybody in your company should, when it’s useful, have key company-wide strategy docs available to their agents as they make plans and decisions. And then, when a new revelation motivates the exec team to improve those docs, then bam. All the product engineers’ agents will take this new strategy into account right away. Anybody who’s worked at a large company and/or used CLAUDE.md knows this won’t be a silver bullet – deeply ingrained habits and momentum can not be simply prompted away. But as the tools and the data improve, the advantage will accumulate. When we launched a realtime meeting agent last month, we expected to get feedback about its defaults being too open – currently, Cedarloop defaults to sharing its collaborative notes and tools with all attendees live. But instead, we’ve seen two diverging kinds of feedback: many of our users want the tool to be less visible to external guests and customers, but more open internally within their companies. Which in retrospect makes a lot of sense: decisions and actions in your team’s work are increasingly useful across your company, but your customers shouldn’t need to worry about all that. So long story short, more internal transparency is coming. It will take some time. Apple isn’t doomed, and just because Zapier and Shopify are already working that way doesn’t mean they’re going to instantly be turbo-boosted. But it seems a new era is coming, where siloed knowledge, information hoarding, and secrecy-by-default will become less tenable. The firehose will evolve from a spicy distraction to a useful input to important work.