Most of how our company runs now lives in one written-down place, and the longer we operate this way the stranger it seems that we ever ran companies out of people’s heads. In a normal week I write a decision down once and stop repeating it in meetings, an agent drafting something reads the same goals document a new hire would, and the answer to “what are we doing and why” is a file anyone can open, whether or not they’re a person. The vertigo of being able to build anything, which I’ve written about before, mostly resolved for us into this: one shared picture of the company that everything, human and machine, works from.

It’s less mystical than it sounds. It’s a folder of plain documents. The goals for the half and the reasoning behind them. Records of decisions, written down with the why attached, so nobody has to reconstruct six months later what we were thinking. A profile of how each of us writes, and mine literally includes a list of phrases I never use, which any agent writing under my name reads before it writes a word. What each department is for, what we know about each customer, and the current state of the work in flight. None of it is exotic. What’s different is that it’s the operating copy, not documentation of the real thing happening somewhere else. If it isn’t written there, the company doesn’t know it.

The thing I didn’t expect is how much falls out of there being no translation layer. The document that aligns the people is the same document that steers the agents, so nothing gets rewritten into a second format for the machines, and keeping one version true is the whole maintenance burden. Onboarding turned out to be the clearest example: bringing on a person and bringing on an agent became the same act, which is handing over the brain and letting them read. And my own job quietly changed shape along the way, less producing the work, more maintaining and reviewing the written-down place the work runs from. That sounds like a demotion from making things, and it took me a while to see that it’s the opposite, because everything downstream inherits whatever the brain says.

Which is also the honest cost of running this way: everything downstream inherits whatever the brain says. A person reading a stale document might squint and ask about it. An agent just believes it, and so does the next one, and the error stops being a typo in a file and becomes something your company thinks. We ran into this directly a few weeks ago with our own vocabulary. We’d been using a shorthand for this whole way of operating across our internal docs, and when the term surfaced publicly from someone prominent meaning something adjacent but not quite ours, our documents kept speaking the old usage, which meant everything that read them did too. Fixing it wasn’t an edit, it was a sweep through every live document that carried the term. Doc debt used to be a nuisance you cleaned up eventually. When agents run from the docs, doc debt is org debt, and it compounds at the speed of everything reading it.

What I don’t have, and what I’ve come to think nobody has yet, is a way to test whether the brain is right. I can check that output matched a format, that a rule wasn’t broken, that a draft used the phrases I actually use. There’s no check I can run that tells me the goals document is describing the right goals, or that a decision we recorded with full confidence eight weeks ago still deserves to be in there steering things. You can tell the brain is wrong only by what comes out of it, and usually later than you’d like. So the most important documents in our company are the ones with no test to run against them, and keeping those true, reading them the way you’d review work, turns out to be the job now. I’d still rather have this problem than the old one, where the same knowledge lived in nobody’s file and everybody’s head, but I want to be honest that we traded chaos for a different kind of care.

A short Friday digest for people building companies with AI in the middle of them: what shipped, what got funded, and what it means, from a founder running his company this way. First edition, so it reaches back a little further than a week.

Signal of the week: Block launched Buzz. Jack Dorsey’s team shipped a free, open-source workspace where humans and AI agents share channels, and the agents are members, not bots: their own identity, their own keys, signing their own work (Block’s announcement, TechCrunch). About 6,700 GitHub stars in its first two days. The launch discourse’s own top question, raised by a Slack employee no less: once agent teammates can see everything, who decides what each one should see? Identity, it turns out, was the easy half.

Andrew Ng launched OpenWorker, and YC asked for the team version. OpenWorker (built with Rohit Prasad, ex-Alexa) is an open-source, local-first personal agent that “delivers finished work, not just chat,” runs on your machine with any model, and checks in before doing anything consequential. The same week, Y Combinator’s new Requests for Startups asked for “Multiplayer AI”: shared agent sessions a team can watch, redirect, and hand off. Between Buzz, OpenWorker, and YC’s ask, the agent-as-coworker got named from three directions in seven days.

Everyone is converging on plain files. LangChain’s OpenWiki Brains, Vault-LD 0.5, and Google’s Open Knowledge Format: three independent moves formalizing markdown as agent memory within days of each other (The New Stack’s read: the moat is shifting from the model to the markdown a team owns). Files won because humans and agents can both read them. The unglamorous part nobody’s product does for you: keeping the files true.

