Last week the biggest payments company on the internet decided that metering machine intelligence is payments infrastructure, and paid more than $7 billion to own it. The rest of the week’s stories are smaller, and they rhyme: the questions moving to the front of this field are about who meters, who approves, and who decides.

This edition follows five stories across the payments, governance, coworker, and company-brain layers.

1. Stripe agreed to acquire OpenRouter for more than $7 billion

Stripe confirmed it is buying OpenRouter, the gateway that routes requests across 400+ models from more than 80 providers. Bloomberg broke the number at over $7 billion; reporting since has put it between $7.5 and $8 billion in cash and stock. Three months ago OpenRouter raised at $1.3 billion.

The discourse that followed treated tokens as a new unit of exchange, most visibly in Martin Casado’s widely read piece. I don’t buy that half of it: a token of one model does a different amount of work than a token of another, cost per unit of intelligence has not converged, and even a commodity as standardized as oil trades in dollars against different benchmarks. The half that holds is older economics. Metered intelligence collapses transaction costs between companies, and transaction costs are the reason firms exist at all. When buying a unit of work from outside gets cheaper and more measurable, the boundary of every company moves. Stripe just paid $7 billion for the meter that sits on that boundary.

2. Paperclip’s community started building the approval layer

Two editions ago, Paperclip was a star count and an issue queue full of governance requests. Last week the requests turned into engineering: active community work on approval resolution and duplicate side effects (#503), hardening company-scope isolation in approval and access routes (#712), and an open issue on browser-access approval (#2390), while the project passed roughly 79,000 stars. What had shipped by the cutoff is unconfirmed, so this is a report on the work, not the release.

The direction is the story. The open-source project most identified with “run a business on agents” is being pushed by its own users toward approval mechanics: who may act, what gets recorded, what happens when an approval fails twice. The org chart came first, and the operating rules are being written in public, by demand.

3. The coworker cohort answered with distribution

xAI’s Grok Bot arrived on Amazon Bedrock on August 19, with a 500K context window and support for long-running agents, and no governance feature in the release. Lindy’s Slack-based AI Teammate now looks to have launched inside this window, with persistent memory and shared team instances.

Edition 4 asked what stays distinctive once the labs bundle a coworker surface. Last week’s answer was reach: the cohort competed on where the coworker can live and how long it can run. The believes-and-may-do questions stayed where they were.

4. The company-brain cohort found the write path

Sift (sift.wiki, waitlist stage) pitches agents that “work like real staff: you hire them, train them, and check their work,” and its product surface includes handbook patching: agents proposing edits to the company’s own documents for human review. SenseLab (sense-lab.ai, a16z Speedrun backing announced August 12) describes its open-source memory layer as “Git for agent memory. Branches, diffs, PRs, and rollback for what your agents know,” and weights knowledge by outcome: confidence scores earned from what worked in production.

For months this cohort competed on reading and remembering. These two are building the write path: who changes what the company knows, and on whose authority. And they embody two different answers. One routes changes through a human who reviews the patch. The other lets production outcomes promote knowledge automatically. What worked and what the company has decided to stand behind are different states, and the cohort is now split over which one the write path should encode.

5. Quick hits

Buzz shipped two more point releases (v0.5.14 on August 15, v0.5.17 on August 18), including a fix to remote agent mention authorization binding; the cadence stays high and the pass found no change to authority semantics. And Xpander reportedly raised a $7.5M seed for a vendor-neutral platform that helps enterprises adopt agents without lock-in.

The week in one pattern: the market priced the boundary between companies at $7 billion, while the write path inside the company, the question of who may change what agents believe and do, started getting built from three directions at once: approval mechanics at Paperclip, handbook patches at Sift, pull requests on memory at SenseLab.

Related read: This week in AI-native companies #4: The coworker layer becomes a contest.

Every builder my age inherited the same ironclad rules: work in small batches, keep PRs narrow, merge often. Ship what you’re embarrassed by, and increment your way to the answer.

It was important discipline, and it kept reviews flowing and work aligned. But it also reflects a previous reality: when building was the expensive act - months of engineering time per attempt - getting something big wrong was a catastrophe. The answer was continuous, manageable review increments, which meant correspondingly small build increments. Building in small steps was not just orthodoxy; it was a logical outcome of the cost structure of software development.

But that cost structure just inverted, and most of us are still living the old gospel. Today, the right build increment size is the one we all learned was wrong: step one is the whole thing.

When agents are coding, the marginal cost of the next thousand lines isn’t so different from the cost of describing them. But as the speed of writing code has exploded, the review stage is still a lot of the same work: assessing whether the work is right, safe, and on-thesis. Comparatively, that means review - even augmented by agent reviews and test suites - has become much more expensive.

In my own workflow, a night of unattended agent flights routinely lands what used to be weeks of work, but my morning review hour hasn’t changed. Vishal Misra calls the general version of this the verifier bottleneck: compute buys proposals; verifiers buy knowledge. I’d push the framing even further: a bottleneck is something you can route around, but when a resource is scarce, you budget. Review time is the same on the wall clock, and comparatively it has become extremely scarce. Recognizing the scarcity means recognizing you can no longer afford the old patterns.

Imagine “let’s ship the simple one first” - a lean and prudent use of engineering resources. Now price it in reviews and it doesn’t look so lean anymore: reviewing the simple version before the real version doubles the review, since reviewing the final version already covers the ground the intermediate one walked. And the first of those reviews evaluates decisions you already planned to throw away. If building is expensive, the intermediate version bought you information early, before large investments were made in the product direction. When review is expensive, you just doubled the price of the same information.

This has given rise to a new rule in how we work: ship the version whose review teaches us the most. If reviewing the half-step wouldn’t change what we build next, skip to the whole thing.

I was working on a mobile feature and initially planned to test it over local network only - point your mobile browser at a local IP address and start interacting with the mobile view. That’s a lean build proposal: no networking, no mobile app, just the basics. But the works-anywhere version was buildable in the same breath, and reviewing the small one first would have cost a second founder-morning for zero new information - the review was the same length, and the product came out twice as far along. We did it again with a feature for live shared agent sessions: the half-step (paste your teammate a link) was essentially the same work to build as the whole feature - a one-click invitation that lands in your teammate’s inbox. Building the latter was the same overnight flight of agent work, but now one review was evaluating the whole feature, not the incremental build.

But “build everything” is admittedly a bit of hyperbole.

We retain steps that answer important questions, and these have become more important because they’re often cheap to run and in some cases need no real review. A spike or a research pass is work that never ships into the product, so it never buys a second review. We ran a research pass on a framework decision recently that returned “don’t adopt one” in an afternoon - zero build, one decision, the cheap kind of step, and cheaper than ever.

Steps that hold trust boundaries also stay. Our mail feature shipped first as read-only, so we had confidence in the feature before exploring something riskier: drafting, then sending email via agents. So yes to skipping the intermediate version, and no to skipping trust building. These distinctions are becoming the new senior skills.

And steps that are secretly new products, or explorations of new directions, aren’t steps. Step size is a decision about how far to go in one batch of work toward what you already decided to build.

There’s a precondition underneath all of this: building everything in step one is only rational if your process reliably makes wholes reviewable in one sitting. That means decision-complete specs before any build, adversarial passes while the work runs, an independent skeptic at merge time, and reports the reviewer can trust. Rigor isn’t in tension with velocity; rigor is what makes big steps reviewable, which is what makes velocity compounding instead of chaos. Teams that copy the stride and skip the discipline will re-learn, expensively, why lean existed.

The most unfamiliar constraint we’ve hit isn’t on the build side at all. On the biggest night our machine has run - a dozen-plus parallel workstreams landing by morning - the limit wasn’t building, or even integrating. We ran out of decided work to feed it. What limits the machine now is what you have decided clearly enough to hand it.

Which points at where the review hour needs to evolve to scale. Every decision that lives in a written standard is a review you don’t need to repeat, and it can be absorbed into the build process itself. Start with intent - a definition of what counts as good and valid - and you can chip away at the expense of review too: stop re-explaining intent and start approving changes to the definitions of good. The scarcer review gets, the more valuable the written company becomes.

By the end of last week, both OpenAI and xAI had products in the always-on AI coworker category. OpenAI’s ChatGPT Work arrived in July, xAI launched Grok Bot last week, and Lindy relaunched its own Slack-based AI Teammate around the same time. The worker and room layer that felt new a few weeks ago now has two frontier labs and a growing cohort competing inside it.

This edition follows five stories across the coworker, company, memory, runtime, and workspace layers.

1. The coworker category became a frontier-lab contest

ChatGPT Work executes cross-app tasks from ChatGPT, while Grok Bot gives each bot a cloud computer and supports shared context and handoffs across bots. Lindy’s teammate lives in Slack with persistent memory and both personal and shared team instances. These products differ, but they are converging on the same promise: give the agent a room, tools, and enough continuity to behave like a coworker.

I think the category changed last week. Once the labs bundle a coworker surface, the question moves to what remains distinctive. A room and a worker are becoming available from several directions, which pushes the interesting work toward what the coworker should believe, what it may do, and how anyone can tell whether its work is right.

2. Paperclip crossed roughly 78,000 stars

Paperclip, the open-source project for organizing teams of agents to run a business, reached roughly 78,000 GitHub stars by the August 13 pass. It gives the company an org chart, goals, budgets, and agents from different providers, and its community is already filing requests around governance, audit, and execution policy that had not shipped by the cutoff.

At roughly 78,000 stars, agent-run companies are hard to dismiss as a niche experiment. And the issue queue shows what happens after the org chart and dashboard work: people start asking who can approve an action, what gets recorded, and which policies the system can enforce. The appetite for the company full of agents is arriving before the operating rules are finished.

3. The company-brain cohort moved into permissions

Hyperspell’s founder published an essay about claim-level permissions, arguing that file permissions become inadequate when a system synthesizes across sources. The essay proposes provenance, audience, permitted use, retention, timing, and action authority at the claim level, including human decisions for cases that are ambiguous or difficult to undo. It is vendor-authored, but the product question it raises is concrete.

One state still seems distinct from the essay’s stated and inferred claims: ratified. Provenance can show where a claim came from, and permissions can govern who receives it, while neither one says whether the company has decided to stand behind it. That distinction is getting easier to see as company-brain products move from remembering more toward deciding where remembered material may travel.

4. The virtual-filesystem argument exposed two couplings

Dax raised the problem of agent skills depending on a physical filesystem when an agent loop may be running in memory or on a server. The committed source capture separates that complaint into two couplings: capabilities delivered through files, and company truth held in files. A protocol or virtual filesystem can make skills available without disk, while keeping shared truth in readable, diffable files gives people a place to inspect and own the state their agents use.

The question is which half detaches as agent loops leave the working tree. Delivery can become virtual without turning the company’s beliefs into opaque service state. Git is already content-addressed, and a checkout is only one materialization of it, so the file does not have to disappear simply because the runtime moved.

5. Buzz shipped seven point releases in one week

Block’s open-source agent workspace shipped seven point releases from v0.5.5 through v0.5.11 between August 5 and August 12. The release notes covered fixes and performance work, while the research pass found no change to its authority semantics.

Seven releases in a week is an unusually fast cadence for a young workspace, and it sits next to a different pace in the rest of the week’s stories. The rooms, bots, and orchestration layers are accelerating. Permissions and provenance are beginning to follow, while a company position that someone has reviewed and approved remains a separate piece of the system.

Across the week, execution surfaces multiplied while the distinctions around them became clearer: memory, permission, provenance, and ratified truth solve different problems. The field is moving fast enough that collapsing them into one word now hides more than it explains.

Related read: This week in AI-native companies #3: The whole-company agent arrives.

Every week I write this from inside a company that runs on AI agents, about what we’re seeing in the field. This week the whole-company agent showed up with receipts, and the bill for renting one got a name.

1. Vercel runs on one agent, and it’s becoming a product. Guillermo Rauch posted that Vercel built @v, an internal agent powering “every day-to-day job” - “expert in finance, comms, docs, marketing, engineering, business analytics” - and “growing exponentially both in daily interactions and token use.” His extrapolation, not mine: “One can extrapolate to the day AI agents run entire companies from here.” It’s also being productized: @v is “the basis for the design of” Eve, which he thinks “every company should have.” The best part of the post is the ownership argument: “that’s not your agent, that’s their agent... you being in complete control, from source → runtime → data → token, seems like a pretty big deal to me.” And the open question sits right next to it: @v is “seeded by the skills we gave it” and “constantly improving.” Improving against what definition of good, and who approved the change? The field keeps shipping the agent; the layer that keeps it true still has no name on it.

2. Palantir named the trap. On Palantir’s Q2 call (93% growth, 149% US commercial), Alex Karp argued that most enterprises are “token maxing” at their own cost - “transferring their data, their prompts, the way they run their business, their expertise to a third party.” His summary of the deal: they may be paying AI labs to learn what makes their own businesses valuable. The sharper beat came in the Q&A, on what the durable asset is: the alpha “isn’t simply the data... it’s also the metadata, the reasoning traces, the exhaust, the usage... probably more valuable than just the data.” Set his register aside (it runs hotter than mine) and the claim underneath is precise: the compounding asset is the operational judgment a company accumulates by using AI, and whoever holds it holds the business. Watch the word, too: Chamath’s AI-native operating guide used “tokenmaxxing” within days of the call. When two sources that different converge on one coinage in the same week, an anti-pattern is getting named.

3. Buzz made the earnings call. A follow-up to the last two editions: on Block’s Q2 call, Jack Dorsey cited Buzz’s shipping velocity as a highlight - internal product development runs on it with “a very small team,” and he called it a step-change for Block’s core technologies. That’s a stronger signal than launch-week stars: a public-company CEO telling investors the humans-and-agents workspace is material to results. The standing question survives its third week unchanged: a room shows you everything; it doesn’t tell you what’s true.

4. “Company brain” went generic in about two weeks. Hyper, a two-person YC S26 team, branded itself “The Self-Driving Company Brain” and went from zero to $1k MRR in 12 days, landing top-5 on Hacker News and Product Hunt. Supermemory shipped “Company Brain” as a named Slack-native feature that joins conversations with relevant context without being mentioned. And at least half a dozen more vendors published company-brain guides or took company-brain domains this month. When a term goes from contested to everywhere in fourteen days, it stops being a product name and becomes a category - and the category it names is recall. What none of the brains answer yet: what does the company believe, and who approved it?

5. Agents are getting LLCs - and $28.5M just arrived to fund it. Naïve (announced a Series A this week, led by Nexus with YC participating) is building what it calls Autonomous Company Infrastructure: company formation as an API call - KYC, state filing, EIN, spend-capped virtual cards, “a real US company” provisioned like a database - plus compute, a company-wide memory layer, and a research agenda about maximizing work per token. Two details worth holding together: the announcement’s category is autonomous companies - agents that “fully run businesses” - while in their own docs, the CEO-agent orchestration primitives (AgentCEO, AgentStaff, AgentObjectives) sit marked deprecated. The pitch is autonomy; the product that survived contact is provisioning, cost efficiency, and permission gates. Still nowhere in the stack: anything that decides what’s true or what good means. The agent can have an LLC, a card, and a phone number, and no way to know whether its work is right.

6. Quick hits. Ex-OpenAI researcher Gabriel Petersson launched Energy Thursday - a desktop agent that drives your signed-in browser, with a free tier that starts by connecting the ChatGPT account you already pay for (the bring-your-own-subscription pattern reaching consumers). Lilian Weng published “Harness Engineering for Self-Improvement” - frontier-research adoption of “harness” as the word for agent scaffolding that improves itself. The “Gartner Declares 2026 The Year of Context™” post making the rounds is satire (Joe Reis) - which mostly proves “context” vocabulary is now bloated enough to parody. And if you’re building: The AI Conference’s Startup Showdown (SF, Sept 29-Oct 1) closes applications August 14.

That’s the week. The pattern, if you want one: the agent went whole-company, the bill got a name, and the brains multiplied - and every one of those stories turns on the same missing thing. Not more capability: a definition of good the system can check, and someone accountable for changing it. I published my longer answer to exactly that this week in “The Judgment Decorator”: every loop starts with judgment and ends with realignment.

Andrew Chen wrote something recently that anyone building with agents will recognize: the skills he builds “just end up generating more and more things for me to review. What I want now is actions. More outcomes, fewer copilots.” The better his agents get, the taller the pile on his desk. The pile isn’t tooling immaturity, and it doesn’t shrink as the agents improve - it’s structural, and the structure has a name.

Judgment is conserved. You can move it around a system, but somebody pays for it somewhere. A copilot pays at the end of every task: each output lands in front of a human because nothing else in the system knows what done means. Review scales with output volume - O(outputs), if you like - which means the pile grows precisely as fast as your agents improve. That’s the trap in “just review everything”: the cost curve points the wrong way forever.

The alternative isn’t removing judgment. Nothing else in the loop can supply it. The alternative is moving where it gets paid: write down what good means - once, explicitly, in a form a machine can check work against - and the cost curve flips. Review stops scaling with outputs and starts scaling with changes to the standard. You approve edits to the definition of good, not every artifact the definition approves.

An outcome, in this frame, is a loop that closes without you. And a loop can only close when “done” is a predicate the system can evaluate - and the predicate turns out to have three parts: is it correct (done), is it good (quality), and is it aligned (still serving what we’re actually trying to do). Code has decades of tooling for the first part. The second and third are where agents drift, and where the review pile comes from.

Here’s the design pattern hiding in all of this. Judgment shouldn’t sit at the end of the pipeline; it should wrap each loop, like a decorator. Steering goes in before the work starts - the standards, the definitions, the context the agent needs to know what good means here. Verification comes out after - the work checked against those same definitions before it lands. Judgment isn’t removed from the system. It’s factored: hoisted out of the review queue and into a wrapper every loop passes through. Every loop starts with judgment and ends with realignment.

This isn’t hypothetical. Basis, whose tax agents run for hours and sometimes days in production, found that outcome-checking breaks down at that horizon - too many decisions, too little generalization - so they supervise the process instead, and last week they open-sourced the written behavior specs that make it work. Their conclusion, which I’d frame as the whole argument in one line: the ground truth for an agent isn’t its output, it’s how it behaves.

The decorator is where the metaphor ends, not where the problem does. Decorators don’t rewrite themselves. The definitions of good that wrap your loops have to evolve - every failure that slips through is a sentence missing from a standard somewhere, and the fix is editing the standard, not reviewing harder. That evolution is its own loop, and it needs the same care: definitions under version control, changed deliberately, reviewed like the load-bearing code they now are. The wrapper is static machinery; the judgment inside it is a living document.

None of this is new, exactly. Companies have been trying to wrap human loops in judgment for a century: mission statements, standard operating procedures, OKRs - all attempts to write standards explicit enough to manage by exception instead of by inspection. Mostly it half-worked, because people read documents loosely and enforcement was social. The difference now is that the reader is literal. Agents actually consult the standard, checks actually run, and management-by-exception stops being an aspiration and becomes an architecture.

Which leaves the question that I think matters more than any of the tooling: who gets to own judgment? It has to live somewhere. Post-train it into the weights and the model provider holds your definition of good. Encode it in a framework and the framework does. Write it down, in files you control, and it stays yours - portable across models, inspectable, yours to change. Everyone racing to make agents more capable is implicitly answering this question one way or another. It seems worth answering it on purpose.

AI agents do real work now. They write code, draft the email, plan the campaign, file the research. And the moment you let them, you inherit a question that used to belong to managers: how do you know the work is any good?

For code, most of the answer already exists. You run the tests and the type checker, and anything that doesn’t compile or doesn’t fit the shape you asked for gets handed back without a human ever looking. That layer is fast, cheap, and decades old, and it works because those questions have right answers a machine can verify - which is why agents slot into it so easily.

The reason that layer feels solved is that it only covers the questions with a definite answer. Did the code run, does the output have the required fields, is the type correct. Those are real questions and catching them automatically is worth a lot, but they’re conceptually straightforward to answer. Answering “is this any good”, “is this on brand”, “is this the right call given everything else we’re trying to do” is much harder. None of those have a deterministic answer, and there’s no test you can write that returns true or false, because the thing you’re checking is a judgment and not a fact.

The field has a name for this split. The deterministic checks are computational, and the judgment ones are inferential, which is a polite way of saying you need something with judgment to evaluate them, which until recently meant a person and now sometimes means another model asked to act as a judge. Birgitta Böckeler, who’s written the clearest version of this, is candid that the inferential side is the underdeveloped part, that we still have a lot to figure out about building good checks for whether the behavior is actually right, and that what we have isn’t good enough yet. That’s right, and I’d go a step further, because most of the conversation about this is happening about code, where at least some of the behavior can be pinned down by a test, and the harder version is everywhere else.

For code, you at least get partial credit from the deterministic layer, the compiler and the test suite tell you a real slice of the truth before any judgment is involved. For a customer email, a positioning decision, a piece of writing meant to sound like your company, a call about which accounts are worth pursuing, there is no compiler. Nothing tells you it was right except taste, and taste lives in a person or, increasingly, in your best attempt to capture what your taste is in a form something else can apply. That second thing is hard in a way the first one never was, because you’re trying to write down something most people have never had to make explicit, the difference between on and off, good and not, us and not us.

So the open ground is the inferential half, and inside that, the non-code corner is the least charted of all. The world already knows how to write deterministic checks. The unsolved problem is checking the work that doesn’t have a right answer, the work where being good is the whole point and nobody can yet hand you a green checkmark for it.

I don’t have a clean answer to this and I’m a little suspicious of anyone who says they do, because if there were a test suite for taste we’d all already be running it. It’s the most interesting open problem I know of right now, and it implies an invisible line that caps what we can do with AI.

Every week I write this from inside a company that runs on AI agents, about what we’re seeing in the field. This week the field put real money and real numbers on the board.

For the filmed companion, Matt Nicosia joins me - Head of Data and Ops for GTM at Gray Swan, and before that the builder of Zayer in the context space, so he’s lived most of this week’s stories firsthand. We get into what Claude Tag is actually like as a coworker (his team’s verdict: “it replaces process in a much lower lift kind of way,” though they did remove it from the fun channel for trying too hard at jokes), why context products are so hard to differentiate from the inside, and behavior specs as a guard against what Matt calls “long-running AI psychosis.”

1. Buzz nearly tripled in a week. Block’s humans-and-agents workspace went from about 6,700 GitHub stars to 18,400 in seven days, shipping six releases along the way (v0.4.20 to v0.5.2). Canvases landed, the release pace hasn’t slowed, and whatever you think of the chat-room shape, the demand signal is loud: teams want a place where people and agents work together. The open question from last week stands, though. A room shows you everything; it doesn’t tell you what’s true.

2. Type opened its doors. Type - the human-plus-AI workspace from the team behind Halp (Slack-backed, sold to Atlassian) - moved out of private beta: $50 a month flat, unlimited seats, human and AI, bring your own Claude or ChatGPT subscription. The design choice that stands out is “spaces”: shared containers that carry their own memory, connectors, and skills per context, instead of one global pile - plus a Slack bridge so teams can migrate gradually. Their X bio now reads “the first multiplayer AI product,” which is the exact phrase YC’s current Request for Startups uses as a category name. I’ve been in the beta for the past week and appreciate the sensitivity to access control and organization through workspaces. The room war now has a second serious entrant with a price tag.

3. Two $10M seeds for the context layer, 48 hours apart. Modus came out of stealth with a “Context Warehouse” - a continuously maintained model of how an enterprise actually operates, for agents to query - led by Insight Partners. Credible Data raised the same amount for an “AI Context Engine” built on the open-source Malloy semantic-modeling language. Same week, same layer, same word: context. When two funds write the same check for the same noun in one week, the market has decided the noun matters.

4. Behavior specs go open. Braintrust and Basis released agentbehavior.dev, an open standard for documenting how an agent should behave - markdown specs, versioned with code. The origin story is the interesting part: Basis runs tax agents in production for hours, sometimes days, and found that verifying outcomes breaks down at that horizon - too many decisions, too little generalization - so they supervise the process instead, and the specs are how those hard-earned behaviors get documented. The specs are deliberately prose (”clear, human-articulated prose is the highest leverage way to drive agentic systems”) and deliberately not executable - they inform eval design, with the announcement pointing at “eventually rewarding” behaviors, which would make the specs training signal. It’s the third time this month the field has landed on written-behavior-as-ground-truth (Google’s OKF trust fields, Fluent’s behavior specs at code scope, now evals) - and all three stop at the same open questions: who approves a behavior change, and what checks it. Worth reading the examples.

5. The software factory, open-sourced. Mrinal Wadhwa (CTO of Ockam) released Fluent, an open-source “self-improving software factory” you install into Claude Code or Codex as a skill: observations become briefs, briefs become behavior specs with tests, work runs through writer, tester, and reviewer roles in isolated worktrees, and the lessons land with the merge. His line for what happens without that structure: “an automated game of whack-a-mole.” The factory itself is becoming the product, and he’s building it in the open.

6. Andrew Ng’s OpenWorker opened its beta. The local-first, open-source desktop agent from Ng and Rohit Prasad returns finished deliverables instead of chat - 25+ connectors, per-action approvals, everything on your machine. The worker layer is getting genuinely good, fast. What it works from is still each person’s own setup.

7. And the week’s argument: where does judgment live? Martin Casado posted that he vacillates between “the less harness the better, models are the magic” and “post-training plus harness wins.” Andrew Chen posted that his agent skills “just end up generating more and more things for me to review - what I want now is actions.” Two investors, same week, circling one question from opposite ends: when agents do the work, where does the judgment that used to live in review actually go? I have thoughts, and Monday’s letter is about exactly this.

That’s the week. The pattern, if you want one: the rooms multiplied and got price tags, the money went to context, the standards went to behavior, and the argument went to judgment. The last three are three names for the same missing layer. I went deeper on the process half of that this week in “Context is the new process”: most of what we call process was always machinery for moving context between people, and agents just changed the economics underneath it.

Linear spent years building the issue tracker most product teams regard as a standard for what good software looks like. This year, they began dismantling that product and reimagining the whole question around context. In so doing, they said, more or less in these words, that issue tracking is dead. A best-in-class product uninventing itself is worth confronting. This isn’t a rebranding exercise. Issue tracking is, at its core, a coordination problem, and I think they noticed something radical changing about coordination.

Most of what we call process, the tickets and standups and status fields and handoff rituals, exists to move context between people. A ticket is a container for just enough context that someone else can act without having been in the room. A standup is a daily context sync. A PRD is context translated for engineers, a brief is the same context translated again for marketing. We built all this machinery because context was expensive to share, and the machinery was how a company kept twelve people pointed at the same thing without every one of them holding the whole picture.

Agents change the economics underneath that. An agent doesn’t need the work chopped into tickets and routed through a board, it needs to know what you’re trying to do, what’s already been decided, and what good looks like, and it can hold far more of that at once than any process artifact was designed to carry. So as agents absorb the mechanics of the work, the steps stop being the thing you manage and the shared understanding becomes the thing you manage, and coordination starts to look less like a sequence of handoffs and more like a body of context that everyone, human and agent, works from.

We’ve been running BotBot this way for a while now, with the strategy, the voice, the decisions, and the reasoning behind them written down in one place that agents read the same way a new teammate would. And the surprise is that the process artifacts I assumed we’d eventually need mostly never showed up. When the context is good, the work coordinates itself far more than I expected, because the thing the ticket was carrying is already available to whoever, or whatever, picks up the work. The few times things have gone sideways, the cause was almost never a missing process step but a piece of context that was stale or missing or never written down.

And in the last two weeks this stopped being a product-team story, because the field started saying it out loud. Jack Dorsey launched Buzz, a workspace where AI agents are members with their own identity, and in his follow-up essay named the problem it actually solves in one word: context. Every seam between tools loses information, he wrote, and agents feel it the most, because they can’t help with what they can’t see. Chroma’s CEO published “12-factor companies” the same week with the line I’d have led with if I’d written it first: “The old firm bundled labor and coordination. The new firm bundles context and authority.”

And an essay making the rounds told the cautionary version. An engineer left a well-built agent loop running overnight, planner, builder, reviewer, every checkpoint passing, and woke up to thirty thousand lines of code for a modest problem, because nothing in the loop owned whether the work still served the goal. The process held all night. The context failed.

Linear noticed it for product teams, and engineering was just the first place the economics flipped. Dorsey’s cure is one shared room where nothing gets lost, and I understand the instinct, but seeing everything and knowing what’s true are different problems.

If context is replacing process as the coordination layer, then the question that starts to matter is a different one than the ones we’re used to asking about how teams run. It’s no longer which ceremonies to hold or which tool to track the work in, it’s what keeps the context good. Current, true, actually reflective of what the company believes. That’s a different kind of work than running a process, and I think it’s quickly becoming some of the most important work being done.

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.