Subscribe now

Chroma’s CEO proposed “12-factor companies.” Jeff Huber, in the lineage of 12-factor apps: own your context, rent your intelligence, develop rubrics, encode your expertise. The standout line: “The old firm bundled labor and coordination. The new firm bundles context and authority.”

Quick hit: Lyzr says its own agent ran the outreach for its $100M Series B, fielding questions from 130+ investors on the way to a ~$500M valuation.

The conversation. The big story deserved more than a paragraph this week. Rahul Singh, an AI architect who builds AI in the open at Intelcraft.ai and helps businesses build and scale operationally critical data, cloud, and AI systems at Anant, joined me to talk through Buzz, the files convergence, and what each of us would actually let an agent run.

To catch future videos, subscribe to our YouTube channel @InsideAINative.

The week in one question: everyone is racing to put agents in the room, and nobody has shipped an answer to what all those teammates work from, or who keeps it true.

Every Friday. The whole week’s signal, fifteen minutes to read, from inside a company that runs this way.

Fired from the middle of the job

Loops are what made me see it. A loop is the newer way of working with agents: instead of asking for one thing at a time, you give an agent a goal and it runs on its own, reading what it made, deciding what to do next, going for hours and sometimes days without you in the conversation. More of our work runs this way every month, and the plain way to say what a loop does is that it fires you from the middle of the job.

All the steering you were quietly providing from inside the conversation has to come from somewhere else: the goal written down the way you actually mean it, the context that used to live in your head, the checks that catch it when it drifts. A loop without those isn’t faster work, it’s an agent wandering, and it wanders on your budget.

For as long as I’ve worked, the expensive part of building was making the thing. It cost human time, human time was capped by attention and headcount, and we organized companies around that scarcity: the backlog, the quarter, the roadmap negotiation, all of it machinery for choosing carefully because you could only make so much. Agents dissolved that constraint, the making itself is fast and close to free now, and what a loop bills you for is the steering around it. Some of that bill is literal compute, agents that either converge on something useful or wander and burn money until you stop them, and we’re already hearing about companies blowing through their AI budgets this way. An agent left running for a day is a spend decision in a way a prompt never was. The rest of the bill is the human half of the collaboration, now explicit: deciding what’s worth pointing an agent at in the first place, and being able to tell whether what came back is any good. Neither of those gets cheaper as the models get better.

A level up from the keyboard

You can watch planning change shape under this. The old planning question was whether you could build something at all, and you arranged your people and your quarters around that limit. The new questions are what deserves the compute and the attention, and how much you can trust what comes back without reading every line of it yourself. Those are judgment calls, and they ask for a different kind of attention than the kind we built our companies around.

I don’t think any of this is a loss, and if anything it’s the opposite of the worry that AI flattens the work and leaves people with nothing interesting to do. The bounded, repetitive middle of the job is what got cheap. We keep the two ends that were always the most human, choosing what’s worth making and telling whether it came out right, and the collaboration that was hiding inside prompting all along is now visible, priced, and worth being deliberate about. That’s where the cost lives now, a level up from the keyboard, and I would rather spend my time there anyway. Getting fired from the middle turns out to be a promotion.

Strip away the channels and the emoji and workplace chat is alignment machinery. Letting people know something changed. Asking a question whose answer lives in someone else’s head. Checking status, agreeing on what we’re doing, signaling that a thing is ready or that a thing is needed. It’s the connective tissue between people who each hold one piece of the work, and every ping is a small payment on the same bill. Chat is the tax a company pays to stay aligned, levied continuously, in everyone’s attention.

The tax got cheaper, so we paid more

The strange thing about this tax is that making it cheaper to pay made us pay more of it. Coordination used to be expensive, a meeting you had to call, a memo you had to route, so companies rationed it. Slack dropped the price of a coordination ping to nearly zero, and total spending went up, the way it does whenever something scarce becomes nearly free. A busy Slack reads as a company staying aligned, but the volume mostly measures how easy the tax is to levy, and how much attention it collects along the way.

The tax was rational for one reason: alignment could only live in people. The picture of what the company is doing and why sat in heads, so keeping that picture coherent meant constantly moving pieces of it between heads. Every handoff was a context transfer, every standup a sync, every “quick question” a fetch from someone else’s memory. Chat won because it’s the cheapest mover of context anyone ever built.

When the work stays aligned on its own

That premise is what’s changing. As more of the work runs through AI that reads and writes the same shared picture of the company, the goals, the decisions, the current state of things, alignment stops being something people do between tasks and starts being a property of the system doing the tasks. Work that starts from the shared picture doesn’t need a kickoff ping, and work that lands back into it doesn’t need a status update, because the update is the work itself landing where everyone, human and AI, can see it. If the work stays aligned on its own, there’s less and less to pay the tax on.

None of this removes the need for judgment, direction, and wisdom about where the work should go. But ironically, those were exactly what chat buried, the higher-order questions lost under an avalanche of tactical pings and scrolls and never-ending yammer, and the few conclusions that did surface sank into the scrollback for someone to ask again three weeks later. The endpoint I’m describing is a more focused company, not a silent one, where the talking that remains is about direction and judgment, because the tactical layer stopped needing talk.

The test we apply now

This has become one of the rails of our AI strategy at BotBot, maybe the clearest one we have. Every piece of AI we bring in should shrink the alignment tax, and when something has us pinging each other more instead of less, that tells us it’s coordinating rather than working, and we’ve wired it in wrong. I’d offer the same test to anyone: if your AI makes you more dependent on chat, it’s moving the work around instead of absorbing it.

We’re a tiny team, so I hold our own evidence loosely, but our Slack has gone strangely quiet as more of the work moved onto a shared picture like this, and the overhead went with it: less waiting on each other, less re-explaining, fewer decisions dissolving into the scroll. I don’t know yet how far this goes, or how it plays at a hundred people instead of two. But it’s the first time I can remember that the honest answer to “how do we stay aligned” might not be “talk more,” and I’d ask any bigger company the question that started this: how much of your Slack is conversation, and how much of it is the tax?

There’s a growing body of research, and it’s worth taking seriously: students using ChatGPT score lower on surprise tests weeks later, consultants given AI for tasks outside its capability perform worse than those working without it, EEG studies show weaker brain connectivity in heavy AI users. BCG just published a study where half of C-suite leaders say they’re already observing de-skilling in their organizations, and the skills they rate as most important (judgment, problem framing, creative thinking, causal reasoning) are the exact ones they see as most at risk. Researchers have started using phrases like “cognitive surrender” and “cognitive debt” to describe what happens when people trust AI outputs because they sound convincing, not because anyone verified them.

But most of the research is looking at people doing the same work they did before, just with AI handling more of it. The analyst still writes reports, but now AI drafts them. The consultant still does analysis, but now reviews AI’s analysis instead. And in that frame, yes, the concern makes sense, because you’re outsourcing the cognitive effort that used to keep those skills sharp. The question is whether that’s the only frame.

What happened when shipping got fast

A year ago, shipping a feature took weeks. Now it can take a day. There’s an assumption that should mean less work, but the opportunity cost actually runs the other way: when an hour of building is worth what a week used to be, every hour spent figuring out what to build next is a day not shipping. The work moved up a level, and there’s more of it than before.

When shipping is fast, the bottleneck shifts to knowing what to ship. How do I get signal from customers faster? How do I understand how the market is evolving? How do I build the whole system that ships a feature, writes the blog post explaining it, sets up the email campaign inviting users to try it, sends another email to leads, analyzes how many accounts were impacted, updates the marketing pages in our voice, learns from the result, and then figures out what to do next, all in one cycle? That kind of work is new. It didn’t exist a year ago because it wasn’t possible a year ago, and it requires more sustained attention and judgment than writing the code itself ever did.

So maybe the atrophy research is right about the situation it’s studying, but the situation is specific: work that stayed the same while AI absorbed the effort. If you’re an analyst who used to write reports and now reviews AI reports, the thinking that kept your skills sharp got outsourced, and over time you lose both the ability to do the work without the tool and the judgment to know when the tool is wrong. That’s real, and the research on it seems right to me.

But my experience has been the opposite. The old tasks got compressed or automated, and new, harder work appeared at a higher level of abstraction. Maybe my ability to write a specific function will decline. But my mind feels as engaged as it’s ever been, because I’m spending my days thinking about the landscape, how our market is evolving, how to build workflows that build on each other, and how to keep AI connected to our company’s voice, vision, and values as it handles more of the execution. That’s all work that sits above the code, and it’s more demanding than the code was.

Why I think this is easier to see as a founder

I think this is especially visible to me because as a founder, questioning how we work is literally part of the job. I don’t just get to reshape my role as AI changes what’s possible, I have to. Every week I’m asking how we should be building, how our process should change, whether the way we shipped last month still makes sense this month. The shape of my work is always in question, and AI made that questioning more intense and more consequential, because the answers change faster and the stakes of getting them wrong are higher.

That means I’m holding strategy, product, market, and the development system in my head simultaneously, while also steering AI to stay connected to our company’s voice, vision, and values as it handles more of the execution. That’s a lot of new cognitive load, and it’s the kind of thinking where I don’t think AI can substitute for you, because the judgment about what matters and why is the whole point. BCG’s research actually names “problem understanding and framing” as the most critical skill and the most at risk, and I’d agree with that, except that for me the risk doesn’t feel like atrophy. It feels like being asked to do more of it, faster, with higher stakes.

Inside a larger organization, I think the picture might be very different. If you’re an analyst at a consulting firm, what does AI actually do for you besides replace some of your own effort? You might not have the latitude to step into the higher-order work, the problem framing, the system design, the strategic judgment, because the organizational structure keeps you in a role that looks the same from the outside even after its core thinking has been hollowed out. BCG calls this the “autopilot trap,” where senior people substitute AI judgment for their own out of habit, and I think it’s even worse for junior people who never get to build the judgment in the first place because AI handles the entry-level work they would have learned from.

I’m starting to wonder whether the atrophy question is really about AI at all, or whether it’s about whether roles can evolve fast enough to absorb what AI makes possible. As a founder I can reshape my job every week. An analyst three levels deep in an organization probably can’t. And the interesting question, the one I don’t hear enough people asking, is whether we’re making it easy enough for people to step into the new work, or whether we’re just watching the old work get automated while the new work goes uninvented.

The pressure of what you could be doing

There’s another angle to this that I don’t see discussed much, and I think it matters. I wrote separately about how quarterly planning starts to feel like a scarcity ritual when shipping gets cheap, and the pressure side of that is worth naming too. When AI makes it possible to do three or four times as much in the same window, the cost of not doing it goes up. Every hour you spend doing something the slow way is an hour someone else spent shipping three things and learning from all of them. That creates a real kind of pressure, and I feel it.

It also creates a new challenge around review. When you’re coordinating AI across a dozen workstreams, the volume of output that needs human judgment increases. You’re reviewing more, and at a higher level: is this aligned with our strategy, our voice, our values? Does this actually serve the customer? Is the AI drifting from what we intended? That review work is demanding in a way that wasn’t part of anyone’s job a year ago.

Where this leaves me

I don’t think AI is making work easier for anyone who’s doing it seriously. I think it’s making work faster and more demanding at the same time, and the load shifts from the execution itself to the thinking about what to execute, how to steer it, and how to learn from what the system produces. Whether that’s a better situation depends on whether you have the latitude to step into the harder work, or whether the organization around you keeps you in a role that looks the same from the outside even after its core has been hollowed out. But for those who can make the shift, the “AI makes us lazy” story is incomplete. The real question might be how to make this new pace and chaos sustainable.

That’s also how we think about building BotBot. We run the company out of a shared system that people and AI agents both read from and write to: the company’s identity, voice, strategy, operations, all in one place, and agents draw from it the same way a new team member would. Building and maintaining that system, keeping it current, making sure AI stays connected to who we actually are as it does more of the work, that’s some of the most demanding thinking I do. It didn’t exist as work a year ago, and now it’s most of what my days look like.

I’m not sure shipping is expensive anymore. A small team with good agent workflows can ship a feature in days. But the ceremony hasn’t caught up, and I think the problem is deeper than just inefficiency. The planning ritual teaches carefulness as a virtue: protect the roadmap, don’t waste a sprint, make sure every feature is justified before you build it. That made sense when shipping was the bottleneck. Now you’re planning for a quarter when the game has moved to days. It keeps your thinking small, your learning slow, and your company behind.

What’s actually scarce now is knowing what to build and whether it worked. Understanding the customer, the market, the codebase well enough that you can keep shipping and learning rather than carefully guarding a quarterly plan. Which means the interesting goal might not be “build X” but something more like “build the system that increasingly knows what to build, can validate whether it worked, and keeps learning and shipping on its own.”

What this looks like in practice

Old goal: “Build a measurement and experimentation system by end of Q3.”

New goal: “Build the development workflow where shipping a measurement system, or an experimentation system, or anything else we decide matters, takes weeks instead of months, and each project makes the next one faster.”

Old goal: “Launch one pilot with a real customer.”

New goal: “Build the feedback loop that makes every future pilot cheaper to run and faster to read.”

Both versions require doing the same work this quarter. The difference is what you protect when things get tight and what you measure to know if you’re succeeding. The first version optimizes for a deliverable, the second optimizes for a capability that compounds.

Where we hit this concretely

We ran into this in our own H2 planning at BotBot. The first draft felt familiar: work backward from target metrics, imagine features, assign owners, commit to a date. Build the measurement system, run a pilot, ship experimentation. The usual ceremony.

But we kept noticing that shipping the features wasn’t really the hard part anymore. With improving agent workflows we can ship features in days instead of months now. What’s actually hard is knowing which features matter, whether they worked, and what to try next. The spec pipeline we built last quarter ended up mattering more than any individual spec it produced, because it’s the thing that makes the next feature cheaper and faster and better informed. So the top-level goal became the system itself: build the capability to absorb signals from customers, market, and codebase, validate what works, and keep shipping and learning. First feature sets the baseline, third feature has to be 30% faster, and by month six we’re targeting 50%.

The tension showed up immediately, though. “We’re building the system” can easily become a way to never be accountable for a result. Speed as a goal sounds good until nobody checks whether you actually got faster. So we held both: the system goal on top with concrete delivery targets underneath it. If we can’t show the compounding in real cycle-time numbers, the philosophy isn’t working and we stop pretending it is.

What changes in how you plan

When this clicks, a few things shift in how you think about planning.

The first is what you protect when scope gets tight. The instinct is to cut the “meta” work and protect the feature, but I think you should invert that. Protect the learning loop, the verification pipeline, the development workflow. Defer feature scope instead, because one quarter’s feature is one quarter’s output while the system produces every quarter’s output.

The second is what you measure. Lines shipped and features launched are trailing indicators of a team that already works well. The leading indicators matter more: cycle time from idea to validated outcome, what percentage of verification is automated, how fast a new team member or a new agent becomes productive, and whether you can actually show that project three was faster than project one.

And the third is what posture your goals encourage. Quarterly planning teaches teams to be careful: protect the commitment, don’t waste the sprint, justify before you build. But careful is the wrong posture when shipping is cheap and learning is the bottleneck. The goals should encourage experimenting, shipping fast, learning from what you shipped, and doing it again. When “shipping” becomes unremarkable and routine, that’s the system working.

The cost of being too careful

The counterargument is that this sounds like building infrastructure instead of shipping product, which is the classic trap. Fair concern. But the old infrastructure trap was about building abstractions nobody used. This is about building the system you work through every day, and if it doesn’t make tomorrow’s work faster it’s failed.

I think the real risk actually runs the other way. While you’re carefully protecting your quarterly roadmap, someone else is shipping constantly and learning from all of it. The teams pulling ahead aren’t planning better. They’re in the arena, experimenting, iterating, compressing their cycles. Every quarter you spend being careful is a quarter someone else spent learning. The scarcity mindset that made quarterly planning feel responsible is now what holds you back.

Where we are with this

The product goals for this half at BotBot are real and specific: goal tracking, experimentation, a pilot with real outcome data. But the goal we care most about sits above those, which is whether we can build a development system where shipping, measuring, and iterating on any of those capabilities gets measurably faster each month. The features are how we prove the system works, and the system is the actual bet.

The flip side of this is that when shipping gets cheap, the work gets harder, not easier. The cognitive load moves up, the pace increases, and the real challenge becomes keeping up with what’s possible. I wrote about that separately in The new chaos of being able to build anything